Everything about Code Review:
from Peer Review to Automated Code Review
What is Code Review?
In summary,Code Review is the process throughout which source code gets assessed by one or more software developers or engineers. A thorough reviewer usually looks for inconsistencies, errors, potential bugs, problems in design and architecture, and issues of performance and security. Its benefits include an increase of collaboration, mitigation of risks, and a decrease of knowledge silos.
Too many terms. What does each means?
As humans, not only developers and engineers but all stakeholders involved in the development workflow can make mistakes. That's why software review is an essential practice of the industry.
Software Reviewis a process or a meeting that gathers interested personnel and parties to exam produced deliverables of the software development activities. The examined documents can include contracts, software requirements, specifications, manuals, source code, and any other work necessary for building the software product.
Peer Reviewis a type of Software Review. This kind of review consists of the evaluation of the produced work based on the feedback of one or more people with similar competencies (colleagues, coworkers, seniors, for instance) of the original author.
Scholars have their work peer-reviewed by professors. In the editorial world, it is widespread for editors to review authors' work. This practice is professionally performed since at least 1731, pieces of evidence show.
For the computer science field, it's not something new either. Any produced document is a potential target for peer review. When developers and engineers review source code, though, they are doing code review.
Code Reviewis the practice of having other peers reviewing source code changes before it gets introduced into a baseline. Developers usually review their team members' code, although there are companies that promote cross-team reviews.
This practice has lots of benefits. That's why it became popular in the software industry and a consolidated step of the modern software development workflow. It is widely known, and the more companies are going digital, the more they are adopting this technique.
There are two kinds of Code Review: Formal Code Reviews and Informal Code Reviews. Formal Code Reviews are comprehensive. They follow checklists and more used for mission-critical software. Informal Code Reviews are more open to subjectiveness, as adopters prefer guidelines and conventions over checklists.
Code Review approaches
Although Code Reviews via Pull Requests in tools like Github, Bitbucket, and Gitlab became very famous in the last years, there are more ways to perform this practice. Here is a list of popular approaches. Some of them date from the beginning of the Internet.
This approach marks the beginning of the code review. It's very familiar for those involved with the open-source communities or old-schools companies, in which developers submit patches with source code changes as attachments for approval via mailing lists. All developers of the project would download the patch, apply to the baseline (master branch) and review it. If everything were ok, they would definitively accept the changes. Otherwise, they would return their feedback on the code, suggesting changes or discarding the whole work.
Pastebin is a kind of online hosting service for pieces of code. It became used mainly for code sharing via Internet Relay Chat (IRC). Developers used submit code to pastebin.com (the pioneer) or similar ones while learning how to program or to help project maintainers to reproduce bugs or debug.
It's a kind of informal code review that happens during development. The name says everything. While one developer pilots the keyboard, another one reviews the produced code. This practice became popular after described in the book Extreme Programming Explained: embrace change.
As the technology and the software industry evolved, tools to easy the code review process naturally appeared. Companies chose them so teams can communicate changes through pull requests, merge requests, or change requests. The name varies, but the functionality is the same: to allow software developers and engineers to review changed code before it gets merged into the baseline. Three of the most known providers are Github, BitBucket, and Gitlab.
Code Review Best Practices
Different roles participate in the process of code review. Above the list of best practices groups practices for both roles. The author is the one that wrote the source code. Reviewers are peers of the author that should understand the purpose of the change and point code smells, bug risks, security flaws, and other possible issues.
Best practices for authors
- Always add some business context, so your team can understandwhy this code is being added, changed, or removed.
- If it's am incomplete work, add some checkboxes or list with the missing tasks to the description.
- Enrich your description with visual content, like gifs, screenshots, or diagrams. Images and videos accelerate the understanding of the change.
- Defend any arbitrary decision before the discussion to ignite. For instance, if changes are not following a convention, tell your team why you opted by this solution before they point it out. It focuses on the comments and avoids overwhelmed communication.
- Does the code work? Check whether function and logic are correct.
- Are functions, methods, and variables adequately named?
- Are names semantic and meaningful for your business?
- Is it well tested?
- Are there unit tests, and they have good quality? Do they test the functionality?
- Do tests reach acceptable coverage for your project?
- Is the code clear and easy to understand?
- Does it meet the team's guidelines and style guides?
- Is there any duplicated code? Remember that duplication is far cheaper than the wrong abstraction.
- Is there any commented or unnecessary code?
- Does the code take the most out of frameworks and language? Is there any custom implementation of native or already-existing functions?
- Are there code smells, grey areas, or bug-prone?
- Is documentation on functions, methods, classes, contexts, and behaviors adequate?
- Is the code as modular as possible?
- Are the critical spots adequately logged?
- Does the code consider failures? Is it just considering the happy path?
- Are there better or simpler solutions?
- Is there any performance issue?
- Are input data sanitized?
- Is there any SQL Injection point?
- Is sensitive information being encoded or encrypted?
Code Review tools
There are lots of tools that can help developers and engineers to review source code.
Git, Mercurial, Subversion, and Perforce are examples of version control-systems. Their main job is to store not only the source code but the history of changes. Distributed version control-systems, like Git, allows developers to easily create branches from a master branch, implement a feature or fix a bug, and submit the changes for review.
This kind of tool is essential if the chosen approach is tool-assisted. Pull/Merge/Change Requests rely on the power of distributed control-systems, as does Github, Bitbucket, and Gitlab
Linters & Static Code Analysis
Static Code Analysis means that an automated software runs through your code source without executing it. It statically checks for potential bugs, memory leaks, and any other check that may be useful.
Linters are great examples of static code analyzers. They are available for a large number of programming languages and frameworks.
Automated Code Review: The Future is now!
Code Review is a kind of peer review that evolves since the beginning of computer science. Nowadays, there are even products that perform automated code reviews. Tools for such activity usually integrate with Github, Bitbucket, and Gitlab.
In the case of SourceLevel, for instance, we run multiple linters against pull requests. A robot insert comments telling developers about the issues found right into the related line. It runs on every git push.
This kind of tool improves code quality as much as it ignites health discussions. Another essential advantage of using automated code review tools is that it saves time. Instead of spending time on the same discussions over and over, developers can focus on architectural, structural, and other crucial discussions a pull request should raise.