|
|
|
|
|
|
by LnxPrgr3
3409 days ago
|
|
|
I know exactly zero developers senior enough to have gotten over writing bugs. I know I've written bugs that happened to pass all my tests only to blow up in somebody else's face, sometimes after surviving years of production use. Code review would've at least had a chance to catch them early—so long as you treat it as critical analysis of program logic and not just a screen for generic goodness. IMO if your code reviews are glorified manual style checking, you're doing it wrong. |
|
|
No one was arguing that. Code reviews aren't for bug discovery, though that can sometimes happen. It's a very inefficient way to discover bugs.
Developers should test their code for bugs before completing the task and submitting to QA. QA is a more thorough than development bug / unit testing and includes integration. Betas (if applicable) are the final source of pre-release bug discovery. Spending a bunch of time on code reviews to find bugs.
IMO code reviews should do two things:
1. Make sure the developer knows how to develop and is not being sloppy and not following whatever standards are set (comments, etc). They are essentially training wheels for new developers to the organization and junior developers.
2. Make sure the code represents what the developer thinks it does (sanity check).