Forem: Fábio Freitas

How to accelerate your code reviews?

Fábio Freitas — Thu, 20 Jul 2023 16:00:00 +0000

The code review process can often be tedious and filled with bottlenecks, making it slow and time-consuming. However, there are tools like Promyze and Reviewpad that can greatly assist in improving the code review process and saving you and your team a significant amount of work. In this article provided by Promyze, you'll discover effective strategies on how to expedite your review process.

Code reviews through Pull/Merge Requests have become an essential process for the majority of tech companies.
A recent study in 2022 unveils that 84% of the surveyed companies use it.
Several years of practice allowed practitioners to take a step back on this methodology to identify pain points and how to overcome them.
Besides, code reviews should always be continuously evaluated internally to improve how it’s done.
In this post, we discuss how to add more flexibility to the Pull Request process and, thus, improve the delivery time.

The lead time for change is the amount of time it takes a commit to get into production, and is part of the 4-key metrics defined by the DevOps Research and Assessment (DORA).
Engineering teams seek to optimize this delay to deliver sooner value to their customers. But before bringing solutions, let’s first define the problem:

During code reviews, what can slow down the whole process, create bottlenecks, and grow the lead time for change?

Narrowing the context and purpose of code reviews

The most often quoted obstructions to code reviews are the lack of human resources and the workload of engineers that don’t allow enough time for code reviews. A common reaction consists in adding more human resources to address the issue. Not so fast!

First ask yourself:
Is each code review truly necessary? Can we affirm that all the discussions within reviews are relevant and should happen there?

Indeed, what we observe in practice is that code reviews often lack a clear context and purpose. If you’ve opened a merge/pull request, what do you expect from that? From our point of view, we propose two primary purposes for a Pull Request.

#1 Code approval

I need to ensure my code is okay before merging ⇒ I need your approval.

In this case, it may raise friction from both sides, as reviews come late in the process.
Authors can feel reviews as a constraint that slows down their delivery, and a frustration to get many comments, with which they won’t always agree.
Reviewers can also adopt defensive behavior. What if they think: “I wouldn’t have done [the code] this way.
Should I tell this? Should it be blocking for merging? My colleague waits for 2 days; how will my feedback be welcome?”
So you can see that frictions can emerge from code reviews, mainly because we have the pressure induced by the quest for a satisfying lead time for change.

#2 Get help to improve the code

I’d like to show you my code and get your feedback to improve it ⇒ I need your help.

Compared with item #1, we’re looking to improve our code and learn from a peer.
In this context, it’s worth considering whether this review is part of the delivery process.
We may be convinced this code could be merged first. That’s something commonly observed in trunk-based development.

The workflows and policies are different based on the context of the PR, so it makes sense to define it clearly.

Another problem we observe during code reviews is the long discussion threads about implementation choices, design, and best coding practices.
And there, discussions get emotional and passionate: this is precisely what we want to avoid during reviews.

Do we still need code reviews?

Aside from this discussion, you may ask whether doing code reviews still make sense in 2023, in an era where we can find plenty of “DevOps automation” tools on the market.

We consider that, yes, indeed, code reviews are still necessary.
Even though automatic tools have become increasingly powerful, they’re good at detecting known problems.
They can’t prove the absence of problems. Think about this Dijkstra quote:

“Program testing can be used to show the presence of bugs, but never to show their absence!”

So during a Pull Request, we seek for what tools can’t detect.

Now let’s go back to our main point: how to address the aforementioned issues?

Do code reviews only when it makes sense

The concept of Fluid Pull Request

To answer the question: “Do all Pull Requests require a code review?”, we can explore the model Ship Show Ask. In this approach*,* PR authors are considered free of trust to evaluate themselves if:

The code doesn’t require a code review since the changes are trivial (Ship)
They’d like to show the code changes to colleagues and get their feedback (Show); This mode can sound totally counternatural as the feedback can be provided after the merge. This is part of the paradigm shift.
The code requires a review (Ask)

So instead of adding more human resources to review the code, we reconsider the necessity for each PR to be approved;
This is how we can positively impact the lead time for change. This concept is also called Fluid Pull Request.

Next generation pull requests with Reviewpad

Reviewpad is a GitHub app designed to automate your code review process and which implements the Fluid Pull Request concept.
A single configuration file in your Git repository will contain all your workflows and policies for your Pull Requests.
Based on the context, you’ll define rules to enforce or relax your security net. With Reviewpad, you can define rules such as:

If a file in this folder is edited, one person from this group should approve the code.
If the PR includes a new method in the code with an annotation @Critical, add a label ‘security, and require a double-validation. Rules can decide whether PRs can be automatically merged or refused, define a validation workflow, and more. Rules can address syntactic patterns in the code changes.

Here is an example of workflow to automatically raise awareness when a critical change is introduced:

labels:
  critical:
    description: Modifications to critical changes
    color: "#294b75"

groups:
  - name: owners
    spec: '["lina", "caris"]'

workflows:
  - name: changes to critical code
    run:
      - if: $hasAnnotation("critical") || $hasFileName("runner.go")
        then:
          - $addLabel("critical")
          - $assignReviewer($group("owners"), 1)
          - '$info("@samir: you are being notified because critical code was modified")'

Discuss best practices and design outside code reviews

Knowledge sharing should be collective

f you request a review to improve your code or show it, this shouldn’t be done under pressure before merging the code.
Engineers should instead find dedicated time to discuss code design and best practices, avoiding friction.
If you’re having a 1:1 conversation and debating about a best practice, you hold a discussion that may impact your whole team.
Indeed, if you come up with a decision, shouldn’t everyone agree with that? We can assume that you seek code uniformity and practice alignment.

So maybe it’s time to consider running dedicated workshops on your best coding practices, as 1:1 conversations should not be the right place for that purpose.

Best practices sharing with Promyze

Promyze is a knowledge-sharing platform for developers and provides integrations with IDE and code reviews (GitHub, GitLab, Azure DevOps, Bitbucket, and Helix Swarm).
With the code review plugins, you can create a best coding practice from a comment, and the code is sent to Promyze along with your best practice proposal.
You thus avoid long 1:1 discussions during code reviews.

Then, Promyze helps your team regularly run dedicated workshops to review contributions from developers (made during code reviews or within IDE).
It’s a suitable time to share knowledge and make technical decisions together and ensure everyone is aligned with the appropriate gestures to apply in the code.
This is a continuous improvement process for your best coding practices and to grow developers’ skills.

Want to accelerate your code reviews?

If you feel your engineering team has bottlenecks in their code reviews, we hope you found in this post some insights to improve your process:

Consider the necessity to approve each code change;
Consider dedicated sessions to avoid never-ending discussions during reviews.

We also showed that Reviewpad and Promyze can be complementary to accelerate the code reviews while fostering knowledge sharing.

Tell us if you’ve improved your lead time for change in your context and how you made it; we’d be happy to learn!

The Evolution of Code Reviews: The Beginnings

Fábio Freitas — Wed, 12 Jul 2023 17:00:00 +0000

Code review is now a vital part of software development in the age of DevOps. Understand the evolution of code review from its early days to its present shape. We'll look at how code review has adjusted to the demands of development teams, from time-consuming manual reviews to efficient automated ones.

With the rise of DevOps, the code review process has become a substantial part of software development. The right code review process ensures that our applications are highly available and can be built with high velocity.

Over the years, code review has evolved from manual processes to automated tools, adapting to the changing needs of development teams. As application development continues to evolve, it's essential for code review to keep pace and provide teams with the best possible workflow for ensuring code quality.

In this 2 part series, we will explore the evolution of code review from its early days to its current state. We'll look at how code review has adapted to the needs of development teams, the trends driving its evolution, and the future of code review.

In this first part, we will go through the pages of history to understand how the code review process came into existence, and how some of the shortcomings led to major disruptions.

Whether you're a team leader trying to set the right practices for your development team, just a seasoned developer or simply starting in the software development world, this series will provide valuable insights into the importance of code review. Join us on a journey through the evolution of code review, and discover how it continues to shape the future of application development.

The Dark Ages

In the early days of software development, code review was a manual process. Developers would physically sit down together and review the code line by line, discussing any issues or suggestions. While this method was effective, it was also time-consuming and not scalable for large development teams.

The introduction of Git in 2005 revolutionized how software development teams worked. It scaled the way teams, and contributors could now collaborate as developers could submit their code changes as pull requests. These pull requests would then be discussed and reviewed by other team members and, once accepted, were automatically merged into the main codebase. This was the rise of version control and all its benefits, such as keeping a history of changes and being able to roll back to previous versions.

However, this method relied on manual reviews, and the feedback process was often slow and inconsistent. With Git, teams had the flexibility to conduct code reviews in any way they saw fit, which led to inconsistencies in how code was reviewed. Different teams used different processes and tools, and the process of manually checking the pull request still made it difficult to standardize the entire code review process.

Overall the code review process was very manual and slow. Cutting corners to get functionality out to production often meant disruptions and bugs.

When Disaster Hit

This is exactly what happened to the London Stock Exchange on February 8th, 2008. It's usually not the best time for a financial institution facilitating trade in Europe's financial hub to be down in the middle of a global recession. This disruption was caused due to a bug in the new trading system that was released then.

The impact was that trading came to a halt for almost an entire day, and till today the financial amount lost due to the impact is not publicly available. It is safe to say, though, there are significant losses for the Exchange and its customers. Given the scale of the incident and the impact, it had on the financial markets.

Another such example is that of Knight Capital Group's trading systems which experienced an incident that led to a significant financial loss of $440 million in just 45 minutes. The issue was due to a code change that was not properly reviewed and tested, underscoring the significance of a comprehensive and efficient code review process.

Conclusion

The code review process has become an integral part of software development with the rise of DevOps. Over the years, code review has evolved from manual processes to incorporating automation. This was due to the need to push changes faster while maintaining the stability of your systems.

However, meeting this requirement was something that was just not feasible with the way code reviews were being performed. Stress the system too much and you could have experienced great outages and disruptions such as that of the London Stock Exchange or…

By tracking the evolution of code reviews and being aware of the past issues, we know it is important for us to refine our coe review process. How we can do so is answered in part 2 of this series where we continue our evolution into the future!

The Evolution of Code Reviews: A Better Tomorrow

Fábio Freitas — Wed, 12 Jul 2023 17:00:00 +0000

In this second part of the evolution of code review, we explore the impact of emerging trends in application development. Discover the significance of the shift-left approach, the challenges posed by microservice architectures, and the rise of DevOps-related concepts like GitOps. Embrace change management and explore tools like ReviewPad that automate and streamline the code review process, ensuring swift and confident deployments for your applications.

This is the 2nd part of a 2-part series on the evolution of code reviews. If you haven’t already, check out Part 1 here. In the first part of this series we saw how code reviews were performed in the early days of application development, and how the process if stressed could result in major issues and disruptions. The story of the London Stock Exchange and … is just a couple of examples from a long list of stories where companies suffered because of their outdated or faulty code review process.\
In this second part, we will go over some of the trends that have come up in the world of application development. By understanding these trends we will be able to understand the needs for the future of the code review process. So lets continue on our journey.

Emerging Trends and Their Impact on Code Reviews

Over the past decade, with the DevOps revolution kicking off, we have seen many emerging trends that have redefined how applications are developed and how code goes through development to review to production. Many of these trends, coming, have had an impact on the overall code review process, and it's necessary to understand these trends to understand what lies next.

The Whole Org Shifts-left

Shift-left advocates for quality control measures of code to occur sooner in the development process, near the time code is being written. This approach enables teams to quickly spot and address any issues, reducing the possibility of defects and enhancing the general standard of the software.
As a result, code reviews became essential to software release as the QA testing phase merged into the code review phase. No longer was it enough just to ensure that the code was compliant and met set standards but also that it worked and did not result in any regression.

The Rise of Microservice Architectures

Microservices architecture became popular due to its ability to allow for more flexible, scalable, and agile software development compared to monolithic architecture.

However, with the microservice paradigm, it does become difficult to track how different services are related to one another, especially as your application scales. As a result, a change in one service could affect and even disrupt another.

So it became necessary that these dependencies are realized during the code review process. Some of the related services to the service experiencing the change may be extremely sensitive to disruptions and downtime as per the business goals set. Putting more significance on an effective and clean code review process.

DevOps, GitOps, NoOps…Why?

With the rise of the DevOps concept, concepts under its umbrella also emerged. These included concepts such as GitOps, AIOps, and even NoOps. Whatever type of “Ops” you may adopt, the goal is the same. Increase the velocity of product development while maintaining the availability and stability of the application.

Overall, what is expected is the use of automation wherever possible, combined with the shift-left mentality, to aid in the two goals mentioned. We have seen now how the significance of code reviews increased due to other emerging trends. With the “Ops” trend, we tried to lessen the pressure on the code review stage using automation to ensure that changes could roll out quickly but also safely with high confidence that it's not going to break anything.

The Future of Code Review

Considering the various trends in the application development space, one thing that becomes clear is that pushing changes with a high degree of confidence is key. This is where the concept of change management arises.

Change management is identifying, planning, and implementing changes in an organized and systematic way. It helps organizations deal effectively with change, minimize disruption, and maximize the benefits of change initiatives. Change management includes various activities, such as identifying the need for change, assessing the impact of change, communicating change to stakeholders, implementing change, and monitoring the results.

By realizing the need for change management, it becomes clear why new paradigms, such as Fluid Pull Requests, are gaining momentum when it comes to adoption.

Fluid Pull Requests are an advanced form of the Pull Request method utilized in software development. In the traditional Pull Request system, a developer submits code modifications for review and evaluation by the repository managers. Fluid Pull Requests attempt to resolve these challenges by modifying the code review process based on the risk of the change.

Risk could depend on multiple factors such as how the service being affected is related to other services. The type of change of whether it is a config change or a change in the front, and the number of incidents reported by the team performing the change.

Depending on the outcome of this assessment, various code review procedures can be established and automated to either lessen or increase the rigor of the code review process. For instance, if an important security patch is added, it might be necessary to include the security team in the code review process.

This is exactly the methodology that a team performing change management needs. Any tooling employed could instill confidence in accepting the change, and even automatically merge the pull requests when the risk score is lower below a certain threshold. Increasing both velocity and stability of the application development life cycle.

This is why we are seeing increased adoption of tools such as ReviewPad that automate the review process and instill confidence in code changes. Reducing the need for manual intervention and overall reducing the time it takes for customers to see value in the applications you are developing.

Conclusion

The rise of various trends such as DevOps-related concepts, developing in the cloud, and new architecture paradigms such as microservices greatly increased the importance of code review, making it a possible bottleneck to the entire application lifecycle. As a result further is tools such as ReviewPad, which enable you to perform change management with the speed and confidence required.