With this chapter, we will start our journey by getting acquainted with Review Board. First of all, we will look at pre-commit and post-commit code reviews, which are different ways of performing code reviews depending upon whether the review is done before or after pushing the updated code to the code repository. We will then briefly look at the various features of Review Board, such as creating and publishing review requests with code diff and integration with the version control system (VCS), which will be covered in detail in the forthcoming chapters. As a code reviewer, you can view the code diff, add review comments, and create issues for a review request.
Every time you visit search.yahoo.com, you use code that has been reviewed on Review Board.
How would you feel if the world's craftiest programmer went through every line of code that you wrote before it appeared on the user's screen (or maybe in a cold, dark machine running on a server farm on a remote island)? Good, right?
But everyone is not so lucky to have such a person go through their code! Yet, you can (and possibly do) have a good set of peers who can go through your code and help you improve it. They might not be as good as the world's craftiest programmer, but having your code pass through a different set of eyes and the feedback that it will generate will help you fine-tune your code, improving its correctness and quality significantly. This process is called code review.
Thus, code review helps you in identifying and resolving potential problems in your code that could otherwise be caught by a tester (bad for your ego), or even worse, appear in production (bad for your reputation).
Code review is beneficial for the following reasons:
It can play a significant role in helping you release your software on time (or even earlier)
It can help you create very high-quality and reliable software
It can help transform your team from being a mere development team to a quality development team
Guess what? The preceding points will also help you save a considerable amount of money while developing your software.
Some people think that code review is an overhead and slows down development. In reality though, many teams that perform code reviews have proven that it helps the organization to save a lot of time on bug fixing and speeds up the development, which leads to a better quality product and faster shipping.
Now that you are familiar with what code review is, you will be itching to try to implement it. Hold on, aspiring code review ninja! You will be able to extract the maximum benefit out of code review only when you do it the right way. Keeping in mind the following points will be of help:
Remember, small is beautiful. Code review works best when done in small chunks. Ideally, code review should not exceed 30 minutes, and the number of lines in a code review should not be more than 200.
There should be a common code review checklist so that all of the code is evaluated with the same yardstick.
It must be ensured that the outcome of each code review is sewn back into the code.
Code review should target code, not people.
Be egoless; you are not your code.
Review findings should not be limited to a group of people. Rather, they should be visible to everyone in the organization. This would also help avoid duplication of similar coding mistakes across development teams.
Thus, code review is not a process of only identifying the coding problems; it also helps in manifesting a culture of writing high-quality code. To successfully implement the process of code review in your organization, you would need each and every programmer to be egoless.
A few years ago in our team, the following was how we performed a code review:
Schedule a meeting for code review.
The author would incorporate the improvements and notify at least one of the reviewers to verify it.
The review was closed only once it was verified.
This kind of code review is known as a heavyweight code review or a formal code review. Although this process worked to get the job done, it had lots of overheads and consumed a lot of resources. It also had lengthy cycles of review feedback.
If you think that heavyweight code review is not suited for you because of its slowness, take it easy, aspiring code review ninja! Lightweight code review is here to rescue you! It typically requires lesser overhead than formal code inspections, though it can be equally (or even more) effective when done properly.
Because there is no formal defined rule of performing lightweight code review, you can devise your own methods of practicing it. The only thing you have to keep in mind is that it should not block people within your team.
Pair programming: You and your developer friend can develop code together at the same workstation. This helps eliminate a lot of waste even before it appears. This is common practice in agile development methodologies.
Another categorization of code review can be done on the basis of whether code review is happening before or after committing (pushing) the code to the code repository. The next section will talk about two types of code review (pre-commit and post-commit code review), the work flow that one can follow, and the pros and cons of following these code review processes.
As the name suggests, pre-commit code review enforces that the code be committed to the code repository if and only if it has passed through the full code review cycle. The full code review cycle will ensure that the code meets the required quality standards and that all of the suggested changes have been incorporated. The pre-commit code review cycle is illustrated in the following diagram:
Pre-commit code review is a strict code review process as it acts as an ultimate funnel that doesn't allow a single line of code to be shared among team members unless it has been fully certified as quality code. The major challenge with this kind of review process is that it slows down the team as the multiple cycles of review become additional steps before the code reaches fellow developers.
To have a fairly successful pre-commit code review, the team members (or potential code reviewers) must always have "yes" as an answer to the question: do you have time for code review?
An alternate practice called post-commit review tries to tackle the challenge posed by pre-commit review by making the code review happen after the code becomes available to fellow developers. Thus, it doesn't prevent people from continuing with their work. The following diagram illustrates the post-commit code review cycle:
As Spiderman's uncle Ben said, "With great power, comes great responsibility",and the same applies to the post-commit review process. Because the developers have the power to make their code public even before it has passed the review process, the onus lies on them to ensure that they get the code reviewed later and incorporate the suggested changes.
On the cons' side, it might so happen that the other team members have already made the changes to the original code pushed by the author to the code repository by the time the author wants to incorporate the review comments. It may not be that big of a challenge though; it would depend on the team size.
User feedback is always a good way to separate a great tool from the average ones. Review Board has been the most used tool for code review for many teams.
You can find a list of happy users on the Review Board site at http://www.reviewboard.org/users/.
As a first step towards our learning of Review Board, let's go through its features that make teams feel happy and confident about Review Board being the right tool for code review. A more detailed walkthrough of each feature will follow in the upcoming chapters.
A basic requirement for any code review tool is that a user should be able to share the review request with the team. Review Board supports the creation of a review request through the web interface or command-line tools to push the review requests to Review Board. It requires bare minimum efforts to create and push the review request to Review Board.
The next most important thing after publishing the code review request is the ease with which a review can be performed. The smartest thing that can be done to make code reviewing easy is to highlight the differences introduced in the code, and that's exactly what Review Board does.
As a reviewer, you would want to add comments to the code under review to ask questions, provide suggestions, and appreciate a good implementation. Also, as an author of the code, you might want to further add comments to answer the questions asked by reviewers and explain why a particular suggestion should (or shouldn't) be incorporated. Review Board provides multiple ways to add these review comments on the code and also fulfills all of the following requirements:
Comment on an individual line
Comment on a group of lines or a selection of text
Comment on an existing comment
It becomes easier to review the code if the differences in the code, before and after the changes, are visible and highlighted. Review Board comes with a very intuitive diff viewer to highlight the differences with the following features:
Code addition, modification, and deletion are highlighted in different colors for quick identification
The changed content of a line is highlighted to show exactly what has changed in the line
You can choose to perform a single or multiple diffs
One of the major parameters that teams have to weigh a code review tool is how easy it is to track the review requests. If code review is done manually, it can consume a lot of time tracking all of the review requests and their progress. Also, you might have to keep chasing people to get the review done. With Review Board, one can track the review requests just as user stories and bugs are tracked in other tools. Additionally, Review Board has the following features:
Many code review tools are tied to a specific version control system. This is not the case with Review Board. Review Board can be integrated with Git, Subversion (SVN), Perforce, and Mercurial in a seamless manner.
Review Board makes life easy not only for its users, but also for its administrators. Review Board makes it possible to manage almost everything through its web GUI. The following is the list of features that makes an administrator's life easier:
With the setup of Review Board, we come to the end of our first chapter. In this chapter, we learned about pre-commit and post-commit code reviews, various features of Review Board, and how those features help both the author and the code reviewers to do their work efficiently and effectively.
The next chapter will talk about how you will work with Review Board as an author of code who will be publishing the code to Review Board for code review.