Ode review is a very important task in the project process and can be effectively checked out.CodeLevel issues, which are often hard to be discovered by QA. However, in actual work, code review is often in form because it cannot be quantified and cannot form an effective closed loop. In many cases, it is only a reminder from the PM that you can view each other or organize code review meetings, at the meeting, everyone made a collective review of the projection, and the effect was not very good.
The key to solving the above problems lies in the formation of a mechanism and implementation with effective tools. This can be used for reference to the QA bug system, establish a life cycle for each problematic point, such as Problem Discovery, problem allocation, and problem resolution, and record it, so that each code reviewer assumes the responsibility of similar QA.
Code review mechanism
The Code review mechanism and process are as follows:
The key to the entire process is that all code review work can include the project owner, not only the leader or the core members of the project, but also the closed loop of every issue, solve the detected problems
Implementation Method
The implementation method is based on the defined mechanism and process. The above process can also be completed through an Excel file, but it is not suitable for the whole team to do it in parallel, jupiter is a tool that allows the entire team to review. It is an eclipse plugin, so it can be combined with the code that requires review, which is very convenient. The following describes how to use Jupiter to complete the above steps (for installation purposes, update http://jupiter-eclipse-plugin.googlecode.com/svn/trunk/site/in eclipse ):
1) The coder submits the code for review to the reviewer.
After the developer of a module completes the code, the involved code must be submitted to reviewer.
Go to the properties Panel of the project and Select Review Sub-panel:
Create a Review Unit and follow the new process. The key is to specify who will review your code in the reviewer setting panel, as shown in the following example:
In the author setting panel, specify who is responsible for this code. Generally, it is the coder of this Code, as shown in the following example:
The preceding settings are used to understand the roles in the review process. You can specify other options as needed and use the default settings.
After creating a Review Unit. the review file is commit. Because all the processes and actions are based on this file, your cooperation is based on version management of this file. Therefore, only the file commit is a Review Unit submitted, reviewer can perceive this review item
2) reviewer review the Code submitted to you with comments
After reviewer updates all. Review files, it enters the individual phase of Jupiter:
In the reviewer ID, select the item that represents your own. After the item is finished, you can start the specific code review. In the review panel, you can easily find the file for review:
You can add a review comment on the specific code line:
After saving it, there will be an obvious identifier in the code, indicating that it needs to be modified here:
Commit. Review file after all review tasks are completed
3) The leader assigns issues to the modifier based on the workload schedule.
After updating all. Review files, the leader enters the Jupiter team stage:
For each issue, the assigned person is the coder assigned to this code by default.
4) coder fix specific issues
After the coder updates all. Review files, it enters the rework phase of the Jupiter:
You can see all the repair tasks assigned to you. After the repair, change the status to resolved.
5) issues confirm and close
Reviewer or leader can view the repair results of each issue in the rework phase of the Jupiter. The status of the repaired issue is changed to closed. If the status of the repaired issue is not fixed, contact the coder, those that require collective confirmation and discussion are left at the code review meeting.