Things I learned from Code reviews

We all know the importance of code reviews and how it helps to maintain code quality and establishes coding standards in the team.

But I want to point out a different side of the coin and tell you how it helped me when I was starting in the Development field.

Code Quality

As a junior dev in my first job, I did not know a lot about design patterns or javascript concepts. My mentors provided me with great knowledge of how I should use design patterns while writing any piece of code, no matter the language. They provided constructive feedback as to what sources I should refer to when solving different problems.

Knowledge Transfer

Code reviews helped me get domain-specific knowledge, helped me learn how to structure code according to requirements. They helped me understand the product and how different parts of the system work together to give user experience.

Knowledge Dissemination

Code reviews helped me and my team to share the knowledge about every piece of code. So nobody was the sole point of contact in case of emergencies. Everybody was a code owner of all of the code. This helped me a lot in gaining confidence in my code and my management skills during emergencies.

Art of Discussion

Code reviews help to see the code from the view of business requirements. It helps beginners especially understand concepts of domain-driven design. It encourages them to research and to defend their design in front of code reviewers.

Forward Help

One of the biggest problems I see in new devs is they do not have confidence in their code and sometimes are not able to express why they are using an approach over another. So, I and my friend have come up with an idea to help young devs.

You can forward us your code and we would love to provide you with constructive feedback. We want forward the help we received when starting. Reach us out via email Akanksha Sharma and Alican Karalar or twitter @Akanksha_9560 and @alican_js

Comments

[Robin Palotai]

Nice writeup! Two hints to get the most out of code reviews:

Take a look at the diff.

Before sending your code for review, take a look at the full diff outside your editor.

For example, do a compare vs base branch in GitHub. Make sure it's a split diff, not a unified one (latter is horrible to parse).

Looking at your change outside the editor gives you a real birds-view perspective. You'll notice misindents, missing comments. You'll feel the itch to polish it up.

Act on all instances of the comments.

Even if the reviewer commented on a specific instance of the problem (like having a too long method), go over your change and fix it at all relevant places (break other long methods too).

Note: don't go overboard, only apply this on your change, but not on unchanged parts of the touched files. Those cleanups should happen in separate changes that don't modify functionality.

Source: mindmap for my work-in-progress handbook Programming Without Anxiety.

[Robin Palotai]

Bonus: use my Stylus script to make code in github files-changed view vertically compact. HD code review experience!