如何对自己写的代码负责

这个月转岗了，从之前做的一年多的交易营销相关的系统，转去做交易网关系统。由于所属两个团队，在融入之后，明显感觉到两个团队做事情方法的不同，而最大的区别是做事方式的不同。

发版时间窗口的不同

整个公司的发版周期主要是周二，周四的下午进行发版。一般都是周二灰度发版，周四对于周二灰度的情况进行正常全量发版或bug fix之后的全量发版。

之前的团队除了不允许早晚高峰期间发版外，其他时间都可以发版，往往在午高峰发现一些性能瓶颈后，下午进行发版，晚高峰有技术优化需求进行改动后，晚上进行发版，晚上在修改一部分优化代码之后，凌晨进行发版。总的来说，除了正常的翩大一些的需求迭代正常周二，周四发版外，技术优化，bugfix都可以在高峰期之外进行发版。

现在的团队明显遵守公司发版窗口，如果在两个正常的发版周期之外，比如晚间，周一，周三，周五外都不允许发版，除非特殊情况需要主管申请紧急发版。但是申请紧急发版，在主管会时会被点名，会被认为团队的代码质量或者项目管理存在问题。

个人比对两种方式，认为第一种更积极一些，在发现问题之后可以进行正向代码修复，发版上线。第二种更消极一些，针对于因为线上代码出现的问题往往考虑回滚，这样可能存在连锁反映的问题，因为不确定回滚代码之后对上下游有什么隐藏影响，可能引发连锁反映。

个人更倾向于第一种方式，在正常的项目迭代走正常的发版窗口外，对于性能修改，bug fix的代码可以在提pr进行code review后进行窗口外的发版。

和QA同学合作问题

之前的团队其实看起来是很专业的，对于整个需求的理解也更高，整体参与感也更强，可以作为RD很好的帮手。

在RD将功能代码合并到test分支后，QA同学会将本次合并到test分支的RD和负责对应RD功能的QA同学拉近一个单独的群，test环境由值班QA同学统一处理，包括发流程性的群周知，部署环境，如果RD同学代码设计到下游接口调用，RD将观察日志方式告知QA，QA结合自己的测试过程观察抓包数据和服务器调用日志数据，如果日志能反映出一定问题后，可以联系负责对方接口功能的QA同学帮忙查看，因为大部分时间环境不稳定可能因为对方正在部署test环境，或者把测试环境删除了。

新团队的QA同学能力和工作方式个人感觉存在一定的不足，由于我们是网关系统，下游可能对接大量的业务线接口，每次QA同学只负责网关系统的测试，如果发现api有问题直接反映给网关RD同学，而需要RD同学放下手中工作去排查问题，而大部分时间都是由于下游接口在部署环境或者删除了测试数据造成的，整体感觉QA同学对于RD的帮助不大，同时QA同学也需要具备一定的技术能力，在RD同学告知一定的问题排查方式后可以尝试自己解决一些环境问题，释放RD的人力。

个人更倾向于指定严格的SOP及配置相应的工具给团队合作及流程进行把控。可以认定test环境为QA同学唯一测试主干分支，所以此次版本上线功能需要全部合并到此分支，所有业务相关QA同学测试相关功能只能在此分支进行。上下游RD及QA同学拉群，如果上下游环境部署需要在群里告知，降低因为环境部署造成的环境稳定性问题。同时建立工具，可视化的发现新代码提交记录，方式RD在QA不知情的情况下合并代码，如果对应开发分支有代码变更可以推送rd和qa进行监督。只有代码在开发分支和目标分支编译通过之后才允许代码合并到目标分支。

测试用例

RD在完成代码开发之后需要进行单元测试，这个阶段一般在开发联调阶段完成，由于分布式系统的开发，同时存在环境隔离问题。我自己写了一个泛化RPC调用的框架，可以在开发机上直连到目标服务不同环境的服务进行调用，解决了因为代码合并，部署，测试数据不完整等问题，大大提高了开发测试效率。将这个工具提供给了开发同学，大大提升了开发联调效率。

代码部署到test环境交付qa测试之前，rd需要进行必要的冒烟测试，rd同学可以在上下游关键位置打印日志观察接口调用数据，达到更快确定测试准确性的目的。

代码逻辑降级开关

每次新上线的代码一定要有必要的降级开关，可以随时将自己代码功能关闭，比如如果下游是客户端，如果在服务端发版上线后，客户端说功能有问题或者因为延期，客户端代码上不了，服务端已发版的代码是不可能在回滚了。可以通过关闭开关的方式将此部分功能关闭。

核心功能打点

针对于新上线的代码可以进行必要的打点，通过监控大盘观察服务调用数据，更加直观的观察客户端请求总数，因为下游接口失败造成的失败等信息。现在的团队也打点，但是他们打点的只是文本，并不能直观的看到走势和图标，只能去监控系统进行主动查询。

个人推荐用打点客户化的方式进行观察。

接入日志中心

由于一个核心服务有几十台上百台机器，当进行问题排查时，很难准确定位到那台机器去观察日志。之前的团队直接通过日志中心（ELK）的方式对所有机器日志进行收集和监控，通过统一日志平台进行关键字查询，更加便捷。现在的团队自己写了一个脚本，可以提交linux命令分发到所有服务器去执行，这种方式好处是更符合大家用linux排查问题的方式，但是如果存在服务器节点增减则需要维护这个脚本，大部分时间可能会忘掉，造成查询不到的情况。

个人更推荐第一种方式，同时控制打印必要的日志，防止因为日志暴增造成磁盘空间不足引起稳定性问题。日志也是code review过程中需要关心的内容。

团队合作

在之前的公司曾经因为团队合作问题被领导批评过，当时两个原因，一个是认为PM提的需求确实sb，而且出了prd之后，在开发过程中还要修改，往往因为他的修改使得工期变的delay，他还认为改动不大。第二个是认为pm的需求对于kpi或者产品功能本身没有任何帮助，完全不建议开发浪费人力，但是之前的团队还是抱着合作的态度配合，研发团队的话语权比较低。

这两年来到新公司在性格和态度上进行了磨练，经过几个高强度高压力的项目后，抗压能力有所提升。在团队合作上会更主动和积极的方式进行合作。比如如果涉及到多方团队合作会多拉几次各方主R同学到一起，讨论项目进度及风险点，一起过方案达成对于PRD的统一理解降低因为歧义造成的问题。沟通语气上会更积极，比如会经常说“收到”“感谢”“辛苦”“棒的”等话语，让合作方同学感觉到合作愉快。有风险点及时和各方主R和pm同步。代码质量进行保障，主动帮上下游同学排查自己代码功能以外的问题，并及时给出反馈等。

总结

代码质量不只是代码角度的东西，更是整体上是对项目交付的把控，从多项目团队合作，项目管理流程把控，研发工具开发，研发流程化等多角度入手，共同达成对于代码质量负责的目的。