Code Reviews

Code reviews are one of the most important parts of the delivery process. It helps you and other developers to learn, communicate and build better quality code. Please find couple of these principles to follow while reviewing or being reviewed.

Review your own code

It might sound silly, but it's very important to check your own code before passing it for general review. Looking at your work from a wider perspective in most cases will help you to perceive missing things, potential issues, or even logical bugs. For sure, it's not a waste of your time.

Check the pipelines

Be sure that build and tests are passing before you'll ask for the review. Each pull request will run the pipelines with build and tests checks. If they're passing, you're ready to go. Check them again even your code was approved.

Get at least one review

To merge your pull request you need to get at least one code review from the other developer. As long as your code has been corrected, and it's ready to re-review please be sure you get approval from your reviewer - don't assume that what you've just improved is ready to merge. If you're working on some average or simple task keep the rule, but for more complex and detailed features wait for reviews from two developers / reviewers.

Use references and examples

Don't be rude. Don't be ignorant. Don't leave another developer with one word, one line comment. Remember that code reviews are the best source of learning. It's almost as effective as pair programming. Explain, use an example, or code referral. Ask concrete and specific questions.

Keep it simple

It's important to not review huge and overwhelming features. If the pull request comes with dozens of files to review please ask the author to split the code into smaller chunks. It's super hard to see the whole scope, and the big picture of the task and logic around it if it's large. No matter if you're the reviewer or author remember to split your code and features to sub-tasks and deliver them continuously.

MoSCoW

If it's possible use MoSCoW (opens new window) rule. It can be very helpful while reviewing code of others. You'll not fix everything, and it's not possible to repair the whole world. Let other developers know that at one time you can close your eye on some missing's (could / would be improved) but sometimes it's necessary to fix something (should / must be fixed).

Team decide

It is hard to find a common understanding? Don't fight, don't be stubborn, ask other team members to solve doubts and disputes. There must be something in it when more than one person telling you that you're wrong. Don't treat that as offense or attack, learn and move on. Be humble.