Oh well, you have been asked to make a code review or a merge request (that also implies code review) and you don’t know where to start?
☕️ There there, this guide is made for you.
With simple steps you will become the most effective merge requester of all time. By effective I mean good, and by good I do not mean “fast”, doing a great review takes time, context and empathy.
*MR will be shorthand for “Merge Request”, I assume that you follow the **Gitflow workflow well explained here **by *Atlassian
Context
You are a part of a greater workflow here, don’t forget things that come before the MR and after the MR.
Never forget the context (context is the abstract concept for “things that interact with the subject”) of your MR!
- The project and its history
- The milestone that is related to the MR
- Issue that have produced the MR (of course)
- The developer
- The production and interaction with other project are also to take in account.
Use empathy
Use your empathy! Always assume that the author of the code has made his things on purpose, that he is as smart as you are. That he wrote lines of code for a reason. And if you do not understand why there are some “mistakes” or “weird” things, ask the author before making bad criticism, justify with goodwill.
Make connections
For every line of code, ask you the question “Is this useful to complete the related issue?”.
- And if you followed well the first step you can expand the question to the whole project : “Is this code useful for the project goal to be achieved?”.
- ANNNNDD to stay at the top of the reviewing art you can also ask yourself “Will this code bring value to the project behaviour within the stack?” Make links, think about the whole company as a project and contribution to the project (or objectives)
- If answers are negatives, ask the teammate that created the issue in the first place to discuss legitimacy of the current issue.
Test it
Test the project, nothing is better than a quick build with a simple functional test. Unit tests and automated tests should have already been launched by your CI tool.
Think outside the changes
Do a quick check of what have not been changed. Yes this can take a long time, here is some hints of what to check to speed up this step:
- Is
Readme.mdupdated according to changes? - Is everything committed? (You usually experience that if you executed the step 4)
- Are some function(s) that have been added not duplicated / already present on other part of the project?
- Are company conventions respected?
- Do you find parts of code hard to understand (or even impossible)? Are those parts well documented?
Hope those quick tips and read will help you and your team getting better at code reviewing :)