Code review is one of the most important process in software development process. By reviewing the code level of assurance code works in better way is increased. developer gets early feedback as we say in Agile, ‘Fail Fast’.
I prepared this content for the Atlassian User Group’s Meetup (9th AUG Meetup) organised by AUG Kathmandu. Click here for photos 🙂
Highlights:
- What is Code Review?
- Common methods for Code Review
- Responsibilities
- Crucible Workflow
- Steps towards Code Review using Crucible
- Best Practices
What is Code Review?
Code review is a software quality assurance activity, in which one or several humans check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. Ownership of code is taken by not only developer but by reviewer also.
Review Responsibilities:
- Communicate with your reviewer by giving your reviewers background about your task.
-  Making smaller pull requests is the best way to speed up your review time. Keep your pull requests small so that you can iterate more quickly and accurately.
- Major changes in the middle of code review basically resets the entire review process, so Avoid changes during the code review.
- Respond to all actionable code review feedback , even if you don’t implement their feedback, respond to it and explain your reasoning. If there’s something you don’t understand, ask questions inside or outside the code review.
- Code reviews are discussions, not dictation — think of most code review feedback as a suggestion rather than an order. It’s fine to disagree with a reviewer’s feedback but you need to explain why and give them an opportunity to respond.
Common Code Review Approaches
Email:
As soon as a code is ready for review, the file is sent around to the appropriate colleagues via email for each of them to review as soon as their workflow permits.
Pair Programming:
As one of the hallmarks of Extreme Programming (XP), this approach to writing software puts developers’ side by side working on the same code together and thereby checking each other’s work as they go.
Over-the-Shoulder:
More comfortable for most developers than XP’s pair programming, the old over-the-shoulder technique is the easiest and most intuitive way to engage in peer code review.
Tool-Assisted:
No simpler and more efficient way to review code than through software-based code review tools, some of which are browser-based or seamlessly integrate within a variety of standard IDE and SCM development frameworks.
Code Review Tools in the Market
- Crucible
- Collaborator
- Review Assistant
- Codebrag
- Gerrit
- Codestriker
Using Crucible
Atlassian Crucible is the on-premises code review solution for enterprise teams. It allows your development teams to catch major defects, improve code architecture, and discuss desired improvements, without the need for meetings. Crucible is all about code reviews. It’s no surprise then that Crucible needs access to your source code. A Crucible administrator can connect a repository managed by any of these tools:
Workflow
There are a number of different ways in which you can use Crucible for code reviews. The following diagram shows the basic workflow that applies to most Crucible code reviews.
Creating a review
Creating a review:
Begin by clicking Create review in the header and picking the project for the review (if you have multiple projects):
Adding Content to the review:
Click one of the content types to browse or search for files, branches and change sets you want to be reviewed
Choosing the reviewers:
You can choose individuals and groups, or allow anyone to join the review:
Completing other details for the review:
We can set other details for the review
the title and description, objectives – used to guide the reviewers on what to look for. Due date, a reminder date, linked reviews, related Jira issues (if any). The project, moderator and author are pre-selected.
Start a draft review:
The review will be displayed in draft mode. Here, you can check and edit the details as required. Click Start Review to make the review available
Code Review Best Practice
All team members should follow the guidelines set when reviewing code. A code review will be created for all user stories and in Crucible once the implementation task of the user story is marked Complete. To better facilitate, include the appropriate revisions into the code review. A separate code review task should be created for each user story. This task should be assigned to a team member and this member considered the owner of this task. The owner is then responsible for ensuring all points of the code review process have been met before the review can be considered complete. The list of reviewers should include all members of the scrum team. This gives the entire team the ability to provide feedback and as well as insight into others feedback. However, the entire team does not need to contribute to the review.
Within the defined time period, it is required that at least 2 team members review the code before it can be considered complete. Any feedback provided during the review should be acknowledged by the author by either agreeing to any suggested improvements, or by providing feedback as to why the code is the way it is. A separate code refactoring task should be created, so the author can log their time incorporating feedback against this task. If someone completes the code after completion of the task, the feedback will still be considered and, if necessary an appropriate user story or defect will be created.
