Some experience of Review board

The recent product line research and development system formally review Board this excellent web-based code review open Source tool into the development process, as the product line within the project team for code review of the auxiliary tools. My attention to review board for nearly two years has not been wasted, but there is a fairly good result. But the formal use of review board does not represent an end, but rather a new beginning. Our next step is to focus on how to use good review Board, so that it really is to improve product quality and development efficiency.

In the blog post on "Online code review" I mentioned the role of the Online Code review tool in the development process, the timing of use, and the considerations when it was used, but more intuitively. After really using the review board such a review tool, some ideas will be further refined.

Indeed, we have found a lot of problems in the use of the last one months, within the company I put these problems and solutions into a page wiki pages into the product line of the Knowledge base, here I also share with you.

Here's a list of tips I've made about how to use good review Board:

* Be sure to maintain the cohesion of each review request content
If you submit a review request that contains a bugfix for a library, add a new feature to the B library, and a piece of code that reconstructs the C library, then your review request is unqualified. The request content contains three irrelevant content, a serious lack of cohesion, which will adversely affect the follow-up review, such as the reviewer's focus on the dispersion, efficiency decline, the reviewers are reluctant to ignore the request and so on. For the above question request, it is recommended to split the request into three request, so that the content is single-cohesive.

* Please set the review end time for your review request
Remember to set a valid review timeframe for each review request, or your review will be considered forever, so that the request will become "plastic trash" stuffed with your dashboard over time. Since the review board does not appear to have a location to set the review deadline, it is generally possible to increase the review end time for that request in description, for example, by adding:
"Review deadline: 2011-03-07-12:00"

* Keep your dashboard clean, don't forget to close your review Request
With review Board for a period of time, you will find a lot of incoming and outgoing requests in your dashboard, making people unhappy. We recommend that you close your request and keep dashboard clean after the request has been reviewed or expired.

There is a close tag in each request and there are three options below:
-Summited says the review is over, the code has been submitted and no further review is required
-Discarded discarded request for review
-delete Permanently the request should be deleted
In general we will use the summited.

* Please select the appropriate stakeholder list for the review request.
Each review request should have a specific stakeholder list, not to be sent to all group sets in the review board system. Otherwise, you will not receive effective reviews from those who are irrelevant and interfere with each other's work.

In general, before initiating a code review request, it is clear that the purpose of this review is nothing more than the following combinations:
-The stakeholders are expected to identify the code logic flaws in the code;
-The stakeholders are expected to identify the business logic flaws in the code;
-Share your code and show the beauty of your code to everyone.
After you have identified the purpose, you should be aware of who is in the stakeholder list.

* Ask the reviewer to focus on the changes in this request
In the actual use of review board, it is often found that a colleague initiates a review request for legacy code modifications. A number of reviewers have given some comments that are not intended to be the modified code, but to change the code in the source file. This can lead to the following two issues:
-the reviewer submitting the request may not be able to correct any code issues other than this request;
-The review process may be stretched, and it may not be possible to complete the review within the deadline, or even repeatedly, resulting in an inefficient waste of time.
In this case, we recommend that reviewers focus on this change. If the review process finds other issues that are not related to this change, you can submit a issue/ticket to the project where the code is located, or to an issue tracking system that is todolist by the main maintainer of the project.

Finally, say Post-review the use of this tool. The principle of Review board is actually judging the diff file. In general, it is understandable that you submit your own manually generated diff file via the Web page provided by review board. But review Board also recommends using a more efficient approach, which is to use the Post-review script to initiate the review Request. The following describes three common scenarios for using Post-review tools in your work, provided you have installed Post-review on your console.

* Initiate a review request before code commit
In some cases, the project requires that the code not be reviewed without permission to commit to code repository, which we call Pre-commit review. In this case, you can initiate a review Request, complete the modification of the code in your local code base copy, and then go to your local code directory and execute:
Post-review–server=http://xxx.xxx.xxx.xxx/reviews

Post-review will submit all changes in the current directory and its subdirectories as a diff to the review Board form a request draft waiting for your release. Of course, you can also directly set the request Descripton and other fields through Post-review, and you can publish the request immediately by adding the –publish parameter.

* Initiate review request after code commit
In some cases, some code is reviewed after it is submitted to the repository, which we call Post-commit review. We can construct the review Request by the difference between the revision number of the Repository, as follows:
Post-review–server=http://xxx.xxx.xxx.xxx/reviews–revision-range=n:m–branch=your_repository_path
Of course you can also not specify –branch, but you need to execute Post-review in your local code base copy directory.

* Update a review request that already exists
After the request has been submitted to review Board, you may need to revise the code again and update the diff file to continue the review. You can then update the diff for the existing request by specifying the existing review request ID as follows:
Post-review–server=http://xxx.xxx.xxx.xxx/reviews ..... –review-request-id=58

Note that if you set the HTTP_PROXY environment variable under your Unix/linux account, you need to set the http_proxy to null before executing the Post-review, otherwise the Post-review request will be blocked by the agent and fail.

More and more people in the department are beginning to pay attention to and use review B