The data disagrees with you. Code reviews are the single most effective bug-catching tool we have as developers. While it's a bit older (2004), Code Complete lays out some examples of this. Here's a Coding Horror blog entry about it:
Granted, we have a lot more tools now than we had then, but this kind of basic truth about software development rarely changes. You still need good design and teamwork (peer programming is great), but before you'd convince me not to make this a part of my development process, you'd need to show some proof that this has changed and code reviews are no longer effective. My experience on even recent reviews says they are still effective in real world usage.
Maybe you're dealing with a toxic environment where code reviews aren't done with a professional demeanor and everyone setting aside their egos. That's certainly a challenge. You need good facilitators on your team -- preferably other active developers -- to make sure everyone is respectful and that the code review process encourages that. That means having things like a team-agreed process -- e.g. an adopted style guide, run the linter before creating the review, comments on code must be backed up by (not just opinions), etc.
I'm a web developer and consultant, web GDE, and author of open source libraries. I co-founded 500Tech, a company that specializes in frontend technologies. I love coding, and love speaking about code
Thanks for the feedback!
Well, I admit the article's title is a bit provoking, but the message is not to stop reviewing each other's code, but how I think this will change in the future and allow us to collaborate more early on and more frequently. I definitely agree that in today's environment, every piece of code should be reviewed and that's our current practice.
As I lay out in the final paragraph - "The future of CRs - continuous review":
"Despite the current automation, we still do CRs. That's because we always want another pair of eyes on the code, and automation is still basic and can't understand the context of our code."
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The data disagrees with you. Code reviews are the single most effective bug-catching tool we have as developers. While it's a bit older (2004), Code Complete lays out some examples of this. Here's a Coding Horror blog entry about it:
blog.codinghorror.com/code-reviews...
Granted, we have a lot more tools now than we had then, but this kind of basic truth about software development rarely changes. You still need good design and teamwork (peer programming is great), but before you'd convince me not to make this a part of my development process, you'd need to show some proof that this has changed and code reviews are no longer effective. My experience on even recent reviews says they are still effective in real world usage.
Maybe you're dealing with a toxic environment where code reviews aren't done with a professional demeanor and everyone setting aside their egos. That's certainly a challenge. You need good facilitators on your team -- preferably other active developers -- to make sure everyone is respectful and that the code review process encourages that. That means having things like a team-agreed process -- e.g. an adopted style guide, run the linter before creating the review, comments on code must be backed up by (not just opinions), etc.
Thanks for the feedback!
Well, I admit the article's title is a bit provoking, but the message is not to stop reviewing each other's code, but how I think this will change in the future and allow us to collaborate more early on and more frequently. I definitely agree that in today's environment, every piece of code should be reviewed and that's our current practice.
As I lay out in the final paragraph - "The future of CRs - continuous review":
"Despite the current automation, we still do CRs. That's because we always want another pair of eyes on the code, and automation is still basic and can't understand the context of our code."