认认真真做开发

晚饭时读到Sam哥写的一个博文。受益良多，在此记录一下。原文链接

开发我们是认真的

下面的事情要做在，开始写代码之前:

认真仔细的了解需求，对项目做出整体的认知；
认真仔细的了解需求，对于不确定和不理解的需求定义一定要和相关人员沟通确认好；
认真仔细的了解需求，对于已经确定好的需求，要尽可能的考虑到后续的扩展情况，构思好自己的模块代码要怎么封装；
认真仔细的了解需求，做到在真正写代码之前，心中要有自己负责模块代码的雏形（独立开发的人，要构思好整体的架构，想明白主流程和其他流程的逻辑及处理）；
对于迭代的版本，最重要的也是上面的要求，一定要理解需求<线上版本的需求与新需求之间到底有多少不同之处>，然后针对需求看代码的实现以及更新代码的工作量评估；
对于迭代的版本，新功能上线一定要做好，上线后的维护方案，做好最坏的准备；

Part one

情景描述

很多开发人员再简单了解需求之后，都会hen着急的去写实现代码。其实这样很多时候反而会降低自己的开发效率。

我就遇见过，开发人员代码写完之后提测，测试同学反馈说，某某功能逻辑不符合需求，不符合逻辑，或某某功能对场景支持不完整。

其实，在独立开发或者协同开发系统功能模块的时候，可能自己或者队友会认为** 按时提测、按时上线 *就是对自己的模块 认真负责 了，很少甚至不会想上线之后的维护问题。

谁也不能保证产品上线之后，完全没有问题。假如某产品上线之后，隔天出现了问题，boss来了夺命连环问：

boss：问题分析了没有？影响面有多广？
me: ？
boss:：可以回滚吗？
me：？
boss：是接口性能问题还是功能问题？为什么没有收到报警？能看到日志吗？log文件给下。
me：…没有log。（ps: 这样的人基本就是没有完全理解需求）
boss：…

Part two

认真做开发

产品上线，即便测试的同学做了非常严格的测试，功能测试和回归测试等等，都不能保证上线后没有问题出现。
所以，做为开发人员，以下几点是我们应该做到的事情：

想好回滚/降级/灰度 方案

如果是前后端都改需求，那么一定要先沟通好需求及如果上线后某一端出现问题时，另一端的支持方案；

对于server端，如果是需要做数据库变更的改动，一定要想好旧版本代码是否能够访问更新后的数据库。

最好的情况是数据库表设计向下兼容;
最坏的情况就是旧代码和旧表一起回滚<自己备份的有旧数据，新数据丢失了或者手动导入新产生的数据>；
最最最坏的情况就是：旧代码还在，旧数据没了，那么恭喜你，只能硬着头皮改bug了，留给你自测的时间已经不多了

如果是技术重构项目，必须要有灰度开关，要随时能切回旧版本的技术方案；

举例：
<server端单独修改>

server端接口server-animal(Animal animal)需要使用新技术：
将旧版接口改为server-animal-v1(Animal animal);
新技术接口实现为server-animal-v2(Animal animal)
提供给C端的接口不变，在接口内部通过开关控制使用server-animal-v1() or server-animal-v2()；
之后，如果v2上线之后没有问题，在之后的迭代中可以考虑将v1拿掉。

<C端单独修改>
如果是特殊场景下的项目，比如公司班车C端应用需要修改功能，最好是将灰度开关添加到配置项中。
ps: 配置项放在本地或者云端都行，取决于实际需求。
如果班车有几十或者几百辆，最好还是放在云端，当然云端也要考虑是否需要支持针对某一个班车做特定的限制。
如果班车只有两三辆，项目初期为了节约成本，也可以将配置项数据放在本地。
这样版本上线后如果有问题，可随时修改配置项数据。
同样的，如果上线后项目稳定运行，后续也可以考虑将旧代码清理掉，使项目更加便于维护。

当然，回滚操作也要求我们要做好版本控制。至于是用SVN、Git还是自己公司的取决于实际情况。
但重要的事情还是要做好版本控制。

重视测试人员的测试用例

这个比较容易理解，术业有专攻。专业的测试同学提供的测试用例，做为开发人员一定要仔细看一看，查漏补缺，很多前期没有考虑到的case会进入我们的视野，往往会使开发逻辑变得清晰。
另外，通过看测试用例，可能存在对同一个需求，理解不一样的情况。出现这样的情况时，一定要拉上相关人员进行讨论，把需求确定下来，避免不必要的返工。
评估测试用例的维度：

• 功能的完整性；
• 如果是迭代版本，旧版本的回归场景是否完整；
• 是否有其他遗漏的场景；

提测要提供更新日志

新版本提交测试，一定要提供release note，方便了测试同学，也方便了自己。很多时候一个release note会减少很多不必要的沟通。

做好日志监控

功能模块要做好监控，一旦有任何一个报错，你都能第一时间知道，提前介入解决。比如说：

• 接口打印响应时间，如果响应时间超过200毫秒的，打warn日志；
• List item将接口关键字上报到elk，借助elk做告警，并同步到企业微信或者钉钉告警群；
• 打印入参和出参，方便定位问题，尤其是接口报错时，上下文入参一定要打；
• 如果接口调用了第三方服务的，也必须打印调用一次接口的时间以及入参和出参；

做好数据监控

如果你负责的订单/支付模块，最好能做个数据监控，例如：

• 未支付订单数监控
• 退款订单数监控
• 使用优惠卷订单数监控

如果做的是短信模块，就监控短信发送数量;
如果是做的是发票业务，那就监控开发票失败的数据。
把监控结果，放到监控大盘里，方便大家看。

C端接口的，做好压测

C端接口是用户级别的，每个接口都得压测，通过压测发现瓶颈所在，提早优化。一般要经过如下几个阶段：

• 开发压测，给出预期qps；
• 测试人员压测；
• 线上压测；

关于线上压测，如果服务设施没搞好，那就必须晚上压测。现在用阿里的PTS做压测方便，建个压测任务就行。

一个合理的线上观察期

如上文提到的，功能按时上线了，还是做的不够的，因为还需要加一个线上观察期。模块上线后的一个星期内，每天都要仔细观察该功能是否运行正常，例如如下这些维度：

• 1、接口有无ERROR日志；
• 2、接口响应时间是否正常，尤其是高峰期；
• 3、BUG群里是否有关于该功能的报障；
• 4、有无异常数据；
• 5、写入的数据是否符合预期，是否影响到下游系统；
• 6、之前的出现的问题，是否如预期的完整解决了；

好多开发人员经常漏掉这一步，认为上线后就完事了。

Part three

小结

有条件的公司，一般都会先出内测版本，进行小范围线上测试。这个时候就体现出有资金支持的项目真好，开发人员的幸福感还是有所提升的，毕竟暴风雨没有直接上线来的猛烈。

功能模块从需求–>开发–>测试–>上线–>线上观察期–> 维护与迭代 这几个过程，都照顾周到了，才算对该模块负责了。同时这也是一个开发人员应该要有的习惯和素质，认认真真才能发展和成长，对项目负责，同时也是对自己负责。
————————————————
以上内容借鉴于Sam哥《《《《《《 对自己开发的模块要认真负责 》》》》》》
原文链接：https://blog.youkuaiyun.com/linsongbin1/article/details/107304974