转载:http://www.iteye.com/news/22272
Google的代码之所以优秀原因其实很简单:他们非常重视代码审查。代码审查并不是Google独有的,它被公认为是一个很好的(提高代码质量的)手段,很多人已经在日常开发中采用代码审查。但我还没有看到哪一家大公司(像谷歌这样)应用得如此广泛。在谷歌,任何的产品或者项目代码在检入(代码仓库)之前都需要进行有效的审查。
每个人都要参与代码审查,而且这里我指的不是非正式的审查:它是软件开发环节中非常重要而且通用的规则。不仅是产品代码,所有的代码都需要进行审查。审查代码不需要投入很多的精力,但是(与不做审查相比)产生的效果却是天壤之别。
关于代码审查(code review),Jonathan Danylko 的看法是“代码要经常检查(包括自查和其他同事检查)。不要把别人的检查,看成是对代码风格的苛求。应该把它们看作是有建设性的批评。对个人来说,经常检查你的代码并且自问,“我怎样才能写得更好呢?” 这会加速你的成长,让你成为一个更优秀的程序员。”
你能从代码审查中收获什么?
事实显而易见,有另外一个人检查即将提交的代码,能够帮助找到bug。这是代码审查众所周知且经常被提及的好处。但依据我的经验,这是最没有价值的一个好处。人们确实可以在代码审查中找到bug。然而坦率地说,在代码审查中找到的bug绝大多数都是一些代码作者花上几分钟就能找到的小bug。那些真正 需要花时间才能找到的bug在代码审查中是检查不到的。
代码审查最大的好处在于它是一种社交的途径。如果你编程的时候就知道会有同事检查你的代码,那么你的程序会有所不同。你写的代 码会更加整洁,有着较好的注释,结构也组织的不错——因为你知道会有人来检查你的代码,而且你很在意他们的意见。如果没有代码审查,你知道代码会在最后才 会审查。因为不是马上就要检查,所以对你而言并不紧迫,因而你不会想着先自检一遍。
代码审查还有一个更大的好处,就是可以分享知识。在很多的开发团队中,每个人都会负责并且专注于一个核心模块。除非别的同事负 责的模块出现问题导致自己的代码不能运行,否则他们是不会去关注别人的工作。这样产生的结果是,每一个模块的代码只有一个人比较熟悉。假如事不凑巧,那位 程序员正好休假或者离开了公司,那么没有人了解那些代码了。如果有代码审查的环节,那么至少会有两个人熟悉代码——代码的作者和审阅者。审阅者虽然没有作 者对代码那么了解——但是他同样熟悉代码的设计和结构,这些信息是无价之宝。
当然,没有什么事情是那么简单的。以我的的经验看来,要做好代码审查需要一段时间练习。我注意到经验不足的审阅者通常会落入一些代码审查的陷阱,这些 陷阱往往会造成很多的麻烦,给那些希望尝试代码审查的人们留下了坏印象,成为了他们采纳代码审查的一个主要障碍。
代码审查最重要规则是对即将提交的代码中查找问题——你需要做的就是确认代码是正确的。而通常会犯的一个错误,也是刚刚接触代码审查的新手容易犯的一个错误,即审阅者会判断这段代码是否按照自己思路来实现(误区一)。
当有一个问题需要解决时,通常会有几十种的办法。当选定一个解决方法时,会有百万种代码实现。因此,作为一个审阅者,你的工作不是确保代码是按照你的方式来编写的——因为这是不可能的事情。审阅者的工作是确保原作者编写的代码是正确的。如果你没有遵守这个规则,你可能会到处碰壁,审查结束时你的心情很 糟糕,对你来说肯定不是一件好事情。
问题在于这是不自觉就会犯的一个错误。假定你是一个程序员,当你在看一个问题的时候,你会得到一个自己的解决方案——并且你认为你看到的就是这个问题(应该采用的)解决办法。如果想要成为一名好的审查者,你需要知道这是不对的。
第二个误区就是人们感觉一定要说点什么(才算是做了代码审查)。代码的作者花了很多的时间和精力来编写代码——你难道不应该说点什么吗?
答案是:你不应该。
如果只是说“哦,这看起来这不错!”,这永远没错。反之,如果你不断地去查找一些“问题”并加以指责,那么我肯定你的信誉会荡然无存。如果你不断地去制造一些事情来说些什么,那么代码的作者会认为,当你的言论只是为了避免冷场。从此,你的意见不会受到重视。
第三个误区就是速度。你不应该匆忙完成一次代码审查——但是也不要拖延。你的同事在那里等着你的审查结果。如果你和同事不愿意 抽出时间来做代码审查或者一直拖延,大家会对这次的审查感到厌烦,也会认为以后的代码审查也只会带来麻烦。看起来好像代码审查会打断你的工作,其实不必如 此。你不必要在别人要求你审查的时候马上丢掉手头上的事情。但是在几个小时之内,当你工作中间休息的时候——喝杯茶,去一下洗手间或者聊聊天,散散步。当 你再回来工作的时候,你可以开始并完成这个代码审查。如果你这么做了,没有人会站在你身边一直等着你给出审查结果。
分享到:
相关推荐
这样不仅便于自己回顾,也利于团队协作和代码审查。 5. 不善于利用社区资源:Python拥有活跃的开源社区,提供大量的学习资料和优秀项目。开发者应积极利用这些资源,如阅读官方文档,参与Stack Overflow问答,关注...
此外,书还附有C++/C代码审查表、试题和答案,作为实践和自我评估的工具。 通过阅读这本书,程序员不仅可以提升编程技能,还能理解并遵循高质量编程的标准,从而编写出更可靠、可维护的C/C++程序。
- **操作指南:** 定期进行代码审查,去除冗余代码,确保每一段代码都是精炼且必要的。 **4. 避免直接使用硬编码值:** - **背景介绍:** 硬编码值难以维护且容易出错,在多处修改时尤其麻烦。 - **解决策略:** ...
5. 常量方面,作者解释了常量的必要性,比较了CONST和#DEFINE的差异,提出了常量定义规则,并讨论了类中常量的使用。 6. 函数设计方面,书中涵盖了参数规则、返回值规则、函数内部实现规则、使用断言、引用与指针的...
最后,书中还包含了一些其它的编程经验,比如使用const提高函数的健壮性、提高程序效率的方法和一些有益的编程建议,以及参考文献、附录A的代码审查表、附录B和C的试题及其答案与评分标准,为读者提供了学习和实践的...
2. **时间管理**:专家建议合理安排时间进行保养,这对于软件开发者来说意味着制定定期的代码审查、性能监控和维护计划。定期的代码审计可以帮助发现潜在的问题,性能监控有助于了解软件在不同条件下的表现,以便...
- **静态测试**: 不运行程序的情况下进行的测试,包括代码审查、走查、桌面检查等。 - **代码审查**: 由一组人员对代码进行仔细检查,寻找潜在的问题。 - **走查**: 类似于代码审查,但通常会有一个主持人引导整个...
1. **代码审查**:通过代码审查,团队成员可以相互学习和改进。利用像Git的Pull Request机制进行code review,关注代码设计和风格,而非仅仅关注语法错误或业务逻辑。 2. **重构**:定期重构代码以保持其整洁和高效...
逻辑错误是程序员在实现功能时的思维误区,可能需要通过单元测试和代码审查来发现并修复。并发问题,如死锁、竞态条件,往往在多线程或多进程环境中出现,需要熟悉并发控制机制,如互斥锁、信号量等来解决。资源泄漏...
1. **验证代码逻辑**:编写和执行单元测试是对代码逻辑进行审查和验证的过程,确保代码按照预期运行。 2. **减少代码缺陷**:通过单元测试,可以确保每个独立模块的正确性,从而减少整体项目的bug。 3. **促进代码...
- **代码审查**:定期进行代码审查,确保代码质量。 - **版本控制**:使用如Git等版本控制系统管理代码变更。 - **Bug追踪**:采用Bug追踪系统记录和追踪问题。 - **自动化工具**:引入自动化测试和构建工具,提高...
- **常量的必要性**:使用常量代替硬编码的数值可以提高代码的可维护性和可读性。 - **CONST与#DEFINE**:`const`关键字用于声明常量,而`#define`用于预处理器宏定义,两者在功能上有区别,应根据具体情况选择使用...
函数内部实现时,要在入口和出口处进行参数有效性检查和return语句的审查。函数应单一职责,小规模,避免记忆功能,检查所有输入参数和可能影响函数的外部变量的有效性。 总的来说,C++编程规范旨在通过一系列的...
- **代码重构**:定期审查代码,进行必要的重构以提高代码质量。 - **跨平台开发**:了解不同操作系统间的差异,确保程序能够在多个平台上稳定运行。 总之,学习C++并非易事,需要耐心和持之以恒的努力。通过正确的...
- **代码审查:** 定期进行代码审查,以确保代码质量。 #### 常见错误10:无视(久经考验的)习惯用法 **知识点:** - **定义与理解:** 习惯用法指的是在C++社区中广为接受和推荐的做法,这些做法通常是经过长期...