CR规范&文档

为什么要CR？

提前发现缺陷
在CodeReview阶段发现的逻辑错误、业务理解偏差、性能隐患等时有发生，CR可以提前发现问题。
提高代码质量
主要体现在代码健壮性、设计合理性、代码优雅性等方面，持续CodeReview可以提升团队整体代码质量。
统一规范和风格
集团编码规范自不必说，对于代码风格要不要统一，可能会有不同的看法，个人观点对于风格也不强求。但代码其实不是写给自己看的，是写给下一任看的，就像经常被调侃的“程序员不喜欢写注释，更不喜欢别人不写注释”，代码风格的统一更有助于代码的可读性及继任者的快速上手。
防止架构腐烂
架构的维护者是谁？仅靠架构师或应用Owner是远远不够的，需要所有成员的努力，所谓人人都是架构师。架构防腐最好前置在设计阶段，但CodeReview作为对最终产出代码的检查，也算是最后一道关键工序。
知识分享
每一次CodeReview，都是一次知识的分享，磨合一定时间后，团队成员间会你中有我、我中有你，集百家之所长，融百家之所思。同时，业务逻辑都在代码中，团队CodeReview也是一种新人业务细节学习的途径。
团队共识
通过多次讨论与交流，逐步达成团队共识，特别是对架构理解和设计原则的认知，在共识的基础上团队也会更有凝聚力，特别是在较多新人加入时尤为重要。

CR过程中关注什么？

代码逻辑

设计：代码是否设计良好？这种设计是否适合当前系统？是否考虑了全局设计和兼容现有业务细节，是否考虑边界条件和并发控制？
安全隐患：是否存在数据安全隐患及敏感信息泄漏，如越权、SQL注入、CSRF、敏感信息未脱敏等？
性能隐患：是否存在损害性能的隐患，如死锁、死循环、FullGC、慢SQL、缓存数据热点等；
功能：代码实现的行为与作者的期望是否相符？代码实现的交互界面是否对用户友好？

代码质量

规范：命名、注释、领域术语、架构分层、日志打印、代码样式等是否符合规范？
复杂性：代码可以更简单吗？如果将来有其他开发者使用这段代码，他能很快理解吗？是否有重复可简化的复杂逻辑，代码复杂度是否过高，符合KISS和DRY原则
测试：这段代码是否有正确的、设计良好的自动化测试？单元测试用例的验证逻辑是否有效，测试用例的代码行覆盖率和分支覆盖率；
命名：在为变量、类名、方法等命名时，开发者使用的名称是否清晰易懂？
注释：所有的注释是否都一目了然？是否能让不熟悉的同学快速了解代码逻辑？是否可以让老旧代码清晰明确
代码样式：所有的代码是否都遵循代码样式？
日志：日志打印是否合理，是否记录清晰完整，是否能辅助线上排查问题，测试日志是否及时清除？
可扩展性：是否仅仅是满足一次性需求的代码，是否有必要的前瞻性扩展设计

CR建议：

CR时间点：建议在测试中前期就进行CR，CR完成后会有相应的代码优化改动，还需要通过测试验证，所以开发完成后测试中前期进行CR是最合理的时间点。
工具：建议使用云效codeUp的代码比对功能进行CR，改动点自动抽取并高亮，便于阅读。
交叉CR：建议邀请多个人进行CR，尽量包含业务熟悉的同事、技术比较强的同事、域owner等。
后期跟进：修改后的代码是否如CR时所沟通的，建议CR同事对修改的代码做再次确认。