May 12, 2014 · code-review development-process

Reviewing Unfamiliar Code

So something that is done at my current job that was never really done (at least formally) at my previous jobs are code reviews. I think it is a great thing to have code looked at by more than one person but this got me thinking, should you be reviewing unfamiliar code?

When I say unfamiliar code, I am not talking about code that you have not worked on before since that is generally going to be the case when it comes to code reviews. When I say unfamiliar code, I am talking about reviewing code in parts of the stack that you don't work on. I am a primary front-end developer and 90-95% of my time I spend in HTML, CSS, and JavaScript. How useful is it for me to be reviewing back-end PHP/MySQL code (or whatever it might be)?

The Benefit

The benefit I see with reviewing code in the parts of the stack you don't normally work in would be that it allows you to become more familiar with that code. I can understand this thought process and it does make sense however I don't think the main reason for doing code reviews is to become more familiar with the system, it is to make sure the code that is being pushed is of a high quality.

The Downside

With that mindset, having someone review code that they don't work in on a day-to-day basis seems like a bad idea to me. I mean there have been commits I have seen that I would have given a passing grade on in a review where others who work in that part of the codebase on a day-to-day basis have given comments of improvements that should be made.

Now I agree that you should have at least a high level understanding of how the application you work on works from top to bottom even if you don't work in all the parts of the system on a day-to-day basis, I just don't think code reviews is how you should be exposed to those parts of the system.

It seems to me like if you have the developers, developers should mostly be reviewing code that they work in on a day-to-day basis. Front-end developers should be reviewing front-end code and back-end developers should be reviewing back-end code. I think this will give you the best results as far as code quality is concerned. Now if you only have 1 front-end/back-end developer, then it's fine for a back-end/front-end developer to review the code (better that than no-one reviewing the code).

What do you use code reviews for? How do you handle who reviews what code and what works best for you?

comments powered by Disqus