Rollout IT Blog
Published in

Rollout IT Blog

Pull Request Culture: How to ensure the high code quality, how to bring your teammate to a higher level, how to react when your code has review notes to fix

Peer review dates back to 1731 when the Royal Society of Edinburgh had a system in place to review medical articles for publications, scientists used to circulate their research papers among their peers to elicit responses or critiques which helped them better their work, from then on peer review has trickled down to every field that requires constant improvement and innovations.

Software development industry is no different, it requires continuous improvement, knowledge sharing, state of the art innovations and this can happen only with constant reviewing from their developer counterparts, which happens mainly through peer reviews or what we call it here as code reviews or pull request culture.

Whenever a developer writes a code, he shares them with his fellow developers or reviewers by creating a pull request by sending a request to these reviewers who then review the pull request and assess the correctness and the quality of the code by adding their changes or opinions.

Pull requests are created using version control systems, which is a software that records the changes made to code over time in a special database called a repository. Version control software keeps a track of the history of changes made to the code and is accessible to everyone working on a software development project.

The version control software can be either centralized or distributed and generally distributed version control software is preferred since they are easy to work with and not dependent on an external server.

The popular version control softwares in use are Git, Beanstalk, GitLab, PerForce, AWS CodeCommit, Mercurial, Microsoft Team Foundation Server, Bit Bucket, etc.

But what is the purpose of having a pull request culture?

Just as peer reviews help scientists, authors, medical writers to cross-verify their work with the help of their colleagues’, code reviews help software developers to fine-tune their codes, remove bugs, look out for problems in infrastructure and design, identify security issues, performance issues, and other inconsistencies.

Let us look at some of the major benefits of pull request culture and how it helps build high-quality code.

Reduces the technical debt of bad code

A study conducted in 2018 by Stripe and Harris Poll found that a technical debt of around 85 billion dollars is incurred annually due to bad code and 42 % of developers spend their time and resource correcting these poor-quality codes a time that can be used otherwise for building better software. Developing a healthy code review culture greatly reduces the technical debt on software companies.

Knowledge sharing

Collaborations during code reviews can help better your skills and acquire knowledge that will prevent you from repeating similar mistakes made in the past, develop alternate solutions, learn best practices, etc.

Quality assurance of codes

Code reviews help you finally arrive at a code that is easy to read, easy to understand, and maintain, this can only be possible by developing a healthy pull request culture where reviewers can communicate with the author and other team members to provide clarifications and simplify messy codes.

Security and Performance checks

Common flaws can be easily spotted during the review of the pull requests, bugs can be mitigated and other mistakes that escape the developer’s eye can be spotted during a code review.

Open atmosphere

Pull request culture helps software companies to develop an open atmosphere where they can share and review each other’s codes without bottling themselves up in silos preventing them from sharing their knowledge, this kind of culture builds a positive bond among team members and the ownership of the code lies with everyone and not just one single person.

When a code goes out for reviews two things can happen, a teammate who reviews your code can be too harsh or the teammate who has created the pull request, let’s call them reviewee here, can take the reviews too personally. To mitigate these issues, we need to build a healthy pull request culture where the reviewer needs to help the reviewee to reach a higher level of knowledge and at the same time the reviewee has to react positively when there are review notes to fix

How can the reviewer help a team member(reviewee) to reach a higher level of knowledge?

It is best to practice proper code review etiquette to make sure that the ultimate goal of a perfect software code is achieved, so how can a code reviewer achieve this?

Refrain from making code reviews personal

It is best to refrain from bringing professional rivalry to code reviews by being focused to review only on the code and not the coder. Sometimes personal statements like “you need to return out of this function immediately” can be replaced by “return out of this function immediately”.

Keeping the words crisp, clear, and to the point and very strictly separating code discussion from personal discussion can make a huge difference.

Explain the code

It might be easy to just say this code is wrong, but this triggers the reviewee to defend his code leading to a war of words with each person ends up defending their perspective on the code, instead, the right path to take would be to try to explain the mistakes that have occurred and impart them with correct knowledge.

Realize that your contribution provides value

When you are reviewing a pull request you are contributing towards continuous integration and continuous delivery of code, continuous iterations are possible only with code reviews thus helping the team deliver good quality codes instead of last-minute integrations.

Don’t let the comments escalate into a fight

Sometimes there can be heated arguments that occur during code review exchange where each party is yelling at each other to prove their point of view, a simple change of using informative statements to explain instead of passionate judgmental statements can make a world of difference preventing things from escalating or involving management.

Approve or request changes to the pull request

Just commenting on the pull request can leave the reviewee in the dark and they will not know if they can move forward, comments or discussions might be great but it is also very important to either approve the pull request or request changes to the same so that the reviewee can move forward with their work.

Review codes early

Code reviews take up a lot of time and energy since every additional discussion or comment takes away from writing new codes, there might be additional pull requests on the code to be reviewed creating review bottlenecks, thus it is best practice to review the codes early so that the project can move forward.

Once a code is reviewed there will be a few review notes present which the reviewee has to fix, so how should a reviewee react when he has review notes to fix?

The first step is to fix the code

When a reviewer has spotted an error, bug or has not understood some portions of the code instead of jumping into discussions or comments the first step to take is to try and fix these errors, because if the reviewer found errors, then it is highly likely that others too will spot the same errors. In such a situation the first line of defense is to check yourself first and try to improve.

Avoid taking reviews personally

Understand that the reviews are done for the betterment of the software development life cycle and not a personal attack or a question on your skills, always try to ask yourself what is the constructive takeaway from a particular review.

Explain your pull request

When you create a pull request give a clear description and a title to the pull request,

Try to make the code chunk smaller which makes it easier for the reviewer to review the code resulting in a faster turnaround time, a 3000-line code chunk is very hard to review, build a pull request culture in your team that encourages requests that are easy for the reviewer.

Appreciate the good comments

Appreciating a reviewer’s comments and letting them know that their reviews have been helpful is a huge morale boost for them and helps build a good rapport with your fellow developers.

Avoid long clarifications under the review note

Leaving a long line of comments clarifying a particular review note can come across as arguing even if it is not meant to be that way, so, it’s best to sometimes discuss these clarifications on slack or with a phone call and then leave a summary of the clarification under the review note for the team members to see.

React to things you find objectionable

If the comments are rude, if they are nitpicking on the style of the code, or are giving you a hard time by constantly changing their goals for the project causing a delay in your work then it is best to address these issues amicably. This will cause them to change their behavior and develop proper reviewing etiquettes.

Conclusion

Pull request culture or code reviews are a modern take on the peer review culture that has existed from the time scholarly articles have been published, pull request culture is specific to the software industry and it does not have a specific set of rules or languages to follow, it is something that is developed over time by people and lot factors such as personality, ego, professional rivalry, etc., come into play while doing a code review.

It is extremely important to maintain the dignity of the peer review culture by trying to follow the right etiquettes by encouraging your team members to adopt these etiquettes so that pull request culture becomes a way of sharing knowledge, promoting transparency of the entire software development life cycle and most importantly bring up the reviewee by opening him up to new concepts and ideas.

The ultimate goal of the pull request culture should be to provide a platform where everyone can work towards bettering a product before it goes live by sharing knowledge, correcting errors, fixing bugs, and aligning everyone on the team towards the final goal of delivering the best product. It is worth creating a positive pull request culture so that developers don’t spend all of their time on just reducing the technical debt or on maintenance issues, they can focus their energies instead on innovations and developing state of the art technologies.

You keep your softwares always up-to-date, right? Be informed about the IT & Remote work news and click on the link: https://mailchi.mp/rolloutit/newsletter

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store