My company recently started doing formalized code reviews. The process goes like this: you submit into a github, request a pull request, code gets reviewed by approximately three people, then if all passes, your code goes in.
The process seems fair, however the three people who do the code reviews don't seem to be fair. I notice that when I put my code in for review, I get anywhere between 100-200 comments. The top number for me was 300 comments once. Of course you'd think it is big changes, but this can be very small changes as well with less than 50 lines of code (which includes unit tests). All comments are considered "must do" and without argument.
With that in mind, my main problem here is that it seems a bit excessive. I talked to the group and they told me basically that just because I had so many years of development in php doesn't mean I am an "developer." Of course this seems more hurtful than not. Also I notice that within the group, they don't appear to produce as much comments and most of the time they ignore or otherwise disregard other comments or suggestions rarely accepting it as a valid point even if something is broken.
So my question is if this is fair? Or common?
Best Answer
IMHO that's the real issue, since there is no priorization in that. When you get 100-300 comments, there must be some of them having a priority A (real bugs), some of them prio B (likely to lead to bugs later) and some of them prio C (everything else). Tell your colleagues that you are willing to respect all their wishes, but to make changes effective, and your time is limited, insist on a priorization. Then, start with fixing prio A comment first, and if you really have time for more after that, you can start with B (if you are lucky, your boss will understand that fixing prio B and C is not so important, and give you some more important tasks instead of wasting your time).