Dec 17, 2017
How code review can make you a better developer
I mainly use Github for all my projects. When working with a team, I have a specific git flow which is composed of two protected branches:
mastermain branch (production)devalways ready to be pushed to master, thus to production
I can as well setup continuous integration with services like Travis or CircleCI to ensure that my code is always working in a neutral environment.
Now that I have my two protected branches, if I want to work on a specific a branch I have to create a new branch from dev, implement all the needed features and then make a pull request. Someone else from the team must accept it in order to merge the new branch to dev.
Nobody will be able to push directly to the dev or master branch without code review
Protected branches is a Github feature but other services like BitBucket and GitLab have the same functionalities. On Github, you need to go to your repository settings for the setup.
Why does that matter?
Many developers might think it is a huge waste of time and have their reasons to not doing that. I must say it mainly depends on the project’s needs and the project duration. However, I’ve seen huge improvements in general code quality, team motivation, the number of failed builds, that I don’t think I will ever come back to non-protected branches setup.
Pull requests force you to think about others
When you make a pull request on an open-source project you known that someone else will read your code. Therefore, you pay a lot of attention to it and do everything to make your code as readable as possible.
When working on your private repository alone, you usually do not care that much. However, when working with a team I think you should always code like someone else is reading your code. You must take the time to look back and ask yourself if your code is clear enough for someone with no background knowledge.
If it is not the case then you must do everything to fix your code. How can someone review your pull request if that person does not understand what you did?
Read code
When you are in charge in accepting the code from someone else for example on Github on a pull request, you have to read the code and understand the changes made by the author.
Some might say it is a boring task to do but let’s think about it, it makes you read some code and you can see some interesting implementations. Questions should come where you ask yourself how you would have done it, why the author did it this way and not another way around. Sometimes you can be very surprised and discover a new way to do things you never thought about.
One way to improve your coding skills is to read code from other developers.
Self-satisfaction
Seeing your work being read and accepted by someone else can lead to satisfaction and can strongly improve your self-esteem as a developer.
Everyone like to see his pull request accepted and merged into a project. It is way better than merging something that nobody will ever notice, care or be interested in the way you did it.
Communication skills
With code review, you have the ability to discuss some implementation issues or techniques. It is a huge opportunity for finding the best solution to a problem. Obviously, you should have discussed this before making the pull request but it’s never too late to change some implementations and make sure that you have delivered the best possible solution. In addition, it ensures that as a developer you can explain your work to someone else.
There will never be too much communication between developers, developers must talk to each other and code review is a good way to make sure of that.
Conclusion
There are many reasons why code review is important when working on a meaningful project and that is also why companies like Google, Amazon or Microsoft are relying as much on code review as they do.
Do not stay too much in your comfort zone, read code and make sure to deliver always a tested, readable, robust code. Code review will just help by making sure you do.
