|
--> Google是一个十分优良的公司。他们做出了许多令人称颂的东西—既是公司外部，人们能够看到的东西，也是公司内部。有一些在公司内部并不属于保密的事情，在外部并没有给予足够普遍的探讨。这就是我今天要说的。 让Google的程序如此优秀的一个最重要的事情看起来是无比的简略：代码审查。并不是只有Google做这个事情—代码审查已经被广泛的认可为一种异常好的做法，很多人都在这样做。但我还没有看到第二家这样大的公司能把这种事情应用的如斯广泛。在Google，没有程序，任何产品、任何项目标程序代码，可以在没有经过有效的代码审查条件交到代码库里的。 所有人都要经由代码审查。并且很正规的：这种事情应当成为任何重要的软件开发工作中一个基础轨制。并不单指产品程序——所有货色。它不须要良多的工作，但它的后果是宏大的。 从代码审查里能得到什么？ 很显然：在代码提交前，用第二群眼睛检查一遍，避免bug混入。这是对其最常见的懂得，是对代码审查的利益的最广泛的意识。然而，依我的教训来看，这反倒是它最不重要的一点。人们确切在代码审查中找到了bug。可是，这些在代码审查中能发现的绝大局部bug，很显然，都是微不足道的bug，程序的作者花多少分钟的时间就能发现它们。真正需要花时间去发现的bug不是在代码审查里能找到的。 代码审查的最大的功能是纯社会性的。假如你在编程，而且知道将会有共事检讨你的代码，你编程立场就完整不一样了。你写出的代码将更加整齐，有更好的解释，更好的程序构造——由于你晓得，那个你很在意的人将会查看你的程序。不代码审查，你知道人们终极仍是会看你的程序。但这种事件不是即时产生的事，它不会给你带来等同的紧急感，它不会给你雷同的个人评判的那种感触。 还有一个非常重要的好处。代码审查能传布常识。在很多的开发团队里，常常每一个人负责一个中心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不彼此交换。这种情形的成果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或——但愿不是——辞职了，其余人则一筹莫展。通过代码审查，至少会有两个人熟习这些程序——作者，以及审查者。审查者并不能像程序的作者一样对程序非常懂得——但他会熟悉程序的设计和架构，这是极其重要的。 当然，没有什么事情能简单的做下来的。依我的经验，在你能正确的进行代码审查前，你需要花时间锤炼学习。我发现人们在代码审查时时常会犯一些错误，导致不少麻烦——尤其在一些缺少经验的审查者中常常的呈现，他们给了人们一个很遭的代码审查的休会，成为了人们接收代码审查制度的一个阻碍。 最主要的一个准则：代码审查用意是在代码提交前找到其中的问题——你要发明是它的准确。在代码审查中最常犯的过错——简直每个新手都会犯的毛病——是，审查者依据本人的编程习惯来评判断人的代码。 对于一个问题，通常咱们能找出十几种方式去解决。对一种解决方案，我们能有百万种编码方案来实现它。作为一个审查者，你的义务不是来确保被审查的代码都采取的是你的编码作风——因为它不可能跟你写的一样。作为一段代码的审查者的任务是确保由作者自己写出的代码是正确的。一旦这个原则被攻破，你最终将会倍感折磨，深受挫折——这可不是我们想要的结果。 问题在于，这种错误是如此的普遍而易犯。如果你是个程序员，当你碰到一个问题，你能想到一种解决计划——你就把你想到的方案作为尺度谜底。但事情不是这样的——作为一个好的审查者，你需要清楚这个情理。 代码审查的第二个易犯的弊病是，人们感到有压力，感到非要说点什么才好。你知道作者用了大批的时光跟精神来实现这些程序——不该说点什么吗？ 不，你不需要。 只说一句“哇，不错呀”，任何时候都不会分歧适。如果你老是力求找出一点什么东西来批驳，你这样做的成果只会侵害自己的权威。当你不厌其烦的找出一些东西来，只是为了说些什么，被审查人就会知道，你说这些话只是为了弥补安静。你的评论将不再被人器重。 第三是速度。你不能促忙忙的进行一次代码审查——但你也要能敏捷的完成。你的错误在等你。如果你和你的同事并不想花太多时间进行代码复查，你们很快的实现，那被审查者会认为很懊丧，这种代码审查带来的只有扫兴的感觉。就好象是打扰了大家，使大家放下手头的工作来进行审查。事情不该是这样。你并不需要推掉手头上的任何事情来做代码审查。但如果半途延误了几个小时，你旁边还要休息一会，喝杯茶，冲个澡，或谈会儿闲话。当你回到审查现场，你可以持续下去，把事情做完。如果你真是这样，我想没有乐意在那干等着你。 相关的主题文章： (责任编辑：admin) |