Where I work, we are eight software developers and every task done must be reviewed by another developer. Often, I feel like the code reviews are done too quickly (example: a task completed in five hours gets reviewed in 15 minutes). I know I can easily spend an hour reviewing a task that took five hours to complete.
Here is what we agreed, as a team, to verify when we do a code review:
- The code written/changed solves the problem (bug fix, new feature, etc.)
- Code is clean and well structure (to our standards)
- Code style is correct (to our standards)
- Documentation, if any, is up to date
- Unit tests cover all the possible cases and do not fail
I was wondering if it's my code reviews that are too long or if it's the code reviews of the others that are too short. Or maybe both?
Edit 2015-10-06 15:55 EST : I agree that there is no one-size fits all answer to the question as mentioned by Thomas Owens♦. I guess I was more looking to what should trigger a flag for a code review too short or too long. Or should I simply don't care and let the code fail in production because someone botched a code review (because it does happen)? Remember, we did, as a team, agree to verify that the code solves the problem. We have no QA team.
I ask because it happens that code pushed into production fail. While I agree it can happen, it happens too often in our team. When we talk with the developers to learn what happened, we learn that the code review simply didn't happen (this is more a process problem than a code review problem) or the code review was deficient / not tested enough.