Code Reviews

While working in a development team; being part of the code review is not an optional thing. Depending on the size of the org/team and the # of features in parallel - I am sure, we will get multiple code review requests in a week.

I often ask myself, can I provide valuable feedbacks on every review I am part of? Most certainly NO! lets be honest here.

Then the next question is - why are you added into the review? well I could think of two reasons:

• FYI: Let the team know I made this change; there could be depenencies (another developer; working on similar files)
• Status update (stakeholders)

Not an active reviewer:

If you think, you don’t have the right context to contribute. It’s good to be explict and call out - Sorry, I don’t have enough context to add value. I would leave the review to the experts and recommend the author to mark you as Observer instead.

Note: code review is not a place to train; where you discuss and use it as a learning form.

Add Value:

This is critical and most important objective of a code review. Pointing out each and every spelling mistake and intendation fix - might not add much value; in which case - propose them to run it through a FxCop/style/code analyser utility.

You absolutely need to be aware of the context before providing feedback 👀. If you are not sure about the specifics, setup a meeting and request the developer to walk you through. At the end of the day - code is the ground truth (irrespective of what was aligned). Few example of real Value could be:

1. Pointing out specific use cases not handled
2. Usage of design principles (SOLID) - coupling/cohesion etc
3. Adding: Validation, Logging, Tracablility etc…
4. Handling: Errors, Exception, Leaks, Performance etc..
5. Code Coverage, appropriate tests (note: test should also be as clean/maintainable as SUT)

Assumptions:

This could at times come back back and bite; I have been there 😕. If you are not sure about a specfic change again: call out explicitly and confirm - if your understanding is accurate.

As authors - we do want our code to be non ambiguous. But, since there is always a context and depenency in the code - its hard to describe everything. Maybe better naming could help? well: 😏

There are only two hard things in Computer Science: cache invalidation and naming things.– Phil Karlton

No Condescending words

Thanks to Doctor McKayla for this.

Words such as “just”, “easy”, “only”, or “obvious” can come across belittling and condescending. It’s a good practice to remove those words from your feedback. Most of the time, they do not add any value….. research shows that people have a tendency to interpret written language in a negative way.

Personally, I am cautious to ensure my review comments looks like a conversation - than a direct command.

More the number of Reviewers:

I remember receiving emails like “please review my change set” sent to a DL which had 30+ developers. Do you think all 30 members would have all the required context or would you ensure all 30 will follow up and get the context and then do the reivew? Less likely! 🤔

Maybe there is a perception that more the reviewers; more the # of valuable feedback. But, what if its the other way - every one assumes its someone else responsiblity - zero feedbacks 😟.

Separate Feature Addtion and Refactoring:

Many at time its intriguing to refactor the code while we are working on a feature. We should - its always a good practise to clean up and make it better.

My only argument here is: If you have both - the feature implemetation and refactoring in the same changeset (esp on a large code base, spanning files/dependencies) - It becomes a challenge to follow the actual functional change.

Recomendation: split them into two changeset like StackedPullRequest: Personally would prefer (2) followed by (1)

1. Only refactoring. No feature addtion
2. Only feature addition

Unsure of the reviewers?

If you are already part of the team which maintains the code; no brainer. You are here since you are not sure - simplest tip Go for history. I have done this more than once; say making a change in deploy scripts maintained by operational team. Look for atleast 2 developers based on change history (again: don’t stop with one) of the file(s); secondly: make sure you look at their org structure and see if they belong to the operational team (If I get to deliver and someone else sends me a new review request 😑); finally: just to be sure add their solid line into it (why: well, you are unsure if you would get a response 😜).

Approval Enforced:

Few companies have strict code review rules like: only a pull request that has 2 or more approvals - would be merged into mainline. I feel this culture/process is awesome; as there is definetly a sens of responsibility and ownership on the part of the reviewers - at the end of the day again (would say it multiple times) “Code is the Ground Truth” (irrespective; what ever the feature/design document says).

Conclusion:

I personally belive, Code review are not optional. Anyday - another pair of eyes would give you a different prespective. While, we as developers are more focused on getting thing done, there are chances of scenarios getting overlooked - effective code review enable us to bridge this gap. This defintely requires commitment and trust between authors and reviewers.

Building a culture toward delivering quality code with code review as pivot is critical.

Check out: Doctor McKayla; there are lots of good content on this topics.