Looks good to me: Cisco’s Adrienne Braganza Tacke on how to do code reviews

We caught Adrienne at Infobip’s Shift conference – where she held a presentation titled “Looks GREAT to me: Getting Past Bare Minimum Code Reviews” to talk more in detail about what a good code review process looks like, what teams do wrong when it comes to code reviews and, of course, to what extent AI will change the process of code reviews.

AI cannot replace human understanding of code

Kelsey Hightower said in an interview for ShiftMag that human code reviews are even more important in the age of AI-generated code. What’s your stance on the role of AI in the code review process?

Adrienne: Many jokingly say that AI could replace the code review process. In addition, programs or tools can estimate how long it takes to create one code revision. These tools are not there to replace those involved in this process but to provide them with additional assistance.

On the other hand, AI solutions are there to help us, not to replace us.

The way I see the use of AI technology is for it to act as an assistant, for example, to remind us of some things we would not have remembered in a specific process. AI cannot replace human judgment and understanding of code.

What tools and processes are essential in the code review process?

Adrienne: The most popular forms of the process are based on the tools used. GitHub and Bitbucket represent a kind of assistant for developers with various online code pieces.

But there is also the process of pair programming; more precisely, people work together on one code and thus complement each other, correct their mistakes, and continuously revise the code, which can also be characterized as a part or form of the code review process.

Any time someone else looks at the code and provides an additional check, specifically that it’s a third party and not your own eyes, I also consider that a suitable code review method. You don’t necessarily need to rely on tools and resources like Github, but having someone else look at your code, read it, and provide feedback is necessary.

If a reviewer doesn’t understand the code, something is wrong

What do teams need to improve regarding the code review process, and what are they doing wrong?

Adrienne: The first and foremost thing that teams must do is create a team agreement on how to perform the code review, more precisely, whether they will use tools or focus on pair programming. The point is to make a plan and compromise, put it on paper, and then start a specific process. This is also a good practice for any other procedure within an IT company working on complex tech projects.

Do the challenges for all involved in the code review process depend on the complexity of the code itself?

Adrienne: That is the case. Because the complexity of the code depends on the project for which it is intended and on which a particular company is working. Because of this, there may be a situation where someone involved in code review is unfamiliar with a specific part of the project, which can lead to challenges.
On the other hand, there are also complex codes that are very difficult to follow so specific challenges can arise from that side. Also, we must remember that highly paid professionals do this work.

If a reviewer needs help understanding what is happening in a specific piece of code, something needs to be fixed. You need to react immediately and make changes and new inputs.

Everyone involved in the code review process must also understand the context behind that code and why certain changes are made, whether there is specific documentation or everything that will ultimately facilitate the process of removing errors. Finally, the goal is for anyone who gets insight into a particular code to understand that same code and then find and fix existing bugs.

Context is key

What would be your ultimate advice on conducting the code review process?

Adrienne: I’m writing a book called “Looks Good to Me – Constructive Code Reviews” that should be available soon. It all comes down to context and communication. The most important thing is to provide context as best as possible to everyone on the team, to talk with people about how to do the process, and to understand the code as best as possible. It’s all based on how well we can understand the code and its implementation later and how we can make it even better through communication.