Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills.
Code Review ?
Formal (Fagan) code inspection
∗ Traditional process
∗ Very detailed inspection
∗ Can take too long time
∗ Over-the-shoulder – One developer looks over the author's shoulder as the latter walks through the code.
∗ Email pass-around – Source code management system emails code to reviewers automatically after checkin is made.
∗ Tool-assisted code review – Authors and reviewers use software tools, informal ones such as pastebins and IRC, or specialized tools designed for peer code review.
∗ Pair Programming – Two authors develop code together at the same workstation, such is common in Extreme Programming.
Lightweight code reviews
1. To spot and fix defects early in the process.2. Better-shared understanding of the code base.3. Maintain a level of consistency in design and implementation.4. A different perspective. “Another set of eyes” adds objectivity.
Similar to the reason for separating your coding and testing teams, peer reviews provide the distance needed to recognize problems.
5. Pride/reward. Recognition of coding prowess is a significant reward for many programmers.
Why ?
Responsibilities
Author
∗ Always check the code before submit
∗ Accept the critics
∗ Protect your decisions
∗ Maintain the coding standards
Reviewer
∗ Critique the code instead of author
∗ Ask questions rather than make statements
∗ Remember that there is often more than one way to approach a solution
∗ Moderates review process
∗ Can check the code just to be aware of changes
∗ Can bring some special technical expertise
Observer (3rd person)
Instruments
List of tools for code review
∗ $489+ license cost∗ Wide VCS support∗ Informative reports∗ Consolidate review of code, issues, documents
Collaborator
∗ Free public repositories∗ Great WebUI and IDE integration∗ Different collaborative development models∗ Pull request = code + issue + comments
GitHub
∗ Robust Web interface∗ Only Git is supported∗ GitHub integration with GerritHub∗ Should be hosted on your infrastructure∗ Proven scalability and security
Gerrit
∗ Github/Gitlab as in instrument∗ Author requests a review∗ “Two fingers” rule∗ Share the knowledge∗ Automate everything
Stanfy way
∗ Tools do not matter, but people - do∗ Regular code reviews help to avoid about 60% of bugs∗ Accept the critic∗ Use checklists∗ Treat reviews comments as a document
Summary
∗ Stanfy MadCode Meetup∗ List of tools for code review∗ Code review - Gerrit, GitHub, Gitlab∗ Best practices for peer code review∗ Code review process∗ Don’t waste time on code reviews
Resources