The Code Review life cycle - an overview
From pushing the first lines of code to deployment, the software development cycle involves a pipeline of tasks, processes, and tools. Consider a feature implementation task which involves adding new lines of code - once the engineer is satisfied with the work and is reasonably sure about meeting all product requirements, a Pull Request or a PR is raised.
Depending on the Git provider, it can be referred to as a Pull Request (Github), Merge Request (Gitlab) or Diff Review (Phabricator) - all of which are code review requests.
This initiates the review process, where peers or managers are requested to review the changes made, suggest improvements, edits, or retractions and finally give the green light for this set of changes to be shipped.
Why should PRs be reviewed?
Any and all changes to code are added only to a secondary branch whose purpose is to contain changes that are relevant only to the task under consideration. This is later merged with a larger branch, usually called the `main` branch - considered the production software branch that is deployed everywhere. This practice ensures that the changes being added to the software:
- Are complete in their feature requirements,
- Meet code quality standards,
- Passes test cases with acceptance criteria
A Pull Request or a PR is then raised to merge this secondary branch onto the main to deploy the changes to production.
Completeness of the feature
The code review process in a Pull Request begins with a completeness check that is critical in ensuring that the code changes cover all the requirements detailed in the associated work item. At this stage, the reviewer also makes sure whether the PR is linked to a ticket or not, potentially pointing out loopholes in the development process. Note that all changes to code can become enigmatic without the details on why, when, and how they were implemented that are usually found associated with the associated work item.
Code Quality checks
Anti-patterns: Anti-patterns are code patterns that tend to negatively impact readability, compile times, bug rates, or overall quality of the system. These can be as simple as using inefficient algorithms or not using language specific constructs, paradigms or patterns, often stemming due to the engineer’s lack of experience. Or, using logic or pieces of code that are generally flagged by malware detection softwares. Identifying these might seem like a daunting task at first, but thankfully they are not. They are rather easily identifiable by an experienced reviewer. And for more junior reviewers, there are free tools available that help avoid or detect mistakes that are costly. Code Reviews are a crucial process in maintaining a code base that is free of anti-patterns which in turn maintain and improve overall code quality.
Code readability and complexity: Software dev is a team sport, involving several engineers working on a shared code base. This makes it imperative that code is readable, because most time will be spent reading, understanding, and analyzing code and the solutions to the problem and less time actually writing code.
Laurie, a senior software engineer from Netflix, tweets the importance of reading code thereby throwing light on the readability factor of the code base: