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.
The Future Stack of Code Review
AI Generated Video Summary
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
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
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
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.
4. The Future Stack of Code Review
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
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
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.
7. Automating Code Review Comments
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
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.