"Have you ever spent hours reviewing someone else's code only to feel like you're making no progress?"

When I first started out as a developer, code reviews were one of the most intimidating aspects of the job.

I never knew what to expect and often felt like my work was being torn apart. But over time, I've learned to appreciate the value of feedback and how it can help me improve my coding skills.

If you've worked in software development, you've probably dealt with code reviews.

Code reviews are feedback, but they are a time-consuming process.

The goal of software development is continuous improvement, and receiving feedback is essential to achieving that goal.

Code reviews, though, may be a tremendous hassle. What if there is a way to speed up and shorten the procedure? There is where Reviewpad comes into play.

Why do Code Reviews Matter?

They're a fantastic coaching opportunity. Insightful feedback speeds up learning and development.

Quality code improves readability and is a force multiplier for the long-term velocity of the team.

A common mistake I've seen in my career is for developers new to a "tech lead" role to try to perform every code review. They're afraid that if they don't, something will break, but reviewing every pull request isn't feasible or scalable.

Most software developers are probably tired of manually assigning reviewers to GitHub pull requests.

Are you ready to turbocharge your productivity?

Let's take a look at Reviewpad, a strong and adaptable tool that will make your job simpler and faster.

In this tutorial, we'll explore the features and benefits of Reviewpad and look at some of the best practices and tips to help you make the most of it.

So come along and unlock the potential of Reviewpad and take your productivity to the next level.

Every pull request is unique. However, the code review procedure remains the same. This slows development and creates a false sense of security.

TL;DR

• What is Reviewpad
• What Challenges did I Face as a Code Reviewer?
• Why Reviewpad
• Getting Started with Reviewpad
• OpenAI + Reviewpad
• Why Using Reviewpad is the Best Option

What is Reviewpad

Reviewpad is a SaaS platform that allows developers to specify and automate multiple code review processes.

The platform seamlessly integrates with GitHub, making it simple for teams to improve their code reviews and pull request workflows.

Reviewpad's cost-effective and efficient solution is especially beneficial for remote teams or teams working in distributed locations.

Your Git repository will have a single configuration file that contains all of your Pull Request policies and workflows. If you have a multi-repo architecture, your team can share a main configuration file across all repos.

A Simple Example:

labels:
  ship:
    description: Ship mode
    color: 76dbbe

workflows:
  - name: ship
    description: Ship process - bypass the review and merge with rebase
    if:
      - $hasFileExtensions([".md"])
    then:
      - $addLabel("ship")
      - $summarize()
      - $merge()

What Challenges did I Face as a Code Reviewer?

I spend a lot of time reviewing code in software engineering, and some of the frequent issues I came across are:

• Reinventing the wheel when something similar already exists in open source or within the codebase.
• Trying hard to fit a design pattern into a code where it's not needed (just because you read it a few days back on the internet)
• Variable names that are extremely long and have typos
• There aren't enough tests in the new code
• The absence of clear rules and the use of linting tools
• Low-level coding style (too long lines, unusual variable names, incorrect spacing, compile-time errors) should almost never be discussed during code review.

And the worst that can happen is when the developer stops thinking about "how to write better code" and starts thinking about "how to write the code that passes the code review".

Isn't there a plethora of automated processes for reviewing code?

When members of a software engineering team need to review code, they frequently have to hop between tools or platforms, which can be inefficient and confusing.

• Reviewpad serves as a service platform that allows all team members to collaborate.
• Reviewpad provides a centralized configuration for all pull request automation.

Advantages of Using Reviewpad in SDLC

• Automated workflows
• Unified review experience
• Customisable review templates
• Multiple review types
• Integration with other tools
• Enhanced security
• Issue tracking and resolution
• Cost-effective solution

Why Reviewpad

Reviewpad takes a structured, standardized approach to code reviews, outlining what needs to be reviewed and providing a consistent framework for providing feedback.

All pull requests aren't the same. Why use the same procedure for all?

Reviewpad can help reduce the risk of errors by providing automated checks and alerts, ensuring that nothing is missed during the review process.

They've developed automatic policies for handling pull requests:

• Labelling
• Review assignment
• Custom code quality and security comments
• Merge automation

Getting Started with Reviewpad

It's simple to get started with Reviewpad.

Install Reviewpad on your team’s repository and configure your reviewpad.yml (or tweak the one proposed in the onboarding PR).

• Reviewpad offers a consistent review process with automated activities and clear feedback.
• You can tailor your review settings to meet the needs of your team and use Reviewpad's centralized platform for collaboration and communication.
• Reviewpad allows you to quickly streamline your code review process and improve the quality of your code.

Navigate to the Reviewpad GitHub App page and click the Install button.

You can install Reviewpad in all repositories or just a few. I selected all repositories.

After that, it's time to configure your GitHub workflow.

The Reviewpad configuration is a YAML file that defines the workflows used to automate the pull request process.

After you install Reviewpad it will create an onboarding PR on the selected repositories proposing a reviewpad.yml where you can tweak the settings and see a live preview of the actions it will do on your open PRs."

Add reviewpad.yml to the root of repository

Reviewpad will look for a reviewpad.yml file in your repository's root and execute the workflows set in it.

In the root of your repository, create a file named reviewpad.yml and add the following content

# This file is used to configure Reviewpad.
# The configuration is a proposal to help you get started.
# You can use it as a starting point and customize it to your needs.
# For more details see https://docs.reviewpad.com/guides/syntax.

# Define the list of labels to be used by Reviewpad.
# For more details see https://docs.reviewpad.com/guides/syntax#label.
labels:
  small:
    description: Pull request is small
    color: "#76dbbe"
  medium:
    description: Pull request is medium
    color: "#2986cc"
  large:
    description: Pull request is large
    color: "#c90076"

# Define the list of workflows to be run by Reviewpad.
# A workflow is a list of actions that will be executed based on the defined rules.
# For more details see https://docs.reviewpad.com/guides/syntax#workflow.
workflows:
  # This workflow calls Reviewpad AI agent to summarize the pull request.
  - name: summarize
    description: Summarize the pull request
    always-run: true
    if:
      # Summarize the pull requests when pull requests are opened or synchronized.
      - rule: ($eventType() == "synchronize" || $eventType() == "opened") && $state() == "open"
        extra-actions:
          - $summarize()

  # This workflow assigns the most relevant reviewer to pull requests.
  # This helps guarantee that pull requests are reviewed by at least one person.
  - name: reviewer-assignment
    description: Assign the most relevant reviewer to pull requests
    always-run: true
    if:
      # Automatically assign reviewer when the pull request is ready for review.
      - rule: $isDraft() == false
        extra-actions:
          - $assignCodeAuthorReviewers()

  # This workflow praises contributors on their pull request contributions.
  # This helps contributors feel appreciated.
  - name: praise-contributors-on-milestones
    description: Praise contributors based on their contributions
    always-run: true
    if:
      # Praise contributors on their first pull request.
      - rule: $pullRequestCountBy($author()) == 1
        extra-actions:
          - $commentOnce($sprintf("Thank you @%s for this first contribution!", [$author()]))

  # This workflow validates that pull requests follow the conventional commits specification.
  # This helps developers automatically generate changelogs.
  # For more details, see https://www.conventionalcommits.org/en/v1.0.0/.
  - name: check-conventional-commits
    description: Validate that pull requests follow the conventional commits
    always-run: true
    if:
      - rule: $isDraft() == false
    then:
      # Check commits messages against the conventional commits specification
      - $commitLint()
      # Check pull request title against the conventional commits specification.
      - $titleLint()

  # This workflow validates best practices for pull request management.
  # This helps developers follow best practices.
  - name: best-practices
    description: Validate best practices for pull request management
    always-run: true
    if:
      # Warn pull requests that do not have an associated GitHub issue.
      - rule: $hasLinkedIssues() == false
        extra-actions:
          - $warn("Please link an issue to the pull request")
      # Warn pull requests if their description is empty.
      - rule: $description() == ""
        extra-actions:
          - $warn("Please provide a description for the pull request")
      # Warn pull request do not have a clean linear history.
      - rule: $hasLinearHistory() == false
        extra-actions:
          - $warn("Please rebase your pull request on the latest changes")

  # This workflow labels pull requests based on the total number of lines changed.
  # This helps pick pull requests based on their size and to incentivize small pull requests.
  - name: size-labeling
    description: Label pull request based on the number of lines changed
    always-run: true
    if:
      - rule: $size() < 100
        extra-actions:
          - $removeLabels(["medium", "large"])
          - $addLabel("small")
      - rule: $size() >= 100 && $size() < 300
        extra-actions:
          - $removeLabels(["small", "large"])
          - $addLabel("medium")
      - rule: $size() >= 300
        extra-actions:
          - $removeLabels(["small", "medium"])
          - $addLabel("large")

  # This workflow signals pull requests waiting for reviews.
  # This helps guarantee that pull requests are reviewed and approved by at least one person.
  - name: check-approvals
    description: Check that pull requests have the required number of approvals
    always-run: true
    if:
      # Label pull requests with `waiting-for-review` if there are no approvals;
      - rule: $isDraft() == false && $approvalsCount() < 1
        extra-actions:
          - $addLabel("waiting-for-review")

  # This workflow labels pull requests based on the pull request change type.
  # This helps pick pull requests based on their change type.
  - name: change-type-labelling
    description: Label pull requests based on the type of changes
    always-run: true
    if:
      # Label pull requests with `docs` if they only modify Markdown or txt files.
      - rule: $hasFileExtensions([".md", ".txt"])
        extra-actions:
          - $addLabel("docs")
      # Label pull requests with `infra` if they modify Terraform files.
      - rule: $hasFileExtensions([".tf"])
        extra-actions:
          - $addLabel("infra")
      # Label pull requests with `dependencies` if they only modify `package.json` and `package.lock` files.
      - rule: $hasFileExtensions(["package.json", "package-lock.json"])
        extra-actions:
          - $addLabel("dependencies")

  # This workflow validates that pull requests do not contain changes to the license.
  # This helps avoid unwanted license modifications.
  - name: license-validation
    description: Validate that licenses are not modified
    always-run: true
    if:
      # Fail Reviewpad check on pull requests that modify any LICENSE;
      - rule: $hasFilePattern("**/LICENSE*")
        extra-actions:
          - $fail("License files cannot be modified")

OpenAI + Reviewpad

It's an exciting time when AI is disrupting technology, and we see a lot of excellent applications.

The Reviewpad team is launching an out-of-the-box solution that will disrupt how software developers collaborate on PRs daily.

Reviewpad has made GitHub's new slash commands even cooler!

They are introducing the summarize command, in your PR, type '/reviewpad summarize' for a comment summarizing changes!

You may give it a shot right now.

Why Using Reviewpad is the Best Option

Reviewpad has many excellent use cases.

• Auto-merge
• Automated Labelling
• Blocking Merge
• Comment on pull requests
• Enforce Branch Conventions
• Reviewer Assignment
• Ship/Show/Ask

For example, my team member raised very small pull requests in which he/she just updated some packages in package.json

labels:
  ship:
    description: Ship mode
    color: 76dbbe

groups:
  - name: ignore-patterns
    spec: '["*.lock", "generated/**"]'

rules:
  - name: is-small-patch
    description: Patch has less than 90 changes and 6 files
    spec: $size($group("ignore-patterns")) < 90 && $fileCount() <= 5

workflows:
  - name: ship
    description: Ship process - bypass the review and merge with rebase
    if:
      - rule: is-small-patch
    then:
      - $addLabel("ship")
      - $merge("rebase")

Conclusion

Reviewpad is a powerful and versatile tool that can help streamline the code review process and improve the quality of code. It provides a centralized platform for collaboration and communication, customizable review templates, and real-time commenting and collaboration features.

Reviewpad's cost-effective and efficient solution is especially beneficial for remote teams or teams working in distributed locations.

If you're tired of manually assigning reviewers to GitHub pull requests and want to turbocharge your productivity, Reviewpad is definitely worth checking out.

I'd like to conclude this blog with this lovely quote.

“I approve when the PR is good, not perfect.” — Curtis Einsmann

I would recommend that you read this blog where he explains his approach to code review at Amazon.

That was the end of this blog. Today, I hope you learned something new.

If you did, please like/share it so that others can see it as well.

Thank you for being a regular reader; you're a big part of why I've been able to share my life/career experiences with you.

Follow Reviewpad on Twitter for the most recent updates, and if you have any questions or problems, you can join their discord server to discuss and get help.

Join my Newsletter or follow me on Twitter to get more writing and software engineering articles.