The Future Stack of Code Review

Rate this content
Bookmark

Somehow, the code review had the same jokes and process while the software development world changed daily. Join us to learn how to adapt this process to the modern stacks and make the CR process an efficiency party.

22 min
05 Jun, 2023

Video Summary and Transcription

The Talk discusses the challenges of code reviews and the need to redefine the code review process in light of changes in software development. It emphasizes the importance of collaboration, security, performance, and clean code in the new stack of code review. The Talk also highlights the benefits of automating code review comments and optimizing the code review process. Overall, the Talk aims to build a better code review process that promotes collaboration and improves the quality of software development.

1. The Annoying Code Reviewer

Short description:

Today, I want to introduce you to the annoying person in every team who nobody wants to do a code review. They always have comments that disrupt the work and break your world. Dealing with 20 comments like 'Looks good to me' can be a problem.

So, hello, I'm Gabriel and today I want to introduce you to a person that we all know because they exist in any team, and this is the annoying person that no one wants to let them do a code review, right? The code review always looks better, they have comments like, This is not how I would do it, and then it moves more personal, but it's okay because the boss tells them that it disrupts the work, and then it goes longer and longer, and it has like all those not mean nothing comments that just broke your world, right? This is how code reviews work, and then you learn to do the LGTM. Looks good to me, but the problem is always put it as an issue. So you have to deal with 20 comments like LGTM.

2. The Evolution of Code Reviews

Short description:

I experienced a similar problem with an annoying code reviewer in my team. After years of avoiding their reviews, I started reflecting on how the software stack has evolved. From a Java monolith server to microservices running on the cloud, the tools and techniques for code reviews have remained the same. I turned to Twitter for opinions and found insights on improvement, mentoring, and quality.

So I know your problem because I experienced such a person too in my team. And after six years living with that person that I do everything just to not let them review my code, I start to think. And I took a look into the way that the software stack changed over the years. I started to work back then in 2016 in the same place. We used to have like a Java monolith server that we solved as a virtual machine together with Oracle database. We do a vertical scale, mean we just installed the same image 50 times and we released the software every six months.

Then we moved to some microservices in 2018. We did a gateway to load the balance software piece instead of hardware load balancer. We go further in 2020. We got microservices in multiple languages. We completely running on the cloud. We do horizontal scale and so on so forth. Now we spending in microservices every week. We ship our software in minutes, but code reviews stay the same. For the last 20 years, the tools stay the same. The comments stay the same. They way that people do code review, the techniques that they tell you you should do code review stay the same.

And that all look weird to me. And every time things looks weird to me, I'm going to Twitter. I know it's not the right thing to do, go to Twitter and ask opinions for people. But that's me. And I asked that question and I really recommend you, there is a link below to see the tweet itself. I really recommend you to go to see what people answer, but let's also take a look here and see some words. So let's look here. For example, Karen said that is about improvement and that's right. We want to get improved as a developer. We want our product to be improved. And hence we do code review. Boris speaking about mentoring and we'll get to it later. We see Lia speak about quality and so on.

3. The Changing Landscape of Code Review

Short description:

So I collect everything and then I start to think what we can do to redefine. Redefine the code review, find the way to progress in the same way that we progress with the software stack also in the code review process. We have much more to protect now, as we manage deployment from the same code and have dependencies between services. Another change is that we are now polyglots, developing software in multiple languages. AI is also replacing us, so our job as developers is to understand the platform and the application we're developing for. The software development lifecycle is automated, making it easier to push new features to production.

So I collect everything and then I start to think what we can do to redefine. Redefine the code review, find the way to progress in the same way that we progress with the software stack also in the code review process.

My name is Gabriel and I am the director of Deverell in Permit.io. Permit.io is a startup that solved a critical problem in access control. We developed a system that allowed developers to implement authorization in their system in no time. With just single lines of code you can get a whole authorization system in your application.

And as part of my work, I'm always looking at developer, right? I'm seeing how developer work, I'm developing dev tools. And I ask myself, what changed? If we look at the software stack from the perspective of code review, what changed in those years? So the first thing is that we have much more to protect. If we look for example, on bug prevention back in 2015, back in 2010, we need to prevent bugs in the application code. We have one application and this application could be potential bugs in the logic of the code itself and we want to protect it. But nowadays we have much more to protect because we manage also deployment from the same code. We have also a performance issue only because we have dependencies between services. We manage a lot of thing via code and we have much more to protect when we inspect quality.

And another thing also changed. We are now polyglots. I am not a JavaScript developer anymore. I'm a full stack developer. That's correct. My mother language is JavaScript, but I'm coding for Node.js. I'm coding for D-Nodes. I may be code also for web assembly, for browsers, for native applications, for desktop applications. We are not anymore programming in a language. We are developing software. And the more and more we go and for another change, now AI is going to replace us, right? As a developer, our job nowadays is just understanding the platform, understanding the application, the domains that we are developing software to. I'm coding with Copilot. I'm not should be proficient in JavaScript anymore. I should be proficient in the software that I'm trying to deliver. This way I can get much better applications. And also, if you look at the software development lifecycle, everything is automated. Today, when I want to push a new feature to production, I don't do anything but open PR.

4. The Future Stack of Code Review

Short description:

After automating CI/CD and deploying my software, it's important to consider these changes in code review. However, human wisdom and collaboration remain essential. Code reviews can hinder velocity, so we need a new stack that addresses our software stack changes and focuses on collaboration, security, performance, and clean code.

After that I have GitOps flows, I have automated CI, CD. Everything happened somehow and my software is just deployed. We should take all these changes into consideration in code review, right?

But there is also stuff that does not change. For example, the need for human wisdom. We still need the unique thinking of the human brain on how we deliver applications. Computers may run our applications, but other people will need to read and manage them, and make business decisions. This human wisdom and connection between people is a core principle we want to keep in the future stack of code review.

Another thing that never changes is that code reviews are the enemies of velocity. They often become a manual task that stands in the middle of all the automated tasks and breaks our velocity. So we need to define a new stack of code review that takes into account the changes in our software stack and the need for collaboration, security, performance, and clean code. Let's build together a new stack of code review that aligns with our specific team's needs and goals.

5. Defining the New Stack of Code Review

Short description:

We need to define the new stack of code review based on the different environments, deployments, and languages used by each team. The key aspects of the new stack include increasing velocity, improving code readability, enhancing security and performance, maintaining clean code, encouraging collaboration, and ensuring scalability. Understanding the responsibilities of code review, including checking the code, testing the application, and considering the platform, is crucial in implementing effective code reviews.

So we now need to define what is the new stack of code review? Let's take a look at code reviews and build together a new stack. So I created a list here, but I think the most important aspect of this list is number eight, what you bring as the new stack of code review, because every team today think different, every team running on different environment, every team manage differently deployments, every team writing in a multiple languages to multiple platforms. So I just put my core team stack, but you can add your stack too. And that's the point of the talk. I want us to start at the new code, new stack of code review as something that we implementing in our software needs. Not just a general standard that we need to deliver software, but standard that stand with our software.

So let's take a look on what I list here. I want to increase velocity using code review. I don't want them to break me. I want them to make me better velocity. I want the code to be more readable because human read code, all the machine executed, human read it. I want to get better security. That's a critical aspect that can get true code review. And I also want to get performance. And I want to keep clean code, but the general meaning of clean code. So for example, I want to keep the solid principles on my code, and I want to encourage collaboration with my team. And I want to make sure that the code in the micro and the macro aspects of it is actually scalable.

Looking on this list, I crafted a list of the best practices we can get for code review. The first one is understanding the responsibilities of code review. We have three points when we are looking on every piece of software. First is the code. This is the micro part of our software. The code itself can be checked with LinkedIn. Can be checked with static analysis. Those all will verify that every function, every piece of code, small piece of code we are writing is actually stand on standard. We do also have the testing on our application. The wider aspect of our software. And then the platform, when we are running it. And then we can use tooling to prevent bugs. All those responsibilities together is the reason for code review.

6. Optimizing Code Review Process

Short description:

For code review, it's important to understand the responsibilities and focus on the 20% that really matters. Streamlining the review process and prioritizing PRs can improve timelines. Linting, static analysis, and unit testing can ensure code reliability. Automating code review comments with tools like ESLint can save time and foster a culture of code quality.

For each one of them alone, we can use automatic tools. I can use ESLint to keep everything clean in my code. But when the code itself is overlapped with our application architecture and the platform when we are running it, this is where we need a human eye. A human eye understanding the big picture and think about the important things.

So the first best practice when I'm doing code review, I want to know the responsibilities. And then as a tech lead, I will want to have only 20% of human responsibility on the code review. So think about it like a Pareto. The consequences of the bug that I will find will be mostly from the machine review, right? From the test, from all that. But the human will find important stuff but only 20% of the effort. I want the human to invest their time in writing code. Review is important, but only on the 20% that really important.

And I also want to get a better timelines of code review. I don't want to get people, start looking on code review at the minute they are released. And one of the reasons for that is the context switch. When I'm reviewing code, I'm not writing code. That's actually disconnect me from the task that I'm currently working on it. I want to make a streamline that people are entering into the review phase only after I'm making sure the PR is standing in all standards. So I want first to prioritize the PR. Maybe this is just a small CSS fix. And we'll soon talk about tools that can find you if it's just a small CSS fix, if not, maybe not need a code review. I want to do the right linting and then static analysis testing from the security perspective and also from the code perspective. And learn only after a unit test, I want to get human eyes on it because now I can make sure that the code is reliable to get to production. Then I will run to what make, take time like end-to-end test. But what I know now is that a person waste their time in a review only after it was make sure it's reliable.

And then there is a mindset that they want to encourage. The question is, can I automate it? For every comment that I put in a code review, this a question I ask myself. Can I automate it so next time the developer will find it before I am finding it? It's not hard to get it because we have very comfortable Lint tool for JavaScript, ESLint. We can write custom world to ESLint. This is actually a culture that we will want to put in the organization. We want people to understand that ESLint should work for them.

7. Automating Code Review Comments

Short description:

If you see repetitive comments in code reviews, write an automated rule to find them. I created an ESLint plugin that disallows using 'localhost' in the code. Automating code review comments saves time and encourages a mindset of automation. If a comment cannot be automated, reconsider its necessity. Our code is diverse, and readability is subjective. Follow principles but respect personal preferences. Instead of instructing, start conversations by asking 'why'.

If they see it stuck at the work or some repetitive comments coming again and again in code reviews, we should write an automated rule that will find it next time. And this is actually not that hard. Let's see how easy I can write a piece of code that checks for issues in my code.

So here, for example, I created ESLint plugin, custom plugin. And my problem here is this function. Let's take a zoom out for a second from the best practices and understand what's going on here. So new permit is actually our SDK. And here there are some configuration for the SDK. One of them is the decision point, a server that the software need to go to. And here we can see a local host. But best practices is the not put the local host here. So after one time that they saw that I'm commenting to someone, hey, we shouldn't deliver code with local host, I can automate it. I can create an ESLint plugin here that actually saying I'm disallowed to use local host. And that's pretty easy because what you need is kind of understanding the way that the code looks like. And you can read the instruction, we are not here to learn how to actually write ESLint rules. But you can see here that if the PDP value is local host, I'm returning an error and we can see it work here. So if you go, for example, to the terminal and I'm running now, the ESLint on my program, I can see that I'm getting an error. And of course, if your users work with the right IDE, they will get in just in time. And this is a mindset that we must encourage. If you have a comment that cannot be automated, think of it again. Maybe it's just your opinion. Maybe it's something that you're not should put inside. Our code is now diverse. Readability is about subjective feelings. We have principles to follow, but no one should track your personal preferences. Continue with the best practices. We want to be a match. We want to be good people when we do code reviews.

So first I want to do conversation over instructions. Instead of telling people you shouldn't do this way, maybe ask them why.

8. Building a Better Code Review Process

Short description:

We want to think as a team and encourage collaboration. Avoid nitpicking and keep the code review process simple. Treat code reviews as product features and analyze their impact. Use metrics to identify patterns and improve expertise. Manage code review priorities with tools like GitStream. Let's build our software and create a better product with happier developers.

Or, I think it should be done better, but I'll be happy to get an explanation why you did it. Because probably if you did it, you did something right. Maybe even in the end I'll not accept with it, but this is why we, as people, speaking each other. And we want to think in team over individual. Do not think on someone of the team that is like doing the work alone and we need to affect them in a way. We are a team, we are working together. We are all responsible for our software. And we want to encourage collaboration over competition. We are not compete each other, we are team members that should together do the best and just create a better software.

And we want to avoid the nitpicking. If I'm seeing a nitpicking ward in a code review, that means someone just trying to waste my time. I don't care about nitpicking, you could create a conversation about your nitpicking and then I can answer and maybe I'll agree with you at the end. And also let's keep it simple. One of the thing that I'm seeing in code reviews and you can even see it in a large open source project is that people trying to complex, people trying to make the message complex, people trying to make the code review complex. Let's be a mensch when we do a code review, let's be a better people.

And also we want to treat the code review as product feature, mean we want to put them into analysis. When we do retrospective for our sprint and look why a task took so long, let's see also how long the code review was stuck in a review phase. It's easy to get it from GitHub API and this is actually very important metrics. If we can see a pattern on code review that stuck again and again, maybe that say that we don't have enough expertise on the team, maybe that mean some people should do other task. We could use the insight and the metrics that we get from, let's say GitHub code review tools and get a better product for them. And last but not the least is manage priorities. There are tools today that could help you manage the priority of code review. So as I mentioned, for example, GitStream is looking on code review themselves and see if this is a code review is something that actually should be prioritized for stack other tasks or just could go to the automatic CI, CD and go to production. Sometime yes, sometime without human eyes, human eyes, as we said, is important, but we need to use them wisely. I'm pretty sure that you have also best practices for your code review. But let's remember, we are building our software. We are crafting the new stack of code review. See for yourself, find what is your stack for code review? Build your best practices, made a better product and happier developer.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️
React Summit 2023React Summit 2023
24 min
Video Editing in the Browser
Video editing is a booming market with influencers being all the rage with Reels, TikTok, Youtube. Did you know that browsers now have all the APIs to do video editing in the browser? In this talk I'm going to give you a primer on how video encoding works and how to make it work within the browser. Spoiler, it's not trivial!

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
JSNation 2023JSNation 2023
87 min
Build a Collaborative Notion-Like Product in 2H
WorkshopFree
You have been tasked with creating a collaborative text editing feature within your company’s product. Something along the lines of Notion or Google Docs.
CK 5 is a feature-rich framework and ecosystem of ready-to-use features targeting a wide range of use cases. It offers a cloud infrastructure to support the real-time collaboration system needs. During this workshop, you will learn how to set up and integrate CK 5. We will go over the very basics of embedding the editor on a page, through configuration, to enabling real-time collaboration features. Key learnings: How to embed, set up, and configure CK 5 to best fit a document editing system supporting real-time collaboration.
Table of contents:- Introduction to the CK 5 ecosystem.- Introduction to a “Notion-like” project template.- Embedding CK 5 on a page.- Basic CK 5 configuration.- Tuning up CK 5 for a specific use case.- Enabling real-time editing features.