一、日常问题

1）在家办公

　　3、4月份上海疫情很严重，公司在3月初的时候就果断让大家在家办公。

　　一开始，我觉得在家办公会很影响工作效率，但从后面的工作完成度来看，并不是这样。

　　以我自己为例，我感觉工作时间变长了，因为本来还有通勤时间，现在这部分时间都省了。

　　早上九点没什么事情，就可以开始工作了，中午吃好饭，急的话也可以开工，晚上吃好饭，都能做到20点。

　　这么一算的话，去掉吃饭和休息时间，每天工作得有个8个小时以上。VPN、笔记本电脑都配置好，和在公司上班没啥区别。

　　只是同事之间的交流只能通过即时通信软件了。我们团队的话，会每天下午16点，开个视频会议。

• 一则是分享些公司消息，了解公司动向。
• 二则是大家见见面，聊些近况，免得一个多月不见就生疏了。
• 三责是及时解决工作问题，积累经验，并且避免掉进坑中浪费时间。
• 四则是做些内部的技术分享、Code Review等事情，维持技术氛围，保障项目质量。
• 
  

2）合理修复线上问题的过程

　　前几天休息日的晚上，运营对服务端的开发说，客户端首页有个版块的图片有点模糊，服务端的人就找到了我。

　　我在简短的分析后，就发现是因为图片的地址中带了尺寸的参数，要清晰的话，就将该参数去掉即可。

　　那么接下来就涉及如何修改了，我给出了三套解决方案。

　　（1）在首页接口中，由服务端手动去掉尺寸参数，这是最快速的临时方案，但服务端觉得这样不合理，应该在后台上传的时候就去掉。

　　（2）我马上给出了第二套方案，那就是将后台那部分相关的接口，全部交由服务端统一处理，但他们觉得工作量太巨大，从长计议。

　　（3）既然如此，我给出了第三套方案，那就是在后台中，相关图片在上传时全部不做默认的压缩，只上传原图，由服务端根据不同场景动态添加尺寸，但他们觉得改动成本略高。

　　于是经过讨论，敲定了方案一，但是要与运营说明方案的利弊，以及潜在的风险，修复成本等等。

　　例如将图片修改成原图后，首页的加载速度势必会受影响，并且客户端有可能出现不能适配原图的问题，还有就是在调试接口时，需要先上测试环境，安排QA验收，意思就是要有一定的时间和人力成本。

　　因为图片模糊的问题既不影响营收，也不影响当前业务的流程，所以在给出方案后，并不是说马上就要修复的，需要商量上线时间。

　　既不给自己压力，也不给其他研发组的成员压力，客客气气协助修问题。

3）HTTPS证书

　　最近出了两次事故，都是因为证书到期，导致无法通过HTTPS协议访问。

　　这些域名都是由运维在管理的，但是他们之前没有将域名统计到一个文档中。

　　现在有100多个子域名，分散在各个项目中，手动的搜集，难免就会有遗漏，运维也意识到这一点了。

　　他们这次将所有的子域名都统计到一张表格中，而我们出事故的那几个子域名就被遗漏了。

　　虽然整理的工作是他们在主导，但是自己组所使用的域名，自己还是得清楚。

　　依赖别人的话，还是会有点不稳，因此事故后，在组内也组织了人力去将所有使用的域名都统计出来。

　　其实其他事情也一样，在自己管辖范围内，尽量还是做的精细些，并且能识别出其中的隐患，不然出问题了，背锅的是自己。

4）上线把关

　　最近上线一个计算积分的活动，但是发现数据多算了一天。

　　究其原因，就是上线前的测试数据没有清除干净，这就是一个流程问题。

　　差了最后一步，QA在验收完成后，需要与我们确认数据，例如缓存是否清除，定时任务配置是否正确。

　　立刻将这一条写入协作规范中，并且传达给了组员和QA组，让大家未来任何活动都需要有这一步。

　　以免再次出现此类问题，这次的活动，默认就当早一天进行了，运营也没有表示异议。

二、工作优化

1）管理后台响应式改造

　　为了提升业务人员操作管理后台的体验，花了点时间进行响应式的改造，紧急情况时，掏出手机就能工作。

　　利用CSS3的媒体查询，就能根据不同屏幕的尺寸采用不同的样式来渲染，目前使用的移动端屏幕阈值为750px。

　　为了便于管理，基于Less的语法，声明了一个常量，专门记录屏幕尺寸。

@mobile-screen: ~"(max-width:750px)";

　　我们当前使用的管理后台基于UmiJS3.X和Ant Design 3.X。具体改造过程可以参考此处。

2）团队内部的技术分享

　　在四月初，我发起了团队内部的技术分享，用意其实很明显，就是想让大家能花更多的时间关注技术，提升自身能力。

　　虽然是我强推的，但是大家的响应还是蛮积极的，差不多一个月内分享了4场，平均一周一场。

　　覆盖的范围包括源码的解读、工具的使用等，分享下来，听到最多的就是对该库或工具有了更深层次的理解。

　　这就是我想要的，我在他们分享之前，给他们限定了一个范围，就是要我们当前团队正在使用的。

　　因为你正在使用，所以在知其然后，就能马上应用到日常工作中，排查问题的思路也能更多，印象也能更为深刻。

　　还有一点就是，我会让大家把分享好的资料整理成文档，贴到内部WIKI中，也供其他人可以浏览学习。

　　我想通过这个技术分享，来持续保持团队内部的学习氛围。

3）日常性的体验优化

　　我理想下来，用户体验优化，要优化的点的来源于两处。

　　第一处是业务方的反馈，第二处是代码中。

　　前几天，一个运营希望我能在一张页面的过滤条件中增加一个条件，这种需求对于我们开发来说，就是举手之劳，但是对于她们的工作体验那是很高的提升。

　　日常工作中，我其实也一直在给我们组员灌输帮助业务方提升体验的意识。尤其是那些改造成本很低，但是见效快的需求。

　　我们日常工作就是写代码，那么在写代码的同时，也会去理解业务逻辑，这个时候其实也可以做体验优化。

　　例如之前有个页面要做修改，在修改时发现这个页面居然没有查询条件，但是页码却不少，一处非常明显的糟糕体验。

　　给此处加个过滤条件，成本也并不高，加完后，业务方还对我们组表示了感谢。

　　所以说，并不需要大张旗鼓的专门抽时间来做体验优化，完全可以分散到日常工作中，逐步优化。

　　对于改造成本较大的优化，那么就需要排期，走一整套的研发流程。