DEV Community: Reviewpad

How Reviewpad is Putting the Reviewer Assignment Problem to Rest

Reviewpad — Fri, 24 Feb 2023 10:52:20 +0000

Streamline your code reviews with Reviewpad. Our advanced algorithm suggests the best reviewers for your pull requests, making your workflow faster and more efficient.

Are you tired of manually assigning reviewers to pull requests on GitHub? Do you find it time-consuming and difficult to ensure that each pull request is assigned to the most appropriate reviewer? If so, Reviewpad has the solution for you. With its new Code Reviewer Assignment feature, Reviewpad can help you streamline your code review process and ensure that each pull request is assigned to the right reviewer.

The Problem with Manual PR Reviewer Assignments

For teams working on GitHub, the manual assignment of reviewers to pull requests can be a time-consuming and error-prone process. As development teams grow in size, the need for an automated review assignment mechanism becomes increasingly critical. Without such a mechanism, developers must spend valuable time manually selecting the most relevant and available reviewers for each pull request. This process can take critical time away from development tasks, slow down the review process, and lead to bias in the selection of reviewers.

In addition, it can be challenging to ensure that reviewers have the necessary expertise to review the code in the pull request. This can result in longer review cycles, errors in the code, and delays in the development process.

Reviewpad's Innovative Solution for Effortless Reviews

Reviewpad's Code Author Reviewer Assignment Mechanism aims to solve these problems by automating the assignment of reviewers to pull requests. Reviewpad analyzes the past contribution history of code authors and uses that data to suggest the most appropriate reviewers for each pull request.

In this process, Reviewpad considers two factors when assigning a reviewer. Those are

Relevancy and
Availability

of the reviewers.

The relevancy evaluation is based on the authorship of the code. It analyzes how many lines of code have been written by possible reviewers in the latest version of the impacted source files.

The availability evaluation is based on the number of open reviews per reviewer, which ensures that reviewers with too many open reviews are considered unavailable.

If there are no reviewers available or identified by the algorithm, a random user within the organization will be assigned as the reviewer for the PR. This fallback mechanism ensures that the pull request does not remain unreviewed and that the code changes are still scrutinized by someone in the organization.

The Crucial Role of assignCodeAuthorReviewers Function

Reviewpad's Code Author Reviewer Assignment Mechanism is powered by the assignCodeAuthorReviewers function, a built-in function that takes several parameters to determine the most relevant and available reviewers for each pull request.

This function is critical as it allows teams to customize the review assignment process to fit their specific needs.

Understanding the Parameters of assignCodeAuthorReviewers

The assignCodeAuthorReviewers() function takes three parameters.

Total (Optional): This parameter specifies the total number of reviewers to assign to a pull request. The default value is one, but you can change it to assign more than one reviewer to a pull request.
Excluded Reviewers (Optional): This parameter is a list of reviewers to exclude from being assigned to a pull request. You can use this parameter to exclude specific reviewers who might not be appropriate for the review.
Max Reviews (Optional): This parameter specifies the maximum number of open reviews per reviewer. If a reviewer has more open reviews than this value, they will be considered unavailable and will not be assigned to the pull request. If we don't specify a value to Max Reviews, the algorithm ignores that parameter and considers reviewers regardless of the number of open reviews they have.

Examples of assignCodeAuthorReviewers at Work

Let's look at an example of how you can use the assignCodeAuthorReviewers function in Reviewpad.

Example 1

$assignCodeAuthorReviewers()

This example uses the default parameters for the assignCodeAuthorReviewers function. It will assign one reviewer to the pull request based on code authorship and availability.

Example 2

$assignCodeAuthorReviewers(3)

This example assigns three reviewers to the pull request based on code authorship and availability.

Example 3

$assignCodeAuthorReviewers(2, ["user1", "user2"])

This example assigns two reviewers to the pull request, but it excludes "user1" and "user2" from being assigned as reviewers.

Example 4

$assignCodeAuthorReviewers(1, [], 2)

This example assigns one reviewer to the pull request, but it limits the number of open reviews per reviewer to two.

A Step-by-Step Guide to Using Reviewpad's Code Author Reviewer Assignment Feature

Now that you have a better understanding of the assignCodeAuthorReviewers function, let's take a look at the steps of the workflow of the Reviewpad's Code Reviewer Assignment Mechanism.

Step 1: Sign up for Reviewpad and integrate it with your GitHub account. (Installation Guide ↗︎)

Step 2: In your repository, create a new workflow with the following code:

workflows:
  - name: Code Author Reviewer Assignment
    if:
      - '!$isDraft()'
    then:
      - $assignCodeAuthorReviewers()

Step 3: Customize the assignCodeAuthorReviewers function to fit your specific needs. You can use the parameters and variables mentioned earlier in this article to customize the review assignment process.

Step 4: Create a draft pull request in your repository.

Step 5: When the pull request is ready for review, move it to the Ready for Review status.

Step 6: Reviewpad's Code Author Reviewer Assignment Mechanism will analyze the relevancy and the availability of the reviewers and suggest the most appropriate reviewers for the pull request.

Discovering the Advanced Functionality of Reviewpad

It's important to note that Reviewpad's Code Author Reviewer Assignment Mechanism is a powerful tool that can help you streamline your code review process. However, it's not a replacement for good code review practices. It's still important to ensure that reviewers have the necessary expertise to review the code in the pull request and to maintain a clear and organized review process.

In addition, Reviewpad provides other powerful features such as automated pull request labeling, automatic pull request merge, and enforcing branch conventions. By using Reviewpad's Code Reviewer Assignment feature in combination with these other features, you can create a robust and efficient code review process that saves time and reduces errors.

Fluid Pull Requests

Reviewpad — Thu, 05 Jan 2023 17:32:00 +0000

By Freddy Mallet

Pull Requests have become the backbone of the DevOps movement: the faster, the safer, the better. But the code review step, this systematic and synchronized communication task between humans, inherited from ancient times, slows down the overall development lifecycle for an illusion of safety. It’s time to introduce the Fluid Pull Requests paradigm.

Back in 2008, GitHub introduced the concept of Pull Request and, by doing so, significantly eased the contribution to open-source projects. For the first time, it had never been so simple for two strangers to collaborate on the same code base. At that time, the only purpose of a Pull Request was to provide a safe way to suggest code changes and discuss them in a collaborative interface.

More than a decade later, 170 Million [1] Pull Requests are created each year on private projects and 30 Million on public projects. So the concept has been embraced by the overall software industry and has become a de facto standard. During the same period, the DevOps movement took off, and nowadays, Pull Requests are the backbone of any automated SDLC (Software Delivery LifeCycle). On each Pull Request, many highly valuable tasks are fully automated: building, testing, static analysis to spot bugs, deployment on staging environments, etc. All this DevOps movement could be summarized in one mantra: “The faster, the safer, the better”. Starting in 2015, the DORA (DevOps Research and Assessment) [2] team has identified four key metrics that indicate the performance of a software development team. Three of those four metrics illustrate this mantra: Deployment Frequency, Lead Time for Changes, and Time to Restore Service.

So today, the lifecycle of a Pull Request should be a matter of a few hours, but it is always a few days or even a few weeks. Developers managed to automate many things, but we still have in the middle of each PR lifecycle a systematic and synchronized communication task between humans: the code review step. This inflexible code review step, inherited from 2008, slows down everything and is the main bottleneck.

Why do we keep on accepting to pay such a price? Why do we keep on pushing the stop-the-line button on each PR? Because no software, no static analyzer, nor AI will ever be able to formally prove that a code change is safe and maintainable. Our tooling will keep evolving to spot more patterns but proving the absence of problems is an unsolvable challenge. So we rely on humans to do so. But humans are even less efficient at spotting problems, tracking a flow of execution, or keeping more than 10 variables in our working memory. This is especially true when each PR has to be reviewed. Developers are progressively desensitized, and LGTM symptoms arise. We’re just accepting to pay the price for an illusion of safety.

So what do we suggest doing? As we said, Pull Requests are nowadays the backbone of the DevOps infrastructure, so we can’t work without them. Moreover, today there is no code analyzer to prove the absence of bugs or vulnerabilities, or critical design flaws, so we still need developers to review some code changes. The only problem is that this code review is done systematically, regardless of the context, and always involves synchronous communication between humans. Here is where the Fluid Pull Requests paradigm knocks on the door.

At the core of this Fluid Pull Requests paradigm is the capacity to adjust the code review process based on the sensitivity of the code change, either to lighten or strengthen it. This sensitivity evaluation must take into account several different elements. We can mention, for instance, the seniority of the developer on a code base, the complexity of the code change, or the history of changes. Based on this sensitivity evaluation, you can specify and automate several code review processes to automatically approve and merge, do an asynchronous review, assign several reviewers, and spot the most sensitive parts of the code changes. For instance, if a database migration script is added, it could be relevant to involve the database team, but only to approve this piece of code.

I guess you got it: Fluid Pull Requests is an extension of the Pull Request concept, to increase both the throughput and safety of delivery. We still rely on human review, but only when it’s the most relevant, and in a very driven way. Instead of reviewing everything every time, we only have the most critical changes reviewed by the most impactful reviewers.

References

[1] Octoverse Report 2021: https://octoverse.github.com/writing-code-faster

[2] DevOps Research and Assessment: https://www.devops-research.com/research.html

How to improve code review culture (for managers and CTOs)

Reviewpad — Mon, 27 Sep 2021 16:03:55 +0000

We have discussed best practices and principles. Now is time to get to the task and start arguing about practicalities. If you are leading a team, and you need your code reviews to be better, more effective, and a more perfect tool for team-building, what can you actually do?

We have the answers.

Define what the truth is

Does that title sound excessively ambitious? Is Reviewpad finally becoming political? No to both!

What we mean is that you need to produce and maintain a well-documented source of truth to keep every member of your team on the same page. Code reviews are essentially about co-ownership of the final product, and at their core they are a collaborative endeavor. If all members of the team (especially the more opinionated) don't agree on some basic principles, this can undermine the whole deal.

Here's what this document should contain (at least):

A clear-cut definition of the team's priorities. What do you do in special/urgent cases? Can you skip tests when the team is in a hurry or not? Should code reviews supersede other work when the deadlines are getting close? What constitutes "a hurry"? What qualifies as "getting close"? Etc.
Establish a pull request description template. And make sure people use it.
Establish a code review checklist. And make sure more experienced developers, who probably won't need a checklist, don't fail to keep to its standards.

Leverage automation

Code reviews are an engaging, interesting, personal experience. They are not an afternoon spent nitpicking for teeny bugs that a linter can easily find.

We have written an article where we detail where and when automation is a must-have, and also some of our thoughts about when you can't rely on it. We recommend going through it, but the bottom line is simple: figure out what kinds of work a machine can do better than you, and let it. Linters, test coverage tools, etc. are great tools that you should use to your advantage.

In regards to pull requests: tell your team to favour what's easy

We tend to focus much of our attention on how to improve the review itself. We do, however, know very well that the quality of the review is heavily reliant on how sensible requests are.

Speak to your team, and create clear guidelines: make life easier for the reviewer.

Encourage pull requests of manageable size and clear context , both of which can be defined in the document mentioned earlier.

Everyone reviews code

This one is self-explanatory, but it must be said: everyone needs to be doing reviews. There's no advantage in overworking your most senior teammates (which happens too frequently), and there's a lot to lose in terms of learning and improvement from keeping juniors from doing them.

Be sensible in how you assign code reviews, of course , but share the wealth!

Ban LGTM

Avoid rubber stamp reviews as much as possible. Code reviews are a process of continuous improvement , and every bit of work you do should follow in this spirit. If there are in fact no mistakes, and the code is absolutely pristine, share this achievement with the rest of the team..

Power to the people

Team spirit is fundamental. Co-ownership is key. One of the reasons why code reviews sometimes fail, and create rifts among teams, is that people are working towards their own views and goals about the sprint/product instead of agreeing on collective goals.

Let your team control the review process. Allow the establishment of goals to be a collective process, and have everyone commit to it. This will naturally lead to what should be encouraged (positive/constructive/actionable) comments, instead of what should be discouraged (negative/damaging/empty) ones.

To empower your team is to make them responsible.

Get Reviewpad

We may be a little biased, but the fact is we are using Reviewpad to do our reviews while we build it. We have been doing it from really early on.

Try it out yourself

Managing expectations in code reviews

Reviewpad — Mon, 06 Sep 2021 10:55:57 +0000

Best practices are one thing that surely matters. Improving standards is always good. Who could argue against that? But what do you expect to get from code reviews? How do you expect the experience to go? Managing these expectations, especially when it's often so hard to measure results, can be daunting. Here are some thoughts on how to manage this.

Embrace the qualitative

Code reviews are about continuous improvement. That means it won't always be easy (sometimes it will be impossible) to quantify how much you've improved. Any metric you can come up with to measure return on investment (ROI) is likely flawed, and will probably tell you as much about the quality of your other processes as the reviews themselves.

We do know some things, such as the skyrocketing costs of catching bugs later, but the value of code reviews far exceeds that of simple debugging. The kinds of improvements code reviews achieve can sometimes only be felt years later, when an entirely different team is charged with updating the codebase and finding easily readable code.

Some things you just can't measure. We need to accept this.

Expect people will be reading you

This goes for several stages of the process. Sometimes developers will tend to forget that all their notes and comments will be read by a person that is also a teammate. A person with feelings, issues, and varying degrees of seniority and skill. Sometimes developers will tend to forget that their code will have to be read and understood by people over time.

This means you must be mindful of what you're telling others, but also what you're asking of them. A couple of examples:

Massive pull requests will probably lead to shorter and more superficial comments. Is this what you want?
Reviewers will need to place themselves. Have you provided the context that will allow them to fully understand what you're going for?

Always keep in mind: if you're typing it, expect someone will read it.

People make mistakes

One of the hardest things to manage regarding code reviews is the frustration that comes from reviewing bad code. Lots of mistakes, bad choices in terms of style, and unreadable code.

This, however, is almost inevitable. You're going to have to deal with bad code sometimes.

It's important to not let that frustration boil over into aggressive or hurtful comments. Communication must always be geared towards improvement, both of the codebase and the team. Code reviews are a great way for everyone to learn from mistakes, but that depends on the kindness of the reviewers.

Be mindful of people's schedules

Full-time code reviewers are rare. And even if they weren't, they would have a schedule anyway. Sometimes we expect our colleagues to pick up whatever is our priority as if it is also theirs, but that's not how it works.

Code reviews are often treated by teams like an afterthought, something that can be done by anyone "as soon as they have a minute". This is never the case, and reviewing is a task that should be treated with the same consideration as any other. Assign your reviews in due time, and expect people will be busy.

Best practices matter

Your expectations of code reviews should always take into account how they are being done. Are you posting the pull requests to a public channel and expecting anyone to pick them up? Then you shouldn't be surprised no one does, or if it takes them a long time to do so. Are you bundling up all the reviews and doing them at the end of the week? Then you should expect a lot of confusion. Are you reviewing for hours on end? Expect mistakes.

The full benefit of code reviews heavily depends on them being integrated into a continuous code-review-centric operational model, and the more your practices reflect this, the more you can expect from them.

Code reviews are about your team

An underappreciated aspect of code reviews is how they are a collective endeavor. We believe in them as a form of fomenting co-ownership of the codebase, and always tell reviewers to not think of what they're looking over as someone else's work. It belongs to the whole team.

Code reviews, when done right, will expand the whole team's knowledge of the product, and help everyone learn with both the mistakes and the skills of everyone else.

This is probably the most important thing you can expect from code reviews, if you make them work in that way: you can expect them to be not only a guarantor of your code's quality, but also a true engine of team building.

What are your expectations for code reviews? Did we miss something important? Drop us a line on Twitter (@codereviewpad) and let us know!

A code review checklist from Reviewpad

Reviewpad — Fri, 20 Aug 2021 09:25:02 +0000

Not everyone will need a checklist for code reviews, and not all code reviews will fit into your checklist. We accept that, and we have written about how some more senior developers sometimes even think they get in their way. They are a very good idea, however, if you haven't yet reached a comfort zone with your reviews.

A good checklist will keep you consistent. It will also prevent mistakes and omissions.

Here's our humble proposal, just to get you started:

Are all requirements met? 📋

Requirements are the basis for all development. Regardless of what the project you're working on is, and its scope, you will have a series of basic (and not so basic) requirements that the code must accomplish.

Check them, one by one.

Find the relevant code.

Review it.

Job done.

Are code conventions being followed? 🤝

Code conventions aren't bylaws, and they will change from project to project, and from language to language. They must be kept consistent throughout, otherwise, you can give rise to a whole ocean of troubles.

Whatever's been established for the project and language you're working with, it's your job while doing a code review, that everything is up to snuff. That ranges from things as trite as indentation to things as meaningful as comments.

Consistency is the key word.

Are magic values/scenarios accounted for? 🦄

What would you think if you saw the number 259200000 in the middle of a particularly important piece of code about dates (i.e. days and months, not romantic liaisons), with no explanation?

And that number is absolutely key for the way the function works?

You wouldn't be happy, would you? Well, that's the number of milliseconds in three days, and some people might immediately get it and others might not. Anything that is key for the inner workings of your code that isn't explained, is said to just "magically" work.

There's no magic in development. Make sure everything is clear. Which leads us to:

Is the code easy to read? 🤓

Remember: you don't know who is going to be doing maintenance on the code base your team is working on. It may be you, or not. And even if it is you, it's going to be the future you. We can promise you right now that you will not remember why that wonderfully clever function you've just written down works.

Everything needs to be readable. As readable as you can possibly make it.

Does it have good test coverage? ✅

As much as the codebase as possible should be covered when running your tests. If the percentage isn't high enough, then you probably need to consider changing the battery of tests you're running.

Tests aren't technically a part of code reviews, but they definitely go hand in hand as two of the most effective practices to ensure code quality.

Is there no unused code? 💤

Pretty self-explanatory, right? If the code is unused, it shouldn't be there. No good can come of it. Only mistakes.

Did you enjoy our little checklist? Did we miss something? Is there a key step to your reviewing process that you feel should be on everyone's list?

Make sure to drop us a line on Twitter (@codereviewpad) and let us know.

How long should code reviews take?

Reviewpad — Mon, 16 Aug 2021 13:28:16 +0000

This is one of the most controversial aspects of code reviews. People just don't seem to agree about how long one should be taking doing code reviews, how long the ideal code review is, or even if you should time them at all.

The underlying thought is valid : code reviews depend on our ability to remain focused and detect minor flaws. It's not an activity that you can perform well for very long. Tiredness and distractedness will destroy your productivity.

So how do we optimise this? Should we measure time? Set targets, such as the number of lines of code reviewed? Trust our body and perceptions?

We have some thoughts ourselves, but we'll leave those for the end of the article. In the meantime, let's look at the best arguments.

Code reviews should take a fixed amount of time

This is one of the more common suggestions. The idea is that whether you're measuring how much code you actually go through or not (because this is heavily reliant on its quality), you should focus on time, so you know you aren't doing too much and reviewing whilst tired.

Common answers range from 60 minutes to 2 hours, and it is generally agreed that anything that exceeds two hours is too much and would necessitate taking breaks.

Not everyone emphasizes fixed amounts, however.

Code reviews should be limited by space, not time

This is the second most popular suggestion. The argument is that time isn't the best way to limit reviewing, the number of lines of code checked is.

The idea is that different reviewers with different skill sets are likely to take varying amounts of time to get the same work done.

This makes time-limited sessions an unreliable predictor of when the job will be done.

Proponents of best practices usually recommend around 300 or 400 lines of code at one go.

Cognitive loads vary, so you should do both

This is by far the most common answer out there.

To put it quite simply, different people in different teams have varying degrees of tolerance for cognitive load. Some can work for longer hours, some can deal with more work.

No one is superhuman, though, and we shouldn't expect that.

The ideal solution, if you are doing both, is to set limits in terms of both time and space and stop whenever you reach whichever is first.

Our suggestion: figure out what works for you

When recommendations for best practices are this divisive, odds are different strokes will work for different folks.

This is not a bad thing.

We do believe that best practices for code reviews will be better defined in the future (and we definitely hope to contribute to that conversation), but some aspects of it will always be up to the characteristics of the team.

Here's our recommendation, that we've included in our Best Practices article:

Time your own code reviews.

Figure out how long it usually takes you to get through your work, and be mindful of your own limitations. Once you've understood how long it usually takes you to get through the amount of work you're comfortable with, you will learn a number of important things, such as:

Which part of the codebase takes you the longest;
How long it typically takes you to handle specific issues;
When any given review is taking longer than usual, which can mean there are problems that need fixing elsewhere in the development process;
When you will need to compartmentalise and divide the work.

This is part of a larger point about code reviews best practices, which is all about acquiring metrics that make your work easier.

Something else that makes your work easier is having the correct tools for the job.

Which, incidentally, is what we make.

Take a look.

Code reviews in a nutshell

Reviewpad — Thu, 05 Aug 2021 15:41:15 +0000

When you’re working on a specific field, it is extremely important to never lose focus. What are the basics of your work? Why does it matter? Why do you do what you do?

We have decided to step back a little and take a good hard look at code reviews as a concept, and think through the basics of the work, why it matters, and how it’s become a cornerstone of software development.

What are code reviews?

Some concepts are so ingrained in our day-to-day activities that we have a hard time defining them precisely. A code review is one of them. A lot of confusion arises from this. One of the most common misconceptions about code reviews is that they are the same as pull requests.

This is false.

Not only are code reviews not pull requests, they can happen independently of them, and outside of version control systems, such as Git. These are all tools that make code reviews more effective and easier to perform, but they don’t define the practice.

Code reviews, or peer reviews, are any and all software quality assurance activities where a person (or persons) that is not the original creator of the code will verify it by reading it.

That’s it.

It’s that simple.

Why do we need code reviews?

There are a ton of automated processes for reviewing code, correct? And there’s a lot to be said about metrics that can guide a review, which can also be systematised even by someone without a deep knowledge of the code, correct?

So why do we need some of our brighter development minds to be spending a significant amount of time poring over code that has already been tested and passed?

For several reasons.

We need code to be readable. When we are performing code reviews, we aren’t just debugging, we are doing an exercise in creative reading. We are checking to see if we can perfectly understand everything the code does. Every codebase needs to be updated, and it’s just not practical to always rely on the original developer to do so. The code needs to be readable by someone else.

We need to transfer knowledge. A team that is composed of individuals that only understand the code they wrote is a team that doesn’t understand its own product. Code reviews aren’t just about improving the codebase, they are also about improving on what the team knows.

We need continuous improvement, not just fixing problems. A code review shouldn’t just focus on picking bugs or defects. The reviewer is a second set of eyes and a second mind, and they always need to be thinking critically. Are there better solutions? Can we improve quality? Can this be done more efficiently?

We need it for team building. Collective ownership is key. The team needs to know that every single line of code is owned collectively by everyone, not just by the person who typed. Code reviews make the team understand that everyone can contribute with valuable input at any stage of development in a practical sense.

So how do I do them?

We have a lot of thoughts about best practices regarding code reviews.

We understand not all of them are consensual, though, so here’s the bare minimum you need to do to implement an effective code review process with your team:

Establish what to look for. Not all code reviews are born equal, and not all of them are looking for the same things. If you are making very minor changes to a function, for instance, you might not even need a review, even if it affects a significant number of files. Here are some things to look out for:
- Purpose: Does the code do what it’s supposed to?
- Requirements: Does the code do everything it should?
- Design: Is the code readable and elegant?
- Functionality: Does the code serve its users adequately?
- Complexity: Could the code be simpler?
Figure out how you are going to assign the reviews. Don’t just blast the whole team with a notification and have them randomly review things in their free time. Whether you’re assigning a senior and a junior developer or partnering developers in other ways, make sure reviews are assigned in a timely fashion to specific people.
Make sure reviews are done in a humane way. One of the major roadblocks teams face regarding code reviews is that people sometimes tend to not handle the emotional aspect of going over someone else’s work in the kindest way. Reviews need to be about collaboration, not competition. We were lucky enough to have a guest post on our blog about precisely this.

If you are just getting started

We have made it our mission to improve code reviews, to make them more accessible and simpler for teams, and to truly make them an industry standard.

Reviewpad was designed to do exactly that, and you can try it for free.

You can do it right now, in fact.

Let us know what you think.

The book most of us don't need.

Reviewpad — Wed, 02 Jun 2021 14:46:16 +0000

Let's face it, most developers don't need this book for Code Review, we are all experts on #LGTM

( With https://dev.to/rly )

Why You Need To Be Doing Code Reviews

Reviewpad — Wed, 02 Jun 2021 14:42:51 +0000

Code review is one of the most underrated processes to increase code quality. There is still resistance to a process that is seen as unproven and associated with useless overhead. However, by understanding how code reviews can work, it becomes clear that the advantages far outweigh its costs. I am here to directly address the most common concerns and to share a vision for the future of code reviews.

Spoiler alert: it’s not a fancy AI tool that replaces developers.

Now, any developer worth their salt is going to be checking and documenting the code over time. This is a given. There are many stages throughout development where bugs and mistakes are found.

This is why you have specifications and run tests.

So how do you arrive at the return on investment (ROI) of a code review?

Return on investment is hard to measure

Full transparency: it’s not easy to define adequate metrics to find out a code review’s ROI.

We do know some things. For instance: fixing a bug in the testing stage costs you on average almost eight times as much as if you catch it before. And if it’s ever found after the product has shipped? Well, that’s about 15 times as much.

The benefits of code reviews permeate the entire development process. It improves communication, the sustainability of products, the onboarding of new joiners, and a number of other issues.

Of course, if you want to kid yourself, you can try to put a number on it.

At the end of the day, though, we need to be comfortable with the idea that a formula will never capture how important code reviews are as well as the people in your team. It’s all about continuous improvement – and that’s an integral part of a team’s culture.

Understanding code reviews is simple

Sometimes, the major roadblock for teams to engage in code reviews is that they don’t fully understand what it means. As a developer, that resonates a lot – code reviews are time consuming, are typically unstructured and it’s quite easy to get lost in the process because of their cognitive complexity and frequent context switching.

So, how can we get more structure into it?

Properly done, here’s what an experienced reviewer will be looking for:

Design: the code must fit the purpose for which it was created.
Functionality: the code must behave in the intended way.
Complexity: simpler is usually better. Both for functionality and for maintainability.
Tests: there must be tests in place with sufficient coverage of the changes.
Naming: variables, classes, methods names need to be clear and self-explanatory.
Style: the code must respect the engineering guidelines of the company.
Documentation: it must be updated, and it must be relevant.

This strategy is in many ways a methodical and rigorous process to improve code quality. However, in practice, valuable code reviews are not box ticking – the main goal is to collaborate and improve the codebase which is the common working environment for developers.

Code review brings in different sets of eyes to look at your code. Think of it as a manuscript, and of the reviewer as a proofreader. It’s a brand new set of eyes, someone likely unfamiliar with the text, and someone that needs to understand it on its own merits.

The author shouldn’t need to be at the reader’s shoulder, explaining what is happening in the story. In the same way, a code reviewer constructively should point out when your “narrative” doesn’t make sense. This way, reviewers and the author collaborate on the best solution.

This is a job for humans and adding automation helps but in the code reviews that matter, you ultimately need human interaction to reach the best outcome for the team.

Code review will help your team do its job

By talking with hundreds of developers, we have learnt that teams with a strong culture on code reviews are able to communicate effectively. Not just sporadically, consistently. This is because code reviews don’t simply fix bugs, they also ensure that the codebase is clean and easily understandable for others to maintain.

As developers get used to comprehensive code reviews, they will start changing how they code accordingly. This means code becomes easier to understand by others and a lot of time is saved going back and forth within your team.

(especially if your team is remote)

Most of us are working remotely at the moment, due to… ahem… current events. What we are starting to come to grips with is that some kind of remote work environment is not going away. Ecommerce in particular has been the canary in the coal mine regarding this issue. Consumers and companies alike have realised that there are a lot of advantages in working and buying from a distance, and in-office work will probably never revert to its pre-pandemic levels.

That means effective communication is now at a premium.

High quality code reviews help teams build codebases that facilitate communication, and that lets people get straight to work with very little synchronous guidance.

Are code reviews a silver bullet?

Simple answer: no.

What if the original code is a huge incomprehensible mess? Won’t reviewers spend hours on end trying to figure out how to even begin to understand the changes? Probably.

The complexity of the review itself increases exponentially with the number of changes, the maturity of the codebase and the lack of expertise of the reviewer. However, somehow this complexity feels artificial at times and we believe that has to do with the interface most reviewers are using right now. It is just a textual diff between files.

We started Reviewpad because we believe that it should be possible for developers to have the relevant information about code changes out of the box. Ultimately, we want to systematically help developers create an intuitive guide for reviewers to dramatically reduce the number of useless interactions required today.

There’s also the issue of communication and documentation which I will write about in the future.

We are working to make code reviews better

Reviewpad’s long-term goal is to make high quality code reviews easily accessible for teams of any size and working with codebases that might be recent or decades old.

And we want to do it by protecting our most important resource: developers. For that reason, Reviewpad is being built with a developers first mindset – it should make code reviews better by making it easier for developers to extricate themselves from bad code.

We are currently on private beta but if you want to hear more about Reviewpad, book a demo and we will show you how we are building the future of code reviews.

The "C" in Software Quality stands for for "Code Review"

Reviewpad — Wed, 02 Jun 2021 13:27:46 +0000