This article is a continuation of a previous article Be a Janitor of Coding. So if you haven’t seen that article go ahead and check that out. We will be right here when you get back.

We have looked at what it means to write clean code and clean coding best practices we can implement in our projects to make it more developer-friendly. In this article, we will review other software practices we can introduce in our workflow to raise the bar in our projects and organization.

In this article, we will discuss:

What is Code Review?

Software, for now, has been written by human beings, therefore, it often has mistakes and errors in them. Developers count on different tools like IDEs, analyzers, interpreters, and compilers to help them identify and fix these mistakes before they reach production. Outside of using these tools; human beings can also help each other to mitigate against these mistakes through code reviews.

Code Review is simply the process of examining written code with the purpose of identifying mistakes and providing suggestions on how to fix them.

Code reviews assist developers in understanding the codebase. It’s a great way for junior developers to grow quickly and write cleaner code by having a much-experienced developer review their code and share their expertise.

Benefits of Code Review

Doing code reviews keeps in line with the message of this post series. The message of simply writing better software. Everyone can benefit from code reviews regardless of the methodology being used. No one developer knows about only a specific part of the codebase. Remember that time you were asked to fix that issue but you’re not that one who implemented it but you still have to “figure it out”. It would have been much easier if what was done was shared in a code review right? Code reviews simply help knowledge sharing across the entire team.

Here’s a quick list of the benefits of code reviews.

Code reviews share knowledge

Having anyone person knowing everything about a project is never a good thing. Project managers put their projects at risk if something should happen to this sole savior. Developers might feel some sense of “job security” but that doesn’t last long as you can kiss your vacation days goodbye. Something breaks, you’re the sole programmer remember, so it’s 100% your responsibility to fix it.

Code reviews give agile teams immense flexibility, as a result, teams are better able to pursue new work as no one is the “critical path”. Developers can tackle different work in various areas, front-end, backend, DB etc.

Code reviews improve the accuracy of estimates

When new features are scheduled to be added to the existing code, the original developer can provide an estimate. Any code reviewer that was exposed to the codebase is then exposed to the complexity of the codebase. This knowledge is shared among the team members that results in multiple inputs in the estimate that makes the final estimate more reliable and accurate.

Code reviews allow time off

As mentioned, being the sole savior you might feel good in the beginning, if you are that type of developer. However, this feeling is quickly outgrown as you have 100% responsibility for the success of this project and the sole point of contact on a piece of code. Similarly, nobody wants to venture into a critical piece of code they have no knowledge about. It’s really daunting.

Sharing knowledge through code reviews takes the pressure of the original developer in a way that he/she can easily take the time-off without delay as no one is the sole point of contact.

Code reviews provide mentorship to newer developers

Code reviews are really a great growth enabling practice for a junior developer (and senior) as he/she quickly learns the industry best practices when they get to learn from a seasoned practitioner. Code reviews also help with that tunnel vision syndrome when we get a new pair of eyes on issues that have been affecting the project timeline.

Drawbacks of Code Review

“The trouble with most of us is that we’d rather be ruined by praise than saved by criticism.” – Norman Vincent Peale

Code Reviews are one of those things that make developers squirm. The thought of another person, perhaps an entire room of other developers glaring at the screen criticizing your work leaves you talking to yourself. Did I write enough test cases? Did my comments explain their intent? Did I use industry best practices? Despite the benefits of code reviews, there are a few drawbacks that impact the developer’s egos and time.

Developers Egos

Criticism, depending on the delivery and who you are can be an opportunity for growth or for embarrassment. Developers are close to their work. As they say, your work is a reflection of who you are and as such when developers get criticized in a code review it is often wrongly taken personally leaving that person feeling as if it was an attack on them.

Time Consuming

Developers are funny little creatures, ridiculously selfish with their time. Developers require a constant stream of productivity to be able to remain focus and creative. You can imagine the constant borage of distractions from all corners of the office, answering phones, replying to messages, not to mention code reviews. Code reviews depending on the extent of the review require allotting in enough time for it to be beneficial. Perhaps doing code reviews before committing to the main branch can help. Work out when is best for your team. Regardless, it’s time well spent.

What to look for in a Code Review?

I will have to admit that this topic can be a little hard to define as there are so many things you can look for in a code review because there are many things to consider. Are you looking at architecture, design, functional requirements, non-functional requirements? You get the picture.

Since it’s almost impossible to cover everything in this aspect we will only look at a few things to look out for when conducting a review.

Formatting and style

Do you have a style guide that your team is following? For eg. using spaces over tabs, starting right curly brace ( { ) on a different line or the same line as a function declaration. Having a consistent format makes code easy to read and avoid those teeth cringing moments. OCD Alert.

Naming Conventions

Do variables, methods and class names follow a standard?

Design

Does the codebase follow any best practices SOLID design principles, OOP principles etc?

Readability & Maintainability

Can others understand what the code is doing? Are there any design patterns that can be implemented to make for a cleaner solution.

Functionality

Well more evident than most, does it WORK?

Considerations when conducting a Code Review

No opinions, only facts

Developers should understand why you are giving the recommendation that you are giving. When comments start with “It should be” or “I like it if you would”, leaving questions like why. What’s the reason for doing a thing a particular way versus the other? Be specific as possible like functions should be no more than 100 lines. Don’t Hard code values it’s bad practice. Provide context where you can.

Avoid jokes and sarcasm

Remember that ego thing, yah, it’s still there. At the end of the day, people do get attached to their work, people do care, people do have feelings. If the person under review doesn’t really understand your jokes it can be interpreted in a wrong way that causes the reviewee to inadvertently shut down from a wonderful learning experience. This goes especially for multicultural organizations that have a culture barrier to do deal with on top of all the different Enneagram types.

Make code reviews in person

Sometimes an online comment may not be enough to explain your thoughts. Sometimes online communication is just not the best medium.

Ask others for an opinion

One of the mistakes I made just starting out was trying to do it by myself. Mistakes tons of developers make when just starting out. Asking for help in a general sense sometimes seen as weakness or the inability to things done. This stigma is easily translated into our professional lives too. Knowing when to ask for help or even get a second opinion is one of the most important skills you can learn. Don’t be afraid to ask for help.

Conclusion

We have covered what code reviews are and why it’s important to implement them in our workflow regularly not just once every quarter. These practices do enable us to write better software. Leave a comment below on anything related to code reviews that you think might be beneficial to others.