Millions of years ago, human ancestors, orangutans, learned to walk upright—freeing their hands—and eventually evolved into humans; code reviews have the same effect in the development process—distinguish between savage development and advanced development.
However, in practice, the following sounds are always heard:
- "Code reviews are a waste of time on projects!"
- "I don't have time for a review at all."
- "Because my cautious partner hasn't done the review, the progress can only be delayed."
- "Are you sure, my colleagues asked me to change the code? Please explain to them that any slight changes will take away the elegance of my code."
So the question is, why do we need to do code review? As a professional software developer, continuous improvement of code quality is one of the goals that I constantly pursue in my working life. No matter how good we are, we are inseparable from the team; and code review is the lubricant of the individual and the team:
- Father, like son. Code review is like installing a rearview mirror for us;
- Make our code at least one more bosom friend;
- It can help new employees learn and understand the code essence of their predecessors in the process;
- It will help to carry out knowledge sharing, and the "wisdom" of the public will become a city.
If you want to achieve the above-mentioned good results, it is inseparable from the scientific arrangement of time and work. Just doing basic work such as code indentation and variable naming conventions is not perfect. And if you've ever tried pair programming, you've probably found that it often takes more time than code review. My suggestion is to spend a quarter of the total open time for code reviews. For example, if the total development time is two days, the review should take about four hours. Of course, if you can do things right, you don't have to be limited by the amount of time. Further, we must be able to understand the code that will be reviewed. This not only means mastering the basic language syntax, but more importantly, mastering the structure of the entire code, the components or libraries used and other details. There is little value in review work without knowing what each line of code is doing. So to do this well, you can't just focus on speed, you must spend some effort to sort out and analyze the code from beginning to end. There are two more things that must be done:
- All necessary testing work is included in the review work;
- Do a good job in the preparation of design documents.
避免拖延症
今天的工作今天完成是最完美的工作状态，否则一旦拖延症出现，再多再好的复查都只会成为开发过程中的绊脚石。好的复查需要紧密而持久的努力，不是搞搞突击就能做好的。
因此，开发者应当尽力做到日清日结。把复查作为每天工作的开端是个不错的主意；理清旧的思路将有助于开展新的编码任务。也或许有的人喜欢在午休或下班前进行，无论在什么时候进行，以下几点是应该避免的：
- 让积压工作越积越多；
- 由于复查没有做好而导致进度延后；
- 由于代码更新频率快就放弃做复查；
- 往往在最后一刻才去做复查。
编写出可复查的代码
不应该把所有复查工作都推给复查员。如果我的同事花了一周时间添加了看起来比较乱的代码，这对复查工作无疑是重大打击，也很难让人摸清其思路和结构。
所以我们在编程时，要有意识地把代码划分为可操作单元。我们使用的方法是scrum，它为我们的开发工作做了很明晰的指导，同时使得整个开发过程有迹可循，便于进行追溯和回顾。
其次，在与复查员进行讨论前要搞好关系。这样将有助于双方对彼此有所了解，从而减少讨论时矛盾发生的机率。
再者，项目结构应当在设计文档中描述得清楚具体。这对于项目新成员的成长是大有裨益的，同时能帮助复查员提高工作效率。
最后也是最重要的一点是在自我复查过程中做好注释。换言之要先自行对代码过一遍，把需要做出说明的地方标示出来并解释清楚。有研究表明，开发者在对自己的进行复查和注释时，经常会找出不少瑕疵。
大型代码重构
有时候如果需要进行代码重构，这势必会影响到很多组件，特别是较大型的应用。在这种情况下，最好的解决方案是逐步推进重构工作。先对要做的变更进行划分，然后根据修改意图进行分段式重构。当这部分变更完成并做好复查后，再执行第二部分的重构，重复该步骤直至完成全部工作。这或许增加了重构用时，但会带来更高质量的代码同时可以减轻复查员的工作量。
如果实际情况真的不允许进行逐步重构，可以试试结对编程。
解决矛盾
在一个技术团队中，各人有各自的观点，如何达成共识是成败的关键。作为开发者，应该保持开明的心态并虚心接受不同的意见。避免固步自封，避免对自我复查工作的不屑一顾。如果有人提议把我们一些重复的代码做成一个可复用函数，这并不代表我们之前的工作是毫无价值的。
而作为复查员，要懂得人情世故。在给出修改意见前，先考虑清楚这真的会更好抑或仅仅是风格上的不同看法。提议说法可以是：“如果尝试另一种方法，或许会更好”或“有同事建议这样做”，而要避免的是：“就连我家宠物都能写出比这好的算法！”
如果真的一时僵持不下，争议双方不妨请教第三个开发人员，从他的角度来再次审度各自的观点，直到形成共识，三人行，必有我师焉。
from http://www.iteye.com/news/30155