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?
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.
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?