代码评审.pdfVIP

有效无痛苦的代码评审 有效无痛苦的代码评审 Robert Bogue 著 代码评审在大多数公司对涉及到的每个人来说都是痛苦的经历。开发人员通 常感觉它像个有计划弄清楚他们意向的会议。开发部门的领导对于指出什么是重 要的，什么是不重要的也常常会感到困惑。涉及到的另外一些开发人员通过指出 别人代码中可能存在的问题，把代码评审作为表示他们的代码有多么良好的机 会。 尽管如此，代码评审并不是痛苦的。 记住代码评审的目的 代码评审有两个目的。第一个目的是确保要发布质量可靠的代码，换句话说， 它对于开发过程中的下个阶段是否应该提高代码的质量是个严峻的考验。代码评 审能非常有效地发现所有类型的错误，包括那些由于不正确的结构引起的错误， 那些不适合商业进程的错误，还有那些简单的冗余错误。这就是为什么它对于代 码质量来说是个有效的试金石。 第二个目的是作为教学工具帮助开发人员学会何时并且如何应用技术来提 高代码的质量、一致性和维护性。经过反复仔细地评估代码，开发人员有机会掌 握不同的和潜在的更好的编码方法。 代码评审常常以错误的方式开始，因为开发人员感觉它是个多余的措施，被 强迫接受；或者在管理人员并不信任开发人员的某些情况下开始。这两种观点都 是不正确的。代码评审被证实是最小化缺陷的有效方法。无论公司实行代码评审 的额外动机是什么，代码评审都是工业化的最优方法。 方法的实质 代码评审作为代码分析方法中的一种，以参与者处理代码开始，评审过程仿 佛被设计成证明谁是更好的程序员一样。代码评审常常会变成人身的攻击，在这 里人们瞄准对象进行攻击；换句话说，编写代码的开发人员在被复查。更好的途 径是采用学习的方法，所有的评审工作都被当作讨论的内容来讨论并向其他人学 习 就是说这种方法应该是有教育意义的并且是开放的，除了具有创造力之外， 还能感觉到它比以前的人身攻击更有挑战性。那意味着，你可以改变下面几个方 面来使方法变得更好： 1 有效无痛苦的代码评审 1. 询问胜于陈述。陈述是带有指责性的。“你在这里没有遵守标准”带有攻 击性－无论你是不是有意的。询问“你使用这个方法的理由是什么？”会 发现更多的信息。明显地，问题不能以讽刺的或故意屈尊的语气提出；恰 当的询问通常能使开发人员表明他们的想法，并且会因此而询问是否有更 好的方法。 2. 避免“为什么”的问题。尽管避免“为什么”的问题有时是非常困难的， 但是它能充分改善说话的语气。正像陈述是带有攻击性一样—“为什么” 的问题也是如此。大多数“为什么”的问题都能重述成并不包含“为什么” 词语的语句，而且结果是很有成效的。例如，“为什么你在这里不遵守标 准……”与“在这里你违反标准的原因是什么”相比。 3. 记住要赞扬他人。 代码评审的目的不是关注于告诉开发人员怎样才能改 进代码质量，也没有必要让他们知道自己完成的多好。人类的本性是希望 并且需要别人认可自己的成功，而不是表现自己的过错。由于开发是个具 有创造力的工作，开发人员倾注了大量的精力在开发过程中，因此开发人 员把它看得非常重要。这就需要称赞多于批评。 4. 确保参照良好的编码标准。代码评审以公司内部的代码标准为基础。代码 标准一般假设为共享的约定，开发人员彼此使用它来产生高质量，可维护 的代码。如果你正在讨论的内容不在编码标准中，那么你首先需要使讨论 的内容变为编码标准的条款。你应该有规律地询问自己正在讨论的内容是 否在编码标准中。 5. 确保讨论集中在代码上而不是编码人员上。关注代码有助于防止评审过程 变为人身攻击。你不应该对编码人员的好坏感兴趣，取而代之，你应该注 意产生高质量的代码。 6. 记住通常有多于一种的解决方法。虽然开发人员编写出的代码可能会与你 编写的不同，但这并不能说明它是错误的。我们的目标是产生高质量，可