2 dimensions of the code review process complexity

Photo by Pankaj Patel on Unsplash

You have probably been in my place. You have perfectly planned working day ahead, there are around 2-3 tasks that you need to do, and you think: “Wow, I finally have it under control,” and then you open your laptop, and realize, that at least three code review requests are waiting for your feedback. And even though you have recently working in some of the files, that PR is changing, CRs take much more time than you would expect.

A year ago (not sure about timing here), GitHub introduced the possibility to suggest folks who should be assigned to do code reviews, based on who last was reviewing or editing corresponding files. At first glance, it supposed to make all the process of finding the rightish person more natural, but from my observation – it is not always the case.

One of the ways better to understand why it is not like this is to think about code review in a more abstract way, especially about their complexity. I think it can be measured similarly to algorithm complexity in two dimensions – time and space.

Code review space complexity is several code lines that were changed and several files that were changed (under changed, I mean added, deleted, or modified). It is easy to measure, and as well it is easy to put some limitations on it. For example, an automated warning message can be added to PR if author/authors are changing more, than N lines of code, or M files in the same PR (hands up, it is not inbuilt GitHub functionality, but can be added with something like Danger.js).

Code review time complexity is an amount of time that a person performing code review needs to build mental modal around changes that have been made. And I think this is the reason why folks that are proposed, based on the fact that they were last who edited this code, might be not the best choice as code reviewers. It might be months from now on when they last were doing something in those files. Their mental models have already faded enough, so it would take them a lot of time to rebuild them in their heads. Or they might be working with a different part of the functionality, that somehow was using the part they have changed in the current PR, but their main mental model was around another part of the architecture. On another hand, there are folks, that never edited this part of the code base, but they have a quite good understanding what is going inside it, as they interact with a related part of the codebases frequently though last couple weeks, and have fresh mental models in their heads.

I don’t know the perfect solution for this. Still, I think, that even being able to think about CR in this paradigm can be helpful if one is looking for the ways to improve engineering processes in their company, or trying to understand why some of the code reviews are so easy to do, and some are just not.

One of the ways to overcome this that may work is to have teams that are dedicated to specific parts of the codebase and are responsible for doing code reviews over changes that are happening in their part of the codebase. In this case, the choice who’ll be code reviewer is more curated, and fewer depends on probability. At Webflow (the company where I am currently working), one of our engineering manager – Yoav – proposed and make it live approach, that is very similar to what I have described (have much more in it, than just what I have mentioned). ???