Do you perform reviews?
Review — “a process of examining and assessing the work product again”. Reviews are essential in software development life cycle(or for that matter anywhere). Reviews help take that extra measure of feedback from others to refine the work product. There are various reviews conducted in SDLC.
- Requirement/Use case review
- Architecture review
- Security review
- Infrastructure review
- Design review
- Test plan/case review
- Compliance/Documentation review
Taking an example of the above reviews, let me breakdown the process for what happens in a code review. Similar aspects are applicable for any of the reviews discussed above.
What does it mean to do a code review? Code reviews help with rechecking/re-validating the code so as to see whether the intended purpose is met and the boundary conditions are cross checked. Both positive and negative scenarios are discussed and elaborated. Security, performance and scalability are also brought to the table for discussion.
Why is it important to perform a code review? To get a different perspective of the use case understanding. A developer and a tester think very differently. A requirement analyst thinks differently. All of these work need to be elaborated in the code and the “conditions” need to be met. It also helps to ensure that you have minimal bugs in code, minimize the chances of having issues, confirm the code adheres to guidelines, possibly increase the efficiency of the code.
Are code reviews foolproof? Definitely no, but this additional step helps the development team to help refine the code. Additionally, this helps the developer next time when they write their code and incorporate the various perspectives.
How are code reviews performed?
- Traditional way —Agree on a mutually convenient time after the code is completed or semi-complete. The developer (who developed/wrote the code) opens up the editor along side one or many more peer developers and explains the code. The peer developers comment on the code. The boundary conditions are picked up and discussed. Traditionally, this type of review is also one of the reasons why peer programming always helps
- Remote way — Agree on a mutually convenient time after the code is completed or semi-complete. The developer (who developed/wrote the code) opens up the editor along side one or many more peer developers and explains the code using screen share.
- Automated way — The software tools perform the code review in an automated manner. The tool provides a report on possible issues or action that the developer would need to act on. Apply the 80/20 rule. Not all of the tool output would be directly applicable. There would some false positives. Eliminate them. Seek feedback from experts on topics that are not understood (don't struggle alone). Rinse and repeat.
What are the some tools available for use?
GitHub
Collaborator
Review Board
Crucible
Phabricator
SonarQube
How long does a code review take? This depends on the code base to be scanned or walk though, but this is typically between 30 minutes ~2 hours. Split the code reviews into various intervals.
Are there checklists available for code review? This depends on the programming guidelines but a generic list (not exhaustive) is mentioned below. (you can ask the leading questions to the developer)
- Is the code readable?
- Are the security checks in place?
- Are correct coding constructs used?
- Is the code performant?
- Identify bugs if any
- Is the code testable under positive and negative conditions?
Organizations miss the review process or usually have a “facade” process as a checklist. This can backfire as the dropped review conditions or comments would crop up in testing or production where the users/systems are impacted.
A note of caution —The code reviews should not make the developer uncomfortable. Please try to coach the developer to get better for the next code he/she writes. So please try to avoid insulting remarks. The end goal is to have a “better working code”. Additionally, the developer should not be taking the comments personally.
How do you conduct your SDLC reviews? Do you have adequate time built in the project plan for various reviews?