十条简单高效的 Code Review 技巧【翻译】
Code review （代码评审）是软件开发中用来确保代码是否满足功能需求的环节之一，可以帮助开发人员遵守最佳编码实践。此外，code review 还能提升软件质量。
我根据自己的经验，在此分享十条简单的 code review 技巧，希望可以在 code review 中帮助到代码审阅人员和软件开发人员。
1. 指出代码中的问题
不要强制开发人员修改他们编写的代码。这可能会伤害他们的自尊心，如果他们没有明白代码修改建议背后的原因，下次可能还是会犯同样的错。只要指出代码中的问题以及该问题带来的影响就可以了。
关于这个问题，引用一段有趣的箴言：
如果鸡蛋被外力打破，则生命终止。如果是被内力打破，则生命开始。伟大的事情都是从内部开始的。—— Jim Kwik，学习专家
2. 解释相关的编码原则
如果开发人员不愿意接受给出的意见或者建议，则需要向他们解释相关的编码原则，比如关注点分离原则（Separation of Concerns，SoC）、单一职责原则（Single Responsibility Principle）、开闭原则（Open-Closed principle）、圈复杂度（Cyclomatic complexity）等。如果有必要，可以和他们讨论一下非功能性要求（Non Functional Requirements，NFR），比如可维护性、可扩展性、可测试性和可读性等。
3. 引用相关的编码箴言
为了使 code review 变得更加有趣和引人入胜，可以引用一些箴言来提醒开发人员：
任何笨蛋都可以编写计算机能理解的程序，但只有优秀的程序员才能编写人类能理解的代码。—— Martin Fowler
使用代码行数来衡量编程的进度，就像使用重量来衡量造飞机的进度一样。 —— Bill Gates
胖模型、瘦控制器（Fat model and thin controller）；高内聚、低耦合
在调试的时候，新手会插入矫正代码，专家会删除缺陷代码。—— Richard Pattis
4. 适当地做些线下工作
不要在 code review 中向开发人员解释整个解决方案，只要给出一些相关的链接地址，或者是给出一些关键词鼓励他们自己去研究。这种方式可以节省审阅人员的时间和精力。当然，开发人员也会喜欢这种方式，因为他们也需要一些时间来消化提议的解决方案。
在 code review 期间，不要让代码审阅人员一直坐在开发人员的旁边，他应该可以从源代码管理工具或者共享地址中直接获取到源代码，这样就能节省开发人员的时间，也能给审阅人员充足的时间来推荐所面临问题的最佳解决方案。
5. 作为一个学习最佳实践的机会
有时候，开发人员会站在自己的立场来看待审阅人员的评论，并在没有正当理由的情况下为代码辩护。此时，审阅人员需要告知开发人员，应该把 code review 当作学习或者讨论最佳实践的机会，而不是为了找出要批评的问题，这是审阅人员的责任所在。理想情况下，审阅人员应该通知经理，code review 中的评论不应该用来评估开发人员的技术水平。Code review 应该本着竞争精神开展，为的是能找出更多有用的评论。
6. 永葆耐心，若有必要就重新评审
有时候，开发人员不会接受意见或者建议，而是持续争论。审阅人员可能并不清楚编写代码时所面临的确切上下文环境和挑战。审阅人员应该要理解开发人员提出的所有辩解要点，不要显得不耐烦。此外，为了让争论点更加清晰明白，审阅人员可以将开发人员的方案和自己的方案写在纸上或者白板上面，然后一起解释对比下看看。每种方案都有其利弊，谁优谁劣要经过仔细评估，然后再选择正确的方案。
很多时候，会产生能让开发人员和审阅人员都能接受的第三种方案。如果他们不能达成共识，就停止讨论，比如说“我们先回去多做些分析，然后明天再来一起讨论”。如果在另外的一天，以一种全新的心态来重新审阅同样的问题，很可能会想出一种新方案。永远记住：
没有任何问题可以从创造问题的意识层面得到解决。—— Albert Einstein
7. 解释最佳编码实践的必要性
通常，开发人员会说没有遵循最佳编码实践是因为项目排期太紧。开发人员会觉得他编写的代码是可以接受的。然后，审阅人员应该教育开发人员，随着代码体积的增加，过段时候，整个应用程序会变得难以维护。再者，如果客户也要检查代码的话，那么质量差的代码会给团队或者公司组织的质量标准造成不好的影响。这对将来承接新项目或者将公司组织推荐给潜在客户，都可能会有影响。
如果项目排期太紧，审阅人员可以建议开发人员在修复缺陷、增加功能或者下个版本中重构一下代码。在重构代码时，可能会不小心破坏已有的功能。审阅人员应该说服项目经理，解释代码重构的必要性，并且要为代码重构分配额外的时间计划。
8. 若无法说服，则咨询次审阅人员
如果审阅人员给出了一些意见，但是开发人员不愿意接受，然后需要和开发人员一起讨论。很有可能审阅人员不知道完整的上下文环境。如果审阅人员仍旧无法说服开发人员，则可以咨询次审阅人员，这是完全没问题的。但是，开发人员务必要将次审阅人员的意见转发给主审阅人员，确保大家能达成共识。
9. 发现改进点和技术债
审阅人员给出的意见，很有可能在当前发布版本中不能实现。但是，审阅人员要将所有已被接受的建议，清晰地记录在共享的代码评审文档中，这样的话，在将来的某个适当时机再来实现这些建议。此外，审阅人员应该从技术和业务的视角来确定和指出可以改进的点。当项目完成开发的时候，所有指出来的改进点就可以按照之前记录的文档去考虑实现了，而不是到了那时再去查找。在 code review 中检查改进点会比在项目结束时再来单独查找问题高效得多。
10. 所有 code review 评论文档化
将所有的 code review 评论，记录在邮件、word 文档、excel或者团队在使用的其他任何文档工具中。第一次犯错是可以接受的，但犯同样的错误是一个不好的信号。Code review 文档可以帮助开发人员交叉检查所发现的问题，避免在将来犯同样的错。此外，维护 code review 文档是能力成熟度模型集成(Capability Maturity Model Integration，CMMI)级别流程的强制组成部分。
小结
上面所说的 code review 技巧可以帮助审阅人员和开发人员进行高效的 code review。Code review 应该始终被所有利益相关者以具有建设性的方式所追寻，从而获得最大的收益。
Code review 不仅可以改进软件质量，也可以持续地提升软件开发人员的技术水平。因此，公司组织或者项目经理务必确保在软件开发过程中执行 code review。
留下评论