The Future Stack of Code Review

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.

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.

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.

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.

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.

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.

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.

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.