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 the control”, and then you open your laptop, and realize, that there are at least 3 code review requests 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 easier, but from my personal 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 a number of code lines that were changed and a number of 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 limitation 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 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 head. 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 code bases frequently though last couple weeks, and have fresh mental models in their heads. 

I don’t know a perfect solution for this, but 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 code base, and are responsible to do code reviews over changes, that is happening in their part of the code base. 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 (just have much more in it, than just what I have mentioned). 👏👏👏

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Olena Sovyn
Senior Software Engineer (London, UK). I ❤ React, Redux, lodash, React Storybook, and functional programming overall. Always open for learning something new

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Spelling error report

The following text will be sent to our editors: