Software life cycle is a relies on systematic solution specification, design, development, and implementation subject to continuous review and approval processes.
Review process starts, right from the beginning, with the Requirements Document reviewed by the entire team and once the feedback/comments are finalised, the Requirement Document is freezed. Then comes the turn of the Technical Design Document & Test plan. Again, it is reviewed by the entire team and feedbacks/comments are provided and implemented. Following this, Code & Test scenarios/cases are written & reviewed, firstly within the developer team and then by the peers.
Why Reviews?
- Improve quality – The sole motive for complete review process is to improve the quality of software. Performing reviews at each phase of software life cycle is very significant since it ensures quantum of bug/issues & there severity is very less in subsequent phase as compared to current and so does the cost of fixing the bug/issue.
Consider a situation where there is gap in requirement & requirement review is not done. Their is a chance that this gap would be surfaced during user acceptance and neither client nor development team wants to be in such situation. Now, cost of fixing the requirement gap is very high here. Had this gap got visualized during requirement reviews it would not only be filled up with joint effort of development team & client’s viewpoint but can win client’s confidence as well in the beginning itself. Thus , reviews acts as safeguards and and an effective tool to check bug leakage in following phase of software life cycle. More effective is the review process better would be the code quality & lesser would be the cost of development. - Sharing of thoughts for better solution – Remember their is no best solution to a problem. Solutions are either good or better and there is always a scope of improvement if not today then tomorrow seeing the constant change in technologies. Good solution for one problem area can be better for another and vice versa.
Review is an effective tool for sharing different thoughts for better solution and thus must be taken positively. It should not be taken as an opportunity to outshine or degrade anybody.
Approach to be followed:
For Reviewer
- Ask questions rather than make statements
- Avoid the “Why” questions
- Remember to praise
- Make sure you have good coding standards to reference
- Make sure the discussion stays focused on the code and not the coder
- Remember that there is often more than one way to approach a solution
For Developer
- Remember that the code isn’t you – Developers must be clear on this that reviewer is pointing the issue on code and not on you. Don’t make this personal.
- Create a checklist for yourself of the things that the code reviews tend to focus on
- Help to maintain the coding standards
- Remember that there is often more than one way to approach a solution
Educational and Open – The whole review process should be educational, open & must be taken positively. Learning must be shared across the team so that similar issues must not be repeated in future. It must not be taken as a tool to attack personally on one’s capabilities. Remember the ultimate objective is it to improve Product Quality so that it would be a win-win situation for both client & development team.
View Review Checklist
