How to pass the code review

Great software is built by great teams

One of the things that you have to remember while you are coding at your day job, is that you are not alone. You are part of a team that all of its members are putting equal effort to bring the software quality at a decent point. A great tool for team working and for taking the ideas of people into consideration, is the code review process, where all team members are reviewing the effort of their colleague on a specific feature. Code review happens in different formats, such as manually with pen and paper, using code review system (see Crucible), or during a show-and-tell. The main reasons a code review happens though are the following:

a) To make sure that all the members in a team take part in the development and/or supervision of a feature,

b) To improve any weaknesses in the code and make sure that those weaknesses are not in production code, and

c) To build team appreciation and to learn from each other

But knowing that code review is part of the workflow before a task goes to the done column, you need to make the process slightly smooth to be able to move on to the other feature that you have on your stack. Here are a few suggestions on how to improve the process:

  1. Make sure it works on all devices

Lets say you are working at a mobile app company for iOS applications and you’ve just finished coding a feature. What you have in front of you, is an iPhone 6S, you test it on there and then you say it works! This is wrong. The normal procedure should be to test it from iPhone 6S all the way down to iPhone 4. And while you are doing that, please take a screenshot of your working feature on each device and then include those screenshots in your pull request. If the feature is working on all devices and the screenshots are included in the code review, then we’ve ticked one of the biggest boxes in software development, which is called compatibility. So rule #1, prove that your feature works across all devices.

2. Know your team

Every team has a constitutional map for their coding style and some are more sophisticated than the others. The more generic detail you need to know is regarding the programming paradigm that everyone is using in the team. If the team has agreed on the functional way of programming, or if the team prefers composition over inheritance, then stick with it. The more specific details are regarding the writing conventions in the code. For example, how many lines does the team put after an if statement? Or how is a function declared? Is it with camel case and no special characters and do they use informative names for their functions and variables? If yes, again, try to learn how to be consistent with those methods to save you some time in the long run of the pull request.

3. Know the skill matrix of your team

Teams are divided into UX/UI developers, front-end developers, back-end developers, team leaders and product owners. Eventually, everyone on your team will have to give you a more specific advice on a certain subject and that’s why you should be careful with the people you choose to review your code. For example, if you’ve done some work on the User Interface, then you may include the UX/UI developer, the front-end developer and the team leader. You may also want to show the working feature to the product owner, just for a piece of feedback on the look and feel of the newly created UI. For a back-end solution, the back-end developers and the team leader might be the best people to review that piece of work.

Code reviews are important in your team. They give a clue to the team of where the development is going and if the standards that have been defined in the team are kept to the certain maximum. I hope that this article also helped you to start doing meaningful pull requests as well.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.