代码走读

本文转载自：http://blog.csdn.net/marchbirdcode/article/details/4801978

如需看原文，请看上面的链接。

 

从种种渠道可以知道，Google的代码之所以优秀，原因很简单，他们非常重视代码审查。这个方法不是Google独有的，它被公认是一个提高代码质量的手段。在Google，任何产品或者项目代码在捡入仓库之前，都需要进行有效的审查。

每个人，如果有意愿的话，都要参加代码审查，它是软件开发环节中非常重要而且通用的规则。审查代码，不需要投入很多精力，但是，与不做审查相比，产生的效果却是天壤之别。我们越早发现代码存在的缺陷，解决缺陷的代价就越低。

不要把别人的检查，看成是对代码风格的苛求。

对个人来说，经常检查你的代码并且自问“我怎样才能写的更好？”这会加速你的成长。

 

你能从代码审查中收获什么？
　　事实显而易见，有另外一个人检查即将提交的代码，能够帮助找到bug。这是代码审查众所周知且经常被提及的好处。但依据我的经验，这是最没有价值的一个好处。人们确实可以在代码审查中找到bug。然而坦率地说，在代码审查中找到的bug绝大多数都是一些代码作者花上几分钟就能找到的小bug。那些真正需要花时间才能找到的bug在代码审查中是检查不到的。

自己的看法：在审查前，自己肯定是检查过一次，显而易见的Bug是不出现在审查代码中。鉴于审查时间的长短，被审查者收获什么，别人对自己思路的认同？别人对自己代码的看法？我觉的，应该由被审查者先讲述自己这段代码要解决什么问题，采用了什么样的方法，然后再给别人看流程图，最后结合流程图看代码。
　　代码审查最大的好处在于它是一种社交的途径。如果你编程的时候就知道会有同事检查你的代码，那么你的程序会有所不同。你写的代码会更加整洁，有着较好的注释，结构也组织的不错——因为你知道会有人来检查你的代码，而且你很在意他们的意见。如果没有代码审查，你知道代码会在最后才会审查。因为不是马上就要检查，所以对你而言并不紧迫，因而你不会想着先自检一遍。

自己的看法：代码审查的时机？是解决完一个问题就审查还是在入库时才审查？我觉的应该是在入库时来审查，鉴于部门人数众多，一一审查是不可能的，可以采取每周抽查两个人，在整个部门中，由他们来讲解自己代码中的一部分，感兴趣的人都来听。其余的入库，只需要和自己的上司提交审查请求就可以了，每周至少保持一次。
　　代码审查还有一个更大的好处，就是可以分享知识。在很多的开发团队中，每个人都会负责并且专注于一个核心模块。除非别的同事负责的模块出现问题导致自己的代码不能运行，否则他们是不会去关注别人的工作。这样产生的结果是，每一个模块的代码只有一个人比较熟悉。假如事不凑巧，那位程序员正好休假或者离开了公司，那么没有人了解那些代码了。如果有代码审查的环节，那么至少会有两个人熟悉代码——代码的作者和审阅者。审阅者虽然没有作者对代码那么了解——但是他同样熟悉代码的设计和结构，这些信息是无价之宝。
　　当然，没有什么事情是那么简单的。以我的的经验看来，要做好代码审查需要一段时间练习。我注意到经验不足的审阅者通常会落入一些代码审查的陷阱，这些陷阱往往会造成很多的麻烦，给那些希望尝试代码审查的人们留下了坏印象，成为了他们采纳代码审查的一个主要障碍。
　　代码审查最重要规则是对即将提交的代码中查找问题——你需要做的就是确认代码是正确的。而通常会犯的一个错误，即审阅者会判断这段代码是否按照自己思路来实现。
　　当有一个问题需要解决时，通常会有几十种的办法。当选定一个解决方法时，会有百万种代码实现。因此，作为一个审阅者，你的工作不是确保代码是按照你的方式来编写的——因为这是不可能的事情。审阅者的工作是确保原作者编写的代码是正确的。如果你没有遵守这个规则，你可能会到处碰壁，审查结束时你的心情很糟糕，对你来说肯定不是一件好事情。
　　问题在于这是不自觉就会犯的一个错误。假定你是一个程序员，当你在看一个问题的时候，你会得到一个自己的解决方案——并且你认为你看到的就是这个问题（应该采用的）解决办法。如果想要成为一名好的审查者，你需要知道这是不对的。
　　第二个误区就是人们感觉一定要说点什么（才算是做了代码审查）。

代码的作者花了很多的时间和精力来编写代码——你难道不应该说点什么吗？
　　答案是：你不应该。
　　如果只是说“哦，这看起来这不错！”，这永远没错。反之，如果你不断地去查找一些“问题”并加以指责，那么我肯定你的信誉会荡然无存。如果你不断地去制造一些事情来说些什么，那么代码的作者会认为，当你的言论只是为了避免冷场。从此，你的意见不会受到重视。

自己的看法：在审查过程中，多提问题，不要把自己想的那一套强加在别人身上，以提问的方式，来了解别人的设计思路和策略，这就像，一人一个想法，相互交换了，每个人就有了两个想法，思路也是一样的，尊重别人的思维成果，即使它还不完善，还有漏洞。
　　第三个误区就是速度。

你不应该匆忙完成一次代码审查——但是也不要拖延。

你的同事在那里等着你的审查结果。如果你和同事不愿意抽出时间来做代码审查或者一直拖延，大家会对这次的审查感到厌烦，也会认为以后的代码审查也只会带来麻烦。看起来好像代码审查会打断你的工作，其实不必如此。你不必要在别人要求你审查的时候马上丢掉手头上的事情。但是在几个小时之内，当你工作中间休息的时候——喝杯茶，去一下洗手间或者聊聊天，散散步。当你再回来工作的时候，你可以开始并完成这个代码审查。如果你这么做了，没有人会站在你身边一直等着你给出审查结果。

自己的看法：在部门的代码审查上，建议时间保持在30分钟左右，第一，不要浪费大家的时间.第二，３０分钟，１０分钟讲思路和流程图，１０分钟介绍代码，还有１０分钟接收提问。这样的时间分配，应该还是比较合理的。在个人的代码审查上，时间因人而定，能够疏通逻辑、答疑解惑一两个点就可以了。

-------------------------------10-17更新分割线-------------------------------------------

本次更新来自：代码走读常规流程

代码审查的内容：代码风格、常规缺陷、业务逻辑缺陷、设计逻辑和思路的审查。

审查原则是确保正确性、可复用性、可扩展性、可维护性和可读性。

理解代码的意图和发现问题，这两件事情，前一件要在开始之前，通过某种方式告知参与人员，先按自己的思路理解程序的逻辑，然后标注出找出的问题并且记录下来。

可能下面的需要一定的专业工具来审查，我不是特别了解，希望以后的公司，能够有这种好的确保质量的规范制度。