条实践助你更好地完成代码评审.docxVIP

13 条实践助你更好地完成代码评审 多年来，我一直在接收代码评审会议的邀请，同时也在发出邀请。假如做得不适当，代码评审可能会令人恼火、花费大量时间，并且对代码质量几乎没有影响。但是，假如做得适当，它可以提高代码质量并削减交付特性所花费的时间。它还有助于发觉麻烦的 bug，加速团队中的学问共享。在代码评审期间发生的对话也可以使我们对问题或替代处理方案有新的见解。 我将 baker 的 13 条最佳实践放在了一起，你和你的团队可以使用它们来提高代码评审的效率。 创建小的提交列表 你可能已经听说过通过部署最小功能进行增量开发的好处。这样的一种部署削减了交付时间，供应了快速的反馈并降低了技术风险。当你将代码评审加入到增量开发中时，所带来的好处愈加显著。当提交列表的大小添加时，等待评审者的反馈所花费的时间也会添加，并且大多数情况下会以超线性的方式增长。这有以下几个缘由： 首先，当大的提交列表中存在设计缺陷时，它会影响你已经实现的更多代码段。但是，假如你将大的提交列表分解成几个小的提交列表并将它们一个接一个地合并，就可以避开一些返工。其次个挑战是将提交列表与主分支合并。当你在处理你的提交列表时，其他人也在处理他们的提交列表。因而，在检查代码时，很自然地会将一些提交列表合并到主分支中。假如其他提交列表与你的提交列表涉及到相同的地方，则合并将导致进一步的变更，这将导致额外的检查时间。当提交列表长时间保持打开形态时，它会同时惹恼开发人员和评审人员。它使他们丢失斗志，由于他们没有前进的感觉。这项工作不被认为是“完成了”，未针对业务显示出任何利润。 但是，将提交列表划分成更小的提交列表并不总是那么简约。次要 API 的变更、迁移到新的框架或基础设备、架构重构以及应当一起发布的特性只是我们面临的其中一些挑战。在这种情况下，特性标志和笼统分支（Branch By Abstraction ）等实践可能会有所挂念。 要使用这些方法，你可能需要在代码中引入切换标志，并创建模仿对象和额外的接口。虽然你可能认为做这些事情是在铺张时间，但大多数时候，通过削减研制周期并挂念你取得平稳牢靠的进展，你会得到报答。 提交列表应当由他们本人独立完成 如何分解你的提交列表格外重要。例如，通过推迟单元测试来划分提交列表是不好的做法。虽然这是一个格外简约的选择，但是这种做法会使代码库处于不行靠的形态。这种形态会保留在代码中，甚至在接近截止日期、新特性优先于延迟的工作时变得更糟。因而，你应当尝试有一个小而完整的工作，包括它的测试，甚至它的部署 / 迁移脚本。 应当让最佳论点获胜 在消灭分歧的情况下，哪一方应当获胜？是程序员还是评审人员？谁更有阅历？没有人？现实上，这不是谁的问题！建立一种让最佳论点获胜的文化。 假如你是一个有阅历的开发人员，你应当能够为你的论点提出理由，而不是仅仅表达你的“感觉”。假如你有某方面的阅历，试着解释一下，为什么你认为它适用于当前的环境。因而，在最佳论点获胜的文化中，“我只要在有论据支持的情况下才会提出主意！”试试这个，你会受益于两个缘由: 你不会由于没有理由的事情而让你的同事不兴奋。 做好解释你的论点的预备会给你力气。它鼓舞你查阅教科书，在网上搜索论文，询问其他专家和资深同事。最终，你要么确保你的观点，要么订正你的假设。 你会学到一些东西。所以，每次你添加评论时，请解释你的理由，除非理由显而易见或之前已经被解释过。假如你不像同事那么阅历丰富，假如一条评论的目的不明确，你应当问问“为什么”，这是你的权利。评论是一次学习的机会。在下一个提交列表中，你应当削减反复的缺陷。当轮到你来评审的时候，你可以给其他同事类似的评论。要做到这一点，你就得在不晓得的时候问“为什么”。 假如你认为另一种选择更好，可以毫不迟疑地与你的评审人员争辩它的利弊。然后，让更好的论点（更有优势的处理方案）获胜。但是，预备好接受它，不管它是不是你的主意。现实上，这是对资深和初级的程序员和评审人员的好建议。做一个有激情的人，一个想晓得“为什么”的人，一个渴望为本人的想法辩护的人，但也要对其他的可能性和处理方案持开放态度。 假如另一个处理方案和你的一样好，就不要争辩了 作为一位实现者，假如你得到一条评论来重命名一个变量，但是你认为建议的名称是相像的，没有明显的区分：接受它。作为一名评审人员，假如你想要提出一个修改意见，但是你不能解释你的建议的明显优势：跳过它。你可能会想，“我的处理方案和同事的一样好。我为什么要放弃呢？”答案很清楚。你的假设是错误的。对你来说同样好的事情，对你的同事来说可能就不一样了。假如在你的加权系统中，这些选项是等价的，你就是那个可以容忍它并体现机警性的人。所以这样做吧。把争辩留到对你重要的事情上。 还有，永久不要数，“我让了他们两次了；现在轮到他们了。”计数玩耍是一种破坏性