Why perform a code review
1. The biggest benefit of code review is purely social. When you know that every line of your code is viewed by another person, you will naturally perform more diligently and come up with the best state coding, because everyone has vanity. Well;
2. The code review can find some bugs that are easy to find in time without having to postpone the time of finding bugs to the testing stage;
3. Code reviews ensure that at least two people understand any piece of code. When employees take leave, leave, etc., at least ensure that the team's code will not fall into a situation that no one understands or handles.
Process
There are two types of code review processes:
1. Pre-push code review
2. Post-push code review
The pre-submission review process is as follows:
1. Before attempting to submit code changes to the code base, programmers submit a change application, which includes the content of this change, reviewer;
2. The reviewer checks the content of the change, evaluates the change, communicates with the change applicant, and evaluates whether the change is passed;
3. If the reviewer passes the change, the change applicant can submit the code to the code base;
4. If the reviewer does not pass the change, the applicant for the change needs to make changes according to the discussion results or review suggestions, and the code can be submitted to the code base until an agreement is reached with the reviewer and the review is passed;
The post-submission review process is as follows:
1. The programmer submits the changed code to the code base;
2. The reviewer reviews the content of the change, and if the review passes, mark the change as reviewed;
3. If the reviewer has doubts, communicate with the changer, and the changer will make revisions based on the discussion results or review comments, until they reach an agreement with the reviewer and pass the review.
pre-push code review vs post-push codereview
Google and Facebook both strictly implement pre-pushcode review. Pre-submission reviews have many advantages over post-submission reviews:
1. Programmers will be more active in organizing the changed code better, more modular, and easier to read;
2. Reviewers have the opportunity to find problems before the code is submitted, or give better suggestions, and the corresponding programmers are more receptive to such feedback;
3. After the reviewer gives a suggestion or opinion, the programmer will respond more positively to the feedback than the post-submission review;
4. The reviewers will review the changes more seriously, and will participate more actively in discussions after discovering problems, and provide support to the programmers who initiated the changes;
5. It is obviously better to find and fix the problem before actually submitting the change than to review it after submitting it, and then submit the revised patch;
Benefits of post-push code review:
1. It is generally believed that post-push code review has almost no benefits over pre-push code review!
2. However, post-push code review is easier to implement, the process does not completely subvert the existing organizational structure and process, and the requirements for team members are not so high;
3. Compared with pre-push code review, post-push code review does not need to interrupt the process of modifying code & submitting changes, and does not need to wait for review time;
4. It can be used as a transition training for the organization to implement the pre-push code review process;
Tools
Introducing Phabricator, Facebook's code review tool
One of the reasons for using phabricator touched me: phabricator is considered one of the 11 important factors or tools for Facebook's success, and Facebook's engineers praised this tool.
Phabricator has been open sourced and can be downloaded from github.
phabricator supports both pre-push code review and post-push code review processes, differential and audit, respectively.
Don't worry about phabricator being a heavyweight tool just because it's a Facebook product. In fact, it fully supports small team development, and even two-person teams can use it for code reviews.
The installation and configuration of Phabricator will not be introduced, refer to
http://www.phabricator.com/docs/phabricator/index.html
There are some configuration options in the middle that need attention, especially when configuring the arc tool and configuring the repository, localization and the root directory of svn and other related details.
If there is any problem during installation, configuration and use, please leave a message or private message on Weibo to discuss.
Best Practices:
Important advice from Google engineers:
(Reference here: http://www.aqee.net/things-everyone-should-do-code-review/)
One of the most important principles: Code review is about finding problems in code before committing - you have to find that it's correct. The most common mistake made in code reviews -- a mistake almost every newbie makes -- is that reviewers judge other people's code based on their own programming habits.
For a problem, usually we can find more than a dozen ways to solve it. For a solution, we can have a million encoding schemes to implement it. As a reviewer, your job is not to make sure that the code being reviewed is your coding style - because it can't possibly be the same as what you wrote. The job of a reviewer of a piece of code is to ensure that the code written by the author himself is correct. Once this principle is broken, you will end up being tortured and frustrated—not what we want.
ps: I have seen many programmers who have mental cleanliness and always ask others to design or code according to standard formats and standard ideas. You must know that programs are creative work. Programmers have independent personalities and thinking methods. The way it behaves is normal.
In addition, there is a very good article on the best practices of code review on IBM developerworks, refer to:
http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/
Most of these best practices can be practiced by yourself, and you can slowly explore to find the best patterns and rules for your team to execute. I think there are two most important things, one is to create a good review atmosphere. This is the same as finding what is right rather than finding what is wrong in a code review mentioned above. The other one is to use lightweight tools. This is true. The team reviewed the code in the past basically did not use the tools. Directly viewing the svn code log is not only inefficient, but also has a great impact on the bug discovery rate. Tool adoption should be lightweight.
SVN Commit articles
This article is the author's reflection on the problems that the author has experienced in the project in the past few years.
1. The log submitted by Svn should be written clearly, and the content of the change should be described as accurately as possible, for example, the bug of XX has been modified, and what specific functions have been added. Many programmers, including old programmers, don't care about svn logs, and write log content such as "make some changes", "update" and other meaningless logs. Such logs are not only meaningless for code review, but even more annoying when fixing bugs or rolling back versions.
2. The number of Svn submissions and the content of submissions are controlled. There are two cases, one is to submit svn at will without restriction, and the submission can't wait for a few lines of changes; the other is to not submit for many days, and after accumulating a lot of code, make a one-time update. Many programmers are too casual about committing. The most common situation is to submit untested code before releasing a version, and then find problems and submit revisions continuously, each of which is only two or three lines. Seriously ruins the readability of the svn version log. It is a better practice to submit a unified module after the modification is completed and the unit test is performed locally. The submitted code should not be too small or too much. If too much code is submitted, it will be inconvenient for code review and version rollback. In this case, you can consider subdividing it into some related changes and submitting them in multiple times.