代码审查的实践经验.docxVIP

代码审查的实践阅历 首先，让我们谨记为什么要做代码审查。对于任何专业的软件开发人员来说，最重要的目标之一是能够持续的提高他们的工作质量。即便你的团队里尽是优秀的程序员，你也不能将你本人与一个有力量的自在从业者区分开来，除非你能够作为一个团队工作。代码审查是达到这个目的的最重要方式之一。尤其，它们： 赐予你其次双眼睛来找到做某些事的瑕疵和更好的方法。 确保至少有一个其他人员生疏你的代码。 通过向新员工呈现更有阅历的开发者的代码来挂念训练他们。 通过让审查者和被审查者相互呈现好的想法和做法以促进学问共享。 鼓舞开发者在他们的工作中愈加尽心尽力，由于他们晓得本人的代码将来要被他们的的某个同事审查。 做彻底深化的审查 不过，假如不在审查工作上倾注肯定的时间和精力，这些目标都是无法实现的。仅仅滚动扫瞄下patch，确保缩进正确、全部的变量实行小骆驼拼写法并不能构成一次彻底的审查。遭到业界的启发也可以考虑结对编程，这是一个相当流行的做法，但也在全部的开发时间上添加了100%的额外开销来作为代码审查工作的基准。你可能会在代码审查中花费很多时间，但与结对编程相比，使用的总体工程时间仍少得多。 我认为花在代码审查工作上的时间应当是原开发时间的25%左右。例如，假如一个开发者花两天时间实现了个小项目，那么审查者应当花大致4个小时的时间来审查它。 当然，花在审查工作上多少时间并不是最重要的，只需审查能够精确?????无误的完成即可。特殊地，你必需要能理解你正在审查的代码。这不只仅意味着你只需懂该代码所接受言语的语法即可，它还意味着你必需了解该代码如何顺应于更大的应用环境、组件或库下。假如你不抓住每一行代码的全部含义，那么你的审查就不是格外有价值的。这也是为什么好的审查都不行能格外快的完成：由于还要花时间去调查触发某个给定函数的不同代码路径，要去确保第三方API能够正确使用（包括任何边缘情况），等等。 除了查找你所审查的代码中的瑕疵或其它问题之外，你还应当确保： 包含全部必要的测试。 合适的设计文档已经写完。 甚至擅长写测试和文档的开发人员也并不总能记得在代码改动之后准时更新。在适当的时候来自代码审查人员的微小调整对于确保代码在随着时间的推移不会变质是至关重要的。 防止代码审查工作超负荷 假如你的团队强制要求做代码审查，那这是有风险的，由于你的代码审查工作可能一直积压，最终到无法管理的地步。假如你两周之内不做任何审查工作，你可以很简约的花上几天时间来赶补它。不过这也意味着当你最终打算去处理它们的时候，你本人的开发工作将遭到肯定的不测搁浅。这也使得做好审查工作愈加困难，由于正确的代码审查需要猛烈、持续的脑力劳动，很难这样数日保持下去。 因而，开发者每天应当竭尽全力的清空他们的审查积压工作。一个方法是晚上的第一件事情就用来处理审查工作。在开头本人的开发工作之前先做完全部的优秀审查工作，你可以防止以后的审查局面失控情况。有些人更宠爱在午休之前或之后或在一天结束后做审查工作。无论你什么时候做这些事情，通过将代码审查作为正轨的日常工作而不是作为一种分散留意力的工作，你可以避开： 没有时间处理你的审查积压工作。 由于你的审查工作还没做完而延迟项目的发布。 做出一些不再相关的审查，由于在此期间代码已经改动的格外多。 由于赶在最终一分钟处理它们而导致审查工作最终完成的很差。 写易于审查的代码 无法管理的审查积压工作也不能全怪审查人员。假如我的同事不管三七二十一的花费一周的时间来给一个大工程项目添加代码，那么他们发布的patch将真的很难审查，由于在一个阶段里有太多的工作要处理，代码的目的和底层架构体系也会很难理解。 这是将你的工作切割为一个个可管理单元之所以格外重要的众多缘由之一，我们使用scrum管理方法，所以对我们来说合适的单元是重点。通过一起努力，用单元来组织我们的工作，并提交仅与我们正在进行的某个单元相关的审查，我们可以写出愈加易于审查的代码。你的团队可能使用另一种管理方法，但是准绳都是一样的。 为了写出易于审查的代码，还有一些其它的必备条件。假如要做出一些很麻烦的架构决策，为满足审查者的要求，事先进行争辩是合理的。这将使得审查者愈加简约的理解你的代码，由于他们将晓得你在代码中试着达到什么目的以及怎样方案来达到该目的。这也有助于避开这样一种情况：在审查者提出一个不同的更好的方法后，你必需要重写你的大段代码。 在你的设计文档里项目架构应当要具体的描述。这无论如何都是很重要的，由于它能让一个新的项目成员很快的赶上进度并理解现有的代码库。它还能挂念审查者更好的做好本人的工作，这是另一个好处。单元测试也有助于向审查者说明组件应当如何使用。 假如你的patch里包含了第三方代码，请单独提交。例如当jQuery的9000行代码被插入代码两头时，要做好代码审查工作就难上加