As a software developer, we are expected to tackle problems of all sizes - minor bug-fixes to developing new features, i.e. we are expected to come up with Solutions and then write Code for them.
It is important to note that this is a 2 step process -
1) come up with a Solution
2) write code
Code Reviews have become an established step in software development, but they cover mostly the 2nd step. Reviewers usually find it very difficult to suggest wholesale changes like suggesting a different solution because of the risk of coming across as a 'bad guy'.
There is no concept of a Review for the 1st step i.e. no Solution Review at present.
It is assumed that a developer will come up with the correct Solution. Herein lies the problem.
First and foremost, most problems, even minor ones, have Multiple Solutions, and the Developer has to choose the best amongst them. Sometimes the Developer working on the problem might not be aware of other Solutions.
Hence I believe that a Solution Review will help with non-trivial bug-fixes/features. The greater the impact of a problem/solution, the more number of senior people that have to review the solution.
Solution Reviews can probably take place in either of the following 2 ways:
1) via Discussions
It is important to note that this is a 2 step process -
1) come up with a Solution
2) write code
Code Reviews have become an established step in software development, but they cover mostly the 2nd step. Reviewers usually find it very difficult to suggest wholesale changes like suggesting a different solution because of the risk of coming across as a 'bad guy'.
There is no concept of a Review for the 1st step i.e. no Solution Review at present.
It is assumed that a developer will come up with the correct Solution. Herein lies the problem.
First and foremost, most problems, even minor ones, have Multiple Solutions, and the Developer has to choose the best amongst them. Sometimes the Developer working on the problem might not be aware of other Solutions.
Hence I believe that a Solution Review will help with non-trivial bug-fixes/features. The greater the impact of a problem/solution, the more number of senior people that have to review the solution.
Solution Reviews can probably take place in either of the following 2 ways:
1) via Discussions
- a developer discusses with one or more team-members and/or team-lead, his/her solution to a given problem
- effort is made to arrive at a consensus amongst max people in the team as possible
- if Jira or another project-management tool is being used, a simple Comment is added that says that 'ABC has reviewed the solution'.
OR
2) via a 2 step Code Review process
- these days Code Reviews happen via pull-requests similar to those used when using GitHub
- 1st step: "Initial/Solution Review" - When a Pull Request is submitted, it can be labelled as "Initial/Solution Review"
- Such a label can serve as an indicator that the pull-request is in the 1st stage of Review
- This sets the expectation to everyone, i.e. the Developer as well as the Reviewers, that the solution that has been implemented, is up for debate
- traditional code-reviews can be painful when the Developer and the Reviewer have different expectations of the Code Review's outcome, so this setting of expectation, is very important
- More people are likely to review/discuss when there is less chance of hurting the confidence of the Developer
- 2nd step: "Final Code Review" - After 'Initial Review' has taken place, the Developer submits a pull-request again that is labelled with "Final Code Review"
- Note that both the steps of the 2 step process have to be Mandatory - Otherwise, as time goes by, it could morph/devolve into a single-step traditional Code Review process.
Note: Both of the above solutions can be used together too.
No comments:
Post a Comment