code review （一）

有 review code 的地方真不错。当然要人好才行。要不冲突多多了。

【转载】

-------------------------

Code Review

做软件开发的时间转眼也有三年有余，所在的团队也使用了各种各样的代码质量控制方法，个人觉得Code Review是一个最有效的方法，同时也是“性价比”最高的代码质量控制方法。现将个人的一些观点和看法总结一下

什么是Code Review

Code Review 中文的翻译方式有很多种“代码审查”，“代码评审”，“代码走查”等，个人更喜欢“代码走查”这种翻译。代码走查是一个流程，从开发人员在一个开发阶段写好代码后开始，之后需要别人以发现bug和技术交流为目的review一下他的代码。它是集代码审查，找出问题，改进代码和改后督查为一体的完整的流程。代码走查一般在代码刚刚出炉为最好，因为在这个时候也是代码重构和调整的最佳时候。

Code Review的目的及内容

功能性Review:

通过Review检查当前代码是否全部实现了需求里面全部的功能点，且功能正确。找出代码中的bug，每个人在写和读代码的时候都有固有的习惯，这样的一些习惯往往会影响代码的质量。比如：我们在代码编写过程中都出现过类似的问题，自己代码中的问题自己无论看了多少遍都发现不了，但别人一眼就能发现问题。出现这样的情况并不是说写代码的人水平不高而是个人编程中的“无意识”错误。当然这也就是结队编程的妙处。

可读性Review:

代码做为软件开发过程中最实时的文档，同时为了以后维护方便一定要有高度的可读性。可读性检查主要检查代码风格是否严格按照系统代码风格规定，代码中是否经过充分的重构消除了其中冗余重复的代码。代码结构是否合理。

分享技术知识：

“三人行必有我师”每个人的代码都有值得别人学习的地方，而且团队中各个成员水平高低不一，通过代码Review使水平高的人的技术逐渐流向水平低的人培养了新人。同时代码编写者向团队中的其他人介绍自己所用的技术和方法，这样一方面使各种技术在团队中得到共享。笔者在当前的公司里面遇到这样一个案例：

团队1在之前的项目开发中用到freetype做中文排版，但是当时没有做代码review。之后团队2也用到了freetype方面的知识但因为不知道团队1有freetype方面的知识，结果团队2又花费了大量的时间和精力去重新研究和学习freetype。这样大大延缓了项目的时间进度。

互为backup：

通过代码Review使更多的人了解当前模块的功能，这样减少了因人员流失而导致对项目产生的冲击。

-----------------------------

百度百科：

代码评审是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找系统缺陷，保证软件总体质量和提高开发者自身水平。 Code Review是轻量级代码评审，相对于正式代码评审，轻量级代码评审所需要的各种成本要明显低的多，如果流程正确，它可以起到更加积极的效果。正因如此，轻量级代码评审经常性得被引入到软件开发过程中。

Why we do Code Review(为什么进行)

1、提高质量

2、及早发现潜在缺陷与BUG，降低事故成本。

3、促进团队内部知识共享，提高团队整体水平

4、评审过程对于评审人员来说，也是一种思路重构的过程。帮助更多的人理解系统。

Practice of Code Review(代码评审实践)

代码评审不是批斗会，不能以缺陷和错误来打击开发人员的积极性评审的目标的提高质量和提高整体水平，作者应该带着学习和提高的态度来参加评审。

代码集体所有制：对发现的问题要本着整体承担责任 的原则，因此建议把代码质量与团队绩效（而不是个人绩效）挂钩。

评审程度，进行一次整体的地毯式的评审成本很高。

代码评审的可操作性，首先需要评审团队具备经验丰富的系统架构师和精通业务的行业专家。其次团队需建立其开发规范或指南，在项目初期建立少量的Sample代码与checklist为评审提供依据。

评审人员的职责是发现工作成果中的缺陷，并帮助开发人员给出消除缺陷的办法，而不是替开发人员消除缺陷 。

记录评审中出现的问题，跟踪改进。

评审前充分准备，评审后详细总结。

不要因为时间和成本问题取消评审。

------------------------------------

另一转载：

-----------------------------------

这篇文章就是关于它们的：代码审查中的陷阱和误解。

代码控制：

很 多公司都把代码审查当成控制代码的方法。很多这样的公司都使用预提交策略。这种策略大多时候都是开源项目中使用，因为会有成百上千的提交者。可在一般的公 司里，很少会有这种情况。如果你雇用一个人，这意味这你要完全信任他，允许他将代码提交到代码库里。我知道有些公司会忍不住制定一些规程，要求程序员在提 交代码前必须进行“审查”和“批准”，但这并不能保证代码的质量。而且，程序员很快就会把这种代码审查当作一种“愚蠢”的公司形式过程，会开始抵制它(例 如，每月改一次密码。例如，使用像mypass1,mypass2等的密码)。

审判厅：

不 要把代码审查当成寻找替罪羊和追究责任的工具。比如说，这有一个错误，你找到“审查”这段代码的人，并责备他没有发现这个问题。这种事情会给公司里的开发 工作带来严重的影响。人们会挑出每个分号放置不正确的地方，因为他们担心会被当成替罪羊。团队成员开始缺乏信心，并最终失去互信。

责任任务：

不要过分要求程序员做代码审查。如果你强迫他们每天做一小时的代码审查，他们很快就会痛恨它，把它当成一种无趣的任务。代码审查是一种学习，是表扬，是获得反馈，是一种十分社交性的活动。代码审查应该是有趣的，不要让它变的无聊。

我和我的代码

如 果你的代码被某人审查，他会留下一些注释(有时是不那么友好的话)，不要生气。他并不是在说你是一个很烂的程序员。这不是他的本意，也不是代码审查的目 的。他的所作所为是在批评代码(而不是作者)。代码审查是针对代码，不是针对你。不要把代码审查当成互相讽刺的论坛和相互批判的工具。当你写审查注释时， 努力保持不要粗鲁，也不要太苛刻。努力站在作者的立场上看待这些代码。

总结一下，很多种错误都会使代码审查变味。上面4种是我经历过或预料到的，请警惕。我承诺还会写一篇描述“代码审查是来…..”的文章。

如果你想尝试一种代码审查工具，请访问codebrag.com，这是我们的经验和实践的成果。

-----------------------------------

另二转载

-----------------------------------

本文简要描述了Review Board、Jupiter、JCR、Codestriker、Rietveld几种开源代码评审工具的功能特点，并介绍了在windows下的安装步骤。如您想使用Web方式进行代码评审，推荐安装Review Board，如您想在Eclipse中进行代码评审请安装Jupiter。

-----------------------------------