系统健壮性设计（一）

系统健壮性设计

代码评审

烂代码

如何评估你将要面对的代码是否是一堆烂代码，可以从以下两个方面评估

1. 人的视角：
   • 维护者脏话的频率高，且内容丰富；
   • 存在动粗的可能性
   • 面向离职编程
2. 代码的视角：
   • 不遵守代码规约；
   • 代码像迷宫；
   • 代码流程脚踩西瓜皮
   • 代码执行效率低；
   • 代码行数与bug数不成正比

代码的恶性循环

星级程序员

1. 写出计算机可以理解的代码
2. 写出自己未来可以理解的代码
3. 写出别人可以自我理解的代码

程序员的自我修养

代码评审（code review, CR）

代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。

评审内容

1. 编码规范问题：命名不规范、magic number、 System.out……
2. 代码结构问题：重复代码、巨大的方法和类、分层不当、紧耦合
3. 工具、框架使用不当：Spring、Hibernate、AJAX
4. 实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好
5. 测试问题：测试覆盖度不够、可测试性不好
6. 代码评审不负责检查功能、逻辑是否正确，这些要靠单元测试和QA工作来解决

评审的好处

1. 对团队、项目的好处：
   • 熵减的过程，减少系统混乱；
   • 提高代码质量，工程师互相review,扫除知识盲区，提升代码的质量；
   • 提升代码规范度，通过代码审查，发现纠正不规范情况，慢慢形成良好开发规范；
   • 团队成长，养成团队成员间的交流文化，有利于团队的知识共享。
2. 对个人的好处：
   • 提高自身的抗打击能力
   • 对于自己错误的深刻理解
   • 交流中碰撞出新的思维

如何做CR

1. 统一的编码与设计规范；
2. 完整的技术架构说明与事例；
3. 不定期的review会议；
4. 小项目（3个月内）可10天/次，大项目（6个月以上）可15天/次，前期可以密集安排，后期可调整时间间隔1~3月/次。

CR建议

1. 对事不对人；
2. 至少一条正面评价；
3. PR¹内容一定要少；
4. 不要在review中讨论需求；
5. 明确各模块负责人。

推荐工具

• Phabricator: Facebook开源的代码审查工具
• Gerrit: 非常强的CodeReview+代码托管工具
• CheckStyle：代码规范检查工具

---

1. PR是项目评审（Project Review）英文的缩写。就是关于审查和批准项目计划，项目变更和工作进展评价的一个步骤。项目评审的输入、步骤以及它的输出结果取决于不同的评分类型。 ↩︎