Code Review
FleetingWhen some people take a look at the code of some other people prior to pushing it.
It enables the following objectives.
- it allows sharing knowledge,
- it allows sharing opinions about the way we should do things (see guided serendipity),
- it prevents some kinds of inadvertent mistakes,
- if enforced, it brings some control about what eventually ends in the main branch,
This code review can be achieved synchronously or asynchronously. The former is preferred when it is important to make it fast and avoid common communication errors1, the later is preferred when people cannot meet easily because of time zone/language/availability/shyness/trust issues. Therefore, the later is broadly used in open source projects and made the default in collaboration tools like github.
asynchronous code review should be used only when it makes sense
People tend to enforce asynchronous code review, almost dogmatically and implicitly pretending that it is a good thing per se.
I don’t share this opinion. I believe that people should focus on the objectives presented above. Otherwise, they fall into the measure-objective inversion problem. With that in mind, they should decide what kind of code review to use (or even if a code review is really necessary) in a case-by-case basis.
Unfortunately, I often see people blindly following the procedure and the code review is done without getting the final objectives reached…