Have you ever come across a line of code that made you pause and think WTF is going on here? You get in a huff because some careless programmer did something completely wrong and wrote poorly formatted, incomprehensible code.

Then you do a git-blame and discover that you wrote the line yourself.

Whether it’s poor logic, the use of tabs over spaces, or even a brilliantly crafted solution that is difficult to comprehend, reading code can feel like translating a cryptic language. When nobody on your team shares what they’ve coded with each other, the codebase — no matter how well architected — will quickly fall into disarray. The solution?

Code reviews!

Code reviews are a fantastic way of transferring knowledge between teammates and ensuring that quality code is being committed. Regular code reviews are one of the many processes that effective development teams need, and they play a key role in ensuring the long-term maintainability of a project.

This article will cover what code reviews are, why your team needs to be doing them, and how to get the practice started if it’s not currently part of your team’s routine.

What is a code review?

A code review is the analysis of another developer’s source code. These reviews help find mistakes and improve overall code quality. Code reviewers are responsible for making sure that only clean, well-structured code is allowed into the codebase. Reviewers look for the proper use of design patterns and coding styles, offering suggestions and giving constructive feedback when they encounter code that does not meet the expected quality level.

By both reviewing other people’s code and having your own code reviewed, you’ll get exposure to a variety of perspectives and learn a lot about what constitutes good code. As you grow in your career, you’ll figure out what type of code reviews work best for you and your team. But if you want some inspiration, check out the list below!

Things to Look for When Reviewing Code:

• Anything not meeting the Definition of Done
• Commented out code that could be removed
• Descriptive variable names
• Straightforward logic
• Proper use of design patterns
• The addition of unit tests covering the new feature or bug fix
• That existing coding styles have been followed (things like spacing, indentation, putting code in the right file, etc.)
• Descriptive comments are used where needed
• That the code actually addresses the problem that needs to be solved
• Front-end code is accessible and matches UI/UX designs

To put it simply, your goal as a reviewer is to enforce good coding standards so that your entire team can continue to quickly read, understand, and extend your code.

When you find some code during a review that needs to be changed, you let the person submitting the code review know about it. The original programmer then applies the fix and BOOM! Your code quality levels up!

Now before you get drunk with power, not every piece of feedback given during a code review has to be addressed. Sometimes team members have different opinions on what constitutes “good code”. While the majority of disagreements can be solved by referencing your team’s standards, it’s impossible to cover every scenario with documentation. As you participate in more code reviews, you’ll gain a better understanding of your teammate’s coding styles. As that understanding grows, negotiating code changes will become easier.

Once changes are agreed upon, the code reviewee will implement the changes and submit them again for review. This cycle continues until everyone agrees that the code is good enough to pull into the codebase. After the code is merged, the code review is complete and the developers can move on to their next task.

So now we know what a code review is, where does this review actually take place?

Code reviews can be conducted in a variety of ways. It doesn’t matter if your teammate rolls over to your desk for an informal walk-through, or if everyone submits formal pull requests using tools like GitHub or Bitbucket. Hell, you could even use a message in a bottle or share the code on Snapchat.

It doesn’t matter how you conduct the code review. What matters is that you do the code review.

While I prefer a mix of in-person and online code reviews, your team will have its own unique needs. Some of you may be completely remote, making in-person reviews infeasible. Others might prefer talking over the code as an entire team. Ultimately it is up to your team to decided what works best.

To help you make that decision, here are a few ways in which the different styles can shine, along with some limitations:

Real-time reviews give the reviewer a chance to deliver feedback in-person and give the reviewee a chance to practice their presentation skills as they walk another developer through their code. Feedback can seem less harsh because you get to hear and see the other person. The cold, starkly typed words of a comment on a pull request can sound completely different when said in person. However, pushing back on a code reviewer’s request that you believe to be unreasonable or incorrect can be difficult for some people to do in the moment.

Online reviews are useful because they can be completed asynchronously. This is great for distributed teams or for teams with busy schedules. The reviewer can look at the pull request whenever they have time. By leaving comments on specific lines of code, it’s easy for the reviewee to track what needs to be changed. These types of reviews also allow multiple people to more easily participate, since anyone can make comments at any time. Reviewees can react to comments in real time and ask for clarification or defend their coding decisions.

Now that you’ve learned what code reviews are, maybe you’re wondering why I consider them to be such a vital part of effective teams. That’s exactly what we’ll cover in this next section.

Why do I need someone else to look at my code?

Code reviews are a must. Even if you’re the only developer on your project, you should be finding someone else to look through your code. Unless you’re writing code for a side project or Proof of Concept exercise, collaboration is vital to a healthy codebase.

Remember, nobody knows everything about software development. No matter how good you are, you will never know it all. There is always something new to learn, which is exactly why you want to look through lots of people’s code and share your own. Interacting with other’s code will expand your knowledge and help you grow as a developer. We all have our own strengths, and code reviews are a way to share those strengths with others.

Even the most experienced developers have a small breadth of skills compared to what type of work is out there. It’s literally impossible to be good at everything, and anybody who thinks they don’t need to keep learning will soon find themselves out of a job.

Code reviews give both the reviewer and reviewee a chance to teach each other. Veteran developers can always find something new to learn from their junior teammates, and vice versa. Because software development is an ever-changing field, you will have a unique perspective on how to build great software only a few years into your career. Reviews are an opportunity to share and evolve that perspective.

Hopefully by this point I’ve convinced you of the usefulness of code reviews. They truly are critical to the success of a project.

But what should you do if you’re on a team that doesn’t have a regular code review habit? This next section will give you a few ways to help convince them.

How do I get my team to start doing code reviews?

Teams who don’t have code reviews will release awful products. That alone should be reason enough to get started. If your team is not currently doing code reviews, you have a phenomenal opportunity to provide a ridiculous amount of value to your team.

Code reviews result in a better product and ultimately save hours of work by insuring new additions to the system are beneficial. You can’t afford to not do code reviews. Without regular reviews, your product will become increasingly complex, unmaintainable, and inflexible. Scaling it for a larger user base will be difficult and expensive. Developers will become unhappy and their productivity will drop.

You don’t want that, do you? Then start doing code reviews.

The easiest way to get your team to do code reviews is to leverage technology. Using tools like the pull request feature on Bitbucket or GitHub allows you to easily set system-controlled rules that force explicit approval for any new code changes. This means you will not be able to merge your code unless another developer looks at the code and puts their stamp of approval on it. Your team can always get around this by clicking the “Approve” button without really reviewing it, but if that’s happening you should be looking for a new job.

However, change is difficult. You can’t just go update the settings in GitHub and expect your team to start doing code reviews. That’s an easy way to frustrate everybody.

First, help your team understand the value of code reviews so they understand why they should begin reviewing each other’s work. Show them this article or the countless others on the Internet arguing my same point. Focus on how your everyday life as a developer will get better with code reviews being part of your team’s regular routine.

Once everyone is on board, turn on the tools and let the system do its thing.

There will be rough patches. Occasionally you’ll long for the days you could quickly commit that missing semi-colon right to master, but try to resist the urge. People will complain. They may even turn off the pull request approval feature. Keep reminding yourselves why you’re doing this and don’t fight the process.

Eventually the habit will stick, and your team’s skills will improve. The code base will become more stable and deployments will get easier. Point out how much better things are getting and celebrate as you watch yourselves ship great code more quickly.

And that’s it! We’ve covered the what, why, and how of code reviews, so you’re now ready to go out into the world, confidently reviewing all code that cross your path. Even if your team already does code reviews, see if you can find an area of the process that could be improved and give it a test run on your team.

Remember, code reviews are vitally important. As you and your team read each other’s code, you’ll all increase your knowledge and skills. By regularly reviewing your code, the quality of your codebase will improve. You’ll be able to add new features more easily and even reduce the number of bugs in your system!

There’s really no excuse to skipping this vital process. All things being equal, a team that does code reviews will be much happier in the long run than one that doesn’t.

If you have any great tips on code reviews that weren’t included in this article, send me a message!

This is the third of nine articles delving into the processes that every effective development team should use. Stay tuned for more!