JS Nation

JSNation 2023

<p>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.</p>

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 move more personal. But it's okay because the boss tells them that he disrupts the world. 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 he learned to do the LGTM. Looks good to me. But the problem he 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 sold as a virtual machine together with Oracle database. We do a vertical scale, mean we just install the same image 50 times. And we release the software every six months. Then we moved to some microservices in 2018. We did a gateway to load the balance, a software piece instead of hardware load balancer. Go further, 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. The way that people do code review, the techniques that they tell you you should do code review stay the same. And that was look weird to me. And like every time things look 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 Leah 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 a 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 DevRel 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. It was 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 developers. I'm seeing how developers 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. Right? 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 things 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 Linux. I may be coding also for WebAssembly, 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 we 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 the consideration in code review. Right? But there is also stuff that not changed. For example, the need in the human wisdom. We still need the unique thinking of the human brain on how we deliver application. That's correct that computers are running our applications, but other people will need to read it. Other people will need to manage it. Other people will need to get business decisions. And this human wisdom, this connection between people is not changed. This is a core principle we will want to keep in the future stack of code review. And also, another thing that never changed is that code review are the velocity enemies. If we want to look, if we take a look at any Kanban board or whatever the way you manage your work, you will always see that the most obstacle that stuck our software from the lever is the way we are reviewing. We have a manual task that stand in the middle of all the automated tasks and break our velocity. 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 stack of code review as something that we implementing in our software, our 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, although 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 that 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 Linting, 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 YesLint to keep everything clean in my code. But when the code itself is overlap with our application architecture and the platform when we are running it, this is where we need a human eye. A human eye that 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 in 20% of the effort. I want the human to invest their time in writing code. Review is important. But only on the 20% that's 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 only after 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 takes 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 is 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 rule 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 in the work or some repetitive comments coming again and again in code reviews, we should write an automate 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 check for issues in my code. So here, for example, I created a 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 to not put the local host here. So after one time that I 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 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 it 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 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 will 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 team, we're 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 word 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 things 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 man when we do a code review. Let's be a better people. And also we want to treat the code review as a product feature. I 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 a very important metrics. If we can see a pattern on code review that's 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 tasks. We could use the insights 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 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 itself and see if this 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. Sometimes, yes. Sometimes 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 to yourself. Find what is your stack for code review. Build your best practices. Make a better product and happier developer. Thank you very much.
