OK. So uh hello and welcome to code review. Why you should care and how to make the most of it. Let me start by introducing myself. So my name is Tamara. I'm from Brazil and I'm a lead software engineer at ke design system.I'm also a woman empowerment promoter and also the lead of knowledge initiatives aiming to share knowledge. I'm also not resource advocate and either I'm working at CASS developing software or when I'm working on a side project uh on open source code review is a big part of my routine and that's the reason why I choose to talk about that today. So uh before jumping and talking about code review itself, let me start by sharing two stories with you. So the first one is about a rocket from NASA that was launched in 62. It was the Mariner one. Uh the idea for this rock to it, it was to go to Venus. But uh on the first five minutes uh since it was launched, it start stopped responding to the comments that it was supposed to follow. And the engineers, they decided that it was not safe and they have to uh ask for a self explosion of the rocket. This caused a loss for NASA of more than $300 million. The second story is also from NASA.

It is related to the Mars climate orbiter uh project. The idea here was to have a satellite that was going to orbiter Mars and to retrieve information on the atmosphere of that planet, it was launched in 99. But again, uh there was something that went wrong and the, the satellite didn't really follow the path that, that it should have followed and never really went in uh to the the orbiter of Mars. Instead, it got lost in outer space, literally lost in space. This again caused a loss for NASA of more than $100 million. Uh Why I'm talking about that, what those two things have in common. So both of those issues, both of those failures, they were caused by softer error in the first one from the rock from 90 from 62. It was almost like a typo, a dash character was left in the code where it should not be and it caused the, the the software. Uh it caused the rock to stop responding and kind of stayed in an idle uh state. The second one, the most recent one from the Mars uh satellite, it was in some kind of integration issue between two components uh that was supposed to get metrics and get information to help calculate the, the path to the arbiter of Mars, one of those those systems, one of those components, it was considering using um the, the metric system.

And the second one was using imperial system and they were talking with each other with their own measurement uh system. And those are kind of common neighbors. We might have faced those in our lives. And usually we find those, those are issues that we can commonly find during a code review. And why I'm talking about that because I, I want just to give you an idea of what is the cost of an error. And not only I, I'm showing that examples, but IBM has done a research of what would be the cost of an error catching different steps of the software development. And after releasing something, the product or the rockets in the, in the case of uh on that case, uh the cost of finding an A after the release is up to 30 times the cost if that was found during the specification. So we are trying our most when we are working on developing a software, developing a product to catch the A horse as early as possible. In code review, it gets into that spot where the cost of the horse itself is still smaller compared to other steps in the flow. OK? I went a little ahead. Let's go back and let's talk about what is code review.

So code reviews the activity when one or more people uh will go over the code that someone else has written given pro provide a feedback that can be either positive or negative feedback. What is usually look what we are looking for? When we are doing the code review, we want to identify if the solution that is being uh being developed, if it is completed is that is that working as expected? Uh We also want to see the consistence for that uh feature being developed, whether the consistence on the code itself, it's following the, the the code guidelines or even the consistence for the product itself. We also identify what are the side effects that might be hidden uh on that code. Is there something that will cause problems later when we are integrating to a bigger part of the software or when someone might be using that uh API or something that we are doing incorrectly? What would be the, the, the problems that will come from that? We are also in finding what is the inability of that code? Will I be able to get back to the code that I'm writing today in one year from now and understand and remember everything about the reasoning about of the decisions about the code itself.

Will someone else be able to get that code and start working on that? And I'm also trying to see and identify if the tests that were done for that feature for what we are? Doing uh on the patch on the the solution. Is there enough tests to cover that? Will that will that create or has a pos uh has the possibility to create a kind of a performance issue on the software that we're developing. Uh All of those are examples of what we are, we are usually looking for when we are doing review those. Again, those are just a few examples that is even more. But I think it gave everybody an idea of what is code review and what we are looking for when you are doing code review. So let's talk a little bit about the types of reviews. So the first one which might not look like a type of code review, but I'll, I'll explain and it is it is the pair programming. So pair programming for those who do not know that is when two people are working in developing something together using a single code computer, it can be done, it's done usually with someone typing and the other person commenting or suggesting what should be typed and usually those roles they are, you can change that uh and working this way you create a solution together.

So when we are working like that, you already comment, you are already suggesting change. You are already saying what could be the problem. So this is already a form of code review and it is a form of code review that allows for fast response because the people who are asking and who are reviewing, actually who are asking and who are reviewing is the same person and they are working together at the moment and they can solve the issues as they come when they are working.

It's very good for complex problems. When usually uh the people who are involved here, the knowledge of those people, they kind of complement each other's knowledge or even if they don't have the knowledge to start with and they build that knowledge together. The downside of that is that it requires a allocation of two people to solve one problem. So it's not a silver bullet, it is not something that can be used on all the scenarios because this can be a problem. Uh because you have two people working on the same things. This can be a problem. This can be a limitation on the amount of work that can be done. But again, this is still a valid and good option. The second one that I'm talking today is live review. And the idea here is to get everybody in the same room or visual room and show the code. And together you go line by line reviewing and comment on the, the the issues that are being found. And the again, this is uh this is a very good uh uh this will allow for a fast response because you have everybody in the same call, you have everybody in the same room So the the iterations between asking something and explaining these are usually very fast and this is great for when you have to give a little more con context that not only the code itself or some kind of explanation is enough, but the problem is that you create a higher context switch for who is reviewing that code.

This becomes another meeting in the day of that person and the person has to stop that, stop what they are doing, go to the meeting and then get back, get back. So the context switch for the review is really high and we have the synchronous or two assisted uh type of review. And as the name suggests, this is an asynchronous process where someone sends uh works on a patch works on a code, sent this code to someone else or to other people. And those people will give comments, we will, we will suggest change, get back to the first, first person, this will go a few iterations until the solution is actually approved by the reviewers. Usually we do that using tools uh that help the the comments and the tracking of these iterations. Uh I have choose to show here the example that we have on github. But there are many other options and the good side of that that it really breaks the dependencies in the process, the process, creating a very well established uh process.

When your developer, you develop your test, you do the manual tests, then you do the review, then this goes to A Q A, this really creates this established flow uh software development flow. And this allows for a less context switch for the reviewers because I can work or I can continue work on what I'm doing. If a review comes in, when I finish that, I'll do the review. But as you imagine, this can take longer than the the the the other options because this could, this will depend on the priorities of the reviewers and might be a problem. So you saw all of those options and you might be thinking which one should I be using? And the answer is to use all of those depending on the scenario that you have. So understand what are the, the, the upsides and downsides of that and most important because you choose to use one doesn't mean you, you don't need to use the other. You can do pair programming and then use an asynchronous uh code review process to go over that again. So have information knowing that those options are available, try it out and adjust to the problem and to the the the the the conditions that you have. So let's talk about now on why code review should be applied. I already give a spoiler about that. And the first thing that I want to mention that is reducing costs, we are catching a her earlier than they. Uh we are catching a her earlier.

So the cost for the development is uh is cheaper. And because the cost it's cheaper because we are actually not because the cost is cheaper, but because we are catching a her earlier, we are increasing the quality of the tool that we are delivering. And also because the quality is higher, the customer is happier but there is more to that sorry. So another reason why code review should be applied is that it increased. The collaboration between the team is not one person working alone on developing something. Is that one person working and asking for review from other teammates and people outside their team and really creating a collaboration where everybody involved is contributing to the creation of the solution. It also is a great way of mentoring junior people because you are teaching them in practice.

It's really uh you are, it's not a scenario hypothetical of what should be done. We are really doing that and we are teaching them how to do that better. It's also a great way of reducing the bus factor, the bus factor for those who do not know I really like this term is uh that scenario where you say, oh imagine if someone is hit by a bus. So we do not want anybody getting hit by both years. But there might be a few reasons why someone from your team will be leaving the company or leaving the project being relocated and what would happen to the code that that person maintained. Will someone from your team be able to get sorry to get and work on that in that person's uh place because of code review. Because you are sharing the information, we are sharing the information on the code. Uh What is being done? Why it's being done that way. Uh You help more people in the team to really have a notion of what is uh what is the, the what is the code doing? So this reduce your buzz factor for the development for your team. So let's get into the, the the final part of uh this talk when I'm gonna give you tips for really uh take making the most of code review. So the first one is to review everything. You might think that one line, you are changing just one line.

So I'm not going to bother anyone with asking for a review, but maybe in that one line, you forgot a typo and will cause the a rocket that you are developed to uh have to be exp exploded. So we never know. Uh So ask for ask reviews for everything, make sure that there are no exceptions uh in in your flow. The second thing is to use checklists, especially if you are new to that. If this is something that you and your team are trying out and is not uh a well established process, try to think of how would you tackle the review, you would first check for uh code guidelines, then variable names, anything like that, get your team together and think of how would that be done and have that checklist in the first review uh for the first reviews to really be able to see if you are forgetting something or not after this become intuitive and you won't need the checklist anymore.

So the next tip is to review before me, you might be tempted to sorry to do the review to do the code, then push the code and merge it and later uh send it to someone else to review that. Uh But let's be, let's talk about, let's be truthful here because uh you won't be working on that anymore at the point when someone sends feedback, if feedback is sent because the person might think, oh, it's already merged. Why will I ever care about that? Uh You already be working on something else and this will become less of a priority for you. So try to review before merging everything also automate what's possible. I think this is a, a tip for almost everything in the tech related world uh where you want to make the process of creating reviews and review itself uh to be easier as possible. Not only that you can take advantage, you can take um you can use of tools out there that are linkers and other checks to do some kind of pre work for for the reviewer. And we will allow the the people to do a more easy job, a easier job when they are reviewing. And very important is that everybody gets in the game. Uh It's not about junior ask reviews for uh senior people.

Senior needs to ask reviews for other people too because it's sometimes the fresh eyes of a junior person that will catch issues in the code. Also plan and share the load. Make sure that the process is accountable when you are planning and estimating what is the effort for a task. And also make sure that there is not just one person in the whole team who is doing the review, everybody should do the reviews and also embrace the subconscious thoughts. This is something that we might be thinking. Oh my God, I don't want to show the disc code. People are going to criticize me. I don't think I'm good enough embrace these thoughts but make sure that the the these thoughts they don't, they don't prevent you from doing the review and from showing your work. I think this is actually a tip for more of your life. Uh Make sure that this is will not stop you, make sure that this will allow you to become a better professional but will not stop you from trying and finally, don't take that personally, don't take reviews personally. A critic is a critique of the code that you wrote and you can always and you will always get better at writing code. This is not a critique on you. So don't be afraid of code reviews.

Uh Don't, don't think you should not try and you, you are not too good. There is no such thing as being too good for review doesn't really exist anything like that. So don't take that personally. Uh don't really don't uh don't allow this kind of things that we might be uh thinking to prevent you from doing that and for showing your work. So that was what I have to talk about today. I hope I was able to share some new information with you. And I know that uh although very common, there are still some companies and some teams that do not practice uh code review, but I highly suggest for you to try uh and to try to put in your uh in your software development flow. Uh I don't think we have really time for questions, but if you have any feel free to send me uh those on the chat, I'm gonna stick around a bit for that on the chat and also feel free to contact me on my social media. Uh All my contacts, they are on my site, which is Tamara dot dev. And thank you very much for being here and let's let's connect and talk more.