第一次需求上线经验总结

第一次从头到尾完整地实现了需求的上线，总计花了两周多，花费的周期很长，但是收获也很多。最大的收获毫无疑问，就是掌握了需求上线的整个流程。从需求的产生、评审，到开发、自测、提测、showcase、上线，整个流程走下来，也有很多经验和反思。当然还有很多其他方面的成长，例如代码规范、团队合作、项目业务等。主要总结一下上线流程中需要注意的点和遇到的问题。

一、需求的提出和评审

当上线完成后，我第一个想法就是，需求的提出和评审一定要全面地慎重地考虑好。

1. 提出需求的最终目标是什么？它是否和其他需求有耦合的地方？以后是否会有类似的需求产生？我们的设计要保证它的安全性和扩展性，同时也要确保需求的粒度是合理的，比如需求是否可以拆分，提取出公共部分给其他需求使用？
2. 需求的影响范围是否可预期？它是否有可行易解的实现方式？如果不好实现，我们可以去思考PM需求背后的目标是什么，和PM进行讨论，对需求进行微调，使其容易实现。如果等需求进行到一半了才发现不好实现，再修改的成本就会十分高昂。

二、开发

1. 我们在完成需求时，一是要避免复杂的实现方式。如果需求本身很清晰，但实现方式很复杂，这说明需求的设计不够合理，因为每一个项目都有一套设计的内在逻辑在里面，要尽量在符合内在逻辑的基础上去简洁地完成需求。不然的话，复杂的代码会增加项目的维护成本，同时也会增加不安全的可能性。如果无论如何也很难清晰地实现，那极有可能是以下两种情况：a）需求本身不够合理，b）项目的设计逻辑不够合理。不管我们是否会对其修改，都要有自己的思考。
2. 要尽量复用之前的代码，尤其是各种工具类的使用，例如DateUtil、CollectionUtil、StringUtil等，这些功能也许自己实现也很容易，但是复用代码有很明显的好处：提高代码可读性，减少项目维护成本。
3. 提到可读性，一定要明白一件事，代码不仅是写给自己看的，更是给别人看的。代码不是行数少就好，就精妙。有的时候我们反而需要把代码拆开多写几行，多一些注释，让读代码的人可以更加清晰、了然。只要人人都献出一点爱，多考虑下别人的感受，世界将变成美好的人间~
4. 代码的差错控制问题，你永远也不知道你写的方法会被谁在什么情况下调用，对于入参、调用别人方法的返回值，务必做好空值、空集合的判断，做好try-catch的处理。不要嫌麻烦，谨慎永不过时。

三、测试

测试过程需要额外关注的地方似乎并不多，无外乎测试要细致而全面，要尽量覆盖各个方向可能的值。值得一提的是，在接口测试时，往往需要在测试环境中进行调试，我们可以在编写回调接口时就写好对应的测试接口，提前准备好。这样的话，如果我们在进行功能测试时发现了问题，可以直接调用测试接口进行定位，只需要部署一次环境。如果没有提前准备好，我们还需要继续编写测试接口，重新部署环境，时间成本就会很高。

四、上线的注意点

1. 在上线之前，一定要想好自己都需要做哪些准备，例如数据库建立新索引、出现故障后采用回滚还是其他保障措施、控制问题的影响范围。
2. 需求上线，务必要慎重，尤其是涉及核心业务的需求，务必做好测试！务必做好测试！务必做好测试！提前做好发生故障的准备，想好应急方案，随时准备回滚。测试过程中难免会遇到预想不到的问题，比如测试环境数据库和生产环境数据库不同，测试就可能会有一些覆盖不到的地方。
3. 灰度更多是观察对项目进行更新后，是否影响了之前服务的稳定性。有可能一些其他的服务对于此次更新的服务有比较强的依赖关系，但是之前没有考虑到。一定要尽快开始对日志的观察。
4. 在灰度时，只会部署少数服务器。这就导致少数服务器是更新后的服务，其他服务器还是之前的服务。如果这个时候有相关调用进来，而它命中了更新前的服务器，就有可能会出现异常。像我遇到的情况就是，点击查询按钮后，有的时候没有结果，有的时候可以查询到结果，这就是没有命中更新后的服务器导致的。
5. 遵守上线流程规范！每次发布都要先灰度再全量。能够提前预想到的情况就不叫意外了。