一、日常问题
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）日常性的体验优化
我理想下来，用户体验优化，要优化的点的来源于两处。
第一处是业务方的反馈，第二处是代码中。
前几天，一个运营希望我能在一张页面的过滤条件中增加一个条件，这种需求对于我们开发来说，就是举手之劳，但是对于她们的工作体验那是很高的提升。
日常工作中，我其实也一直在给我们组员灌输帮助业务方提升体验的意识。尤其是那些改造成本很低，但是见效快的需求。
我们日常工作就是写代码，那么在写代码的同时，也会去理解业务逻辑，这个时候其实也可以做体验优化。
例如之前有个页面要做修改，在修改时发现这个页面居然没有查询条件，但是页码却不少，一处非常明显的糟糕体验。
给此处加个过滤条件，成本也并不高，加完后，业务方还对我们组表示了感谢。
所以说，并不需要大张旗鼓的专门抽时间来做体验优化，完全可以分散到日常工作中，逐步优化。
对于改造成本较大的优化，那么就需要排期，走一整套的研发流程。