How To REALLY Do Code Reviews [Video]

Welcome to the follow-up to How To Do Code Reviews, with many moooooore details on the human factors involved in a code review, as well as several options on how to approach reviewing pull requests.

Just a quick recap, what is the scenario? A user sent in a GitHub pull request for our Google Photos clone, which means we have to do a code review. How should you do such a review? What is or isn't important? Let's find out in this episode of Marco Codes.

What’s in the Video

00:00 Intro 

In the previous episode, we did a code review of a pull request, but due to the way it was edited, there was a lot of missing context. We will try and add context in this episode and look at a variety of factors involved in code reviews.

01:07 What Is a Code Review?

Even though a lot of people seemingly agree on what a code review is, they differ from team to team and company to company. We will learn about code reviews as happening on a spectrum, from very conservative styles such as in the Linux Kernel to more laissez-faire styles, where people superficially review an insane amount of code changes.

02:48 Levels 

Code reviews differ depending on the actual skill level of the people involved in them. Is the reviewee junior, or the reviewer senior? Are two seniors reviewing each other? We'll have a look at how feedback will differ depending on these different levels.

05:26 Ego 

Ego is a topic involved in every review and it should be kept out of them as much as possible. Again, this goes both ways. The reviewer shouldn't approach the review with an "I know everything better"-attitude, and the review shouldn't see comments as personal attacks, but rather as a chance to learn something.

06:13 Philosophy 

What is the general code review philosophy in the company? Is it merely about reasoning about edge cases, or is it more of a code review++ where the reviewer is expected to deeply reason about every proposed code change?

07:19 Project Type 

Is it a public project? Maybe an open-source project on GitHub? Or is it a commercial project, that you work on together with a close-knit team? Depending on the project type, it is or isn't possible to reject pull requests and hence your review style will also differ.

08:24 Location 

Can you quickly walk into another room to sit together with the reviewee and discuss code changes together? Or do you have to play comment ping pong through a web application? This will significantly affect your code review style.

08:59 Time 

Most importantly, is the company you are working for, willing to allow the time needed to do proper reviews?

10:38 What We Will Review 

In this segment, we will have a quick recap of the original problem that was solved through the pull request for my Google Photos Clone.

11:51 Review Style 

I will elaborate on the style used for this review, taking into account all the variables mentioned earlier.

13:02 Inspecting a Pull Request 

Time to do the actual code review. Let's fire up an editor and see how we can specifically review a pull request.

19:04 Giving Feedback

As a result of our code review, we have different possibilities to provide feedback to the reviewee. Let's talk about 2,5 ways that make sense for this review!

22:44 Outro

What are your thoughts on code reviews? How did you do them in the past? Let me know!