> First and foremost, code reviews are a quality control mechanism to mitigate risk.
That's the ends. The means is collaboration and communication between team members that might otherwise be isolated / silo'ed. The means are what's important.
For new team members sitting in on CRs give them a window into team, culture and code. This isn't easy to duplicate otherwise.
Finally, and I'm surprised it wasn't mentioned, even in passing. I would imagine there are legal implications. Turning your back on an accepted best practice and then sonething goes sideways...questions might be asked and fingers pointed, etc.
Casting aside CRs might be a short cut, but short cuts - regardless of paradigm - eventually catch up to you.
That's the ends. The means is collaboration and communication between team members that might otherwise be isolated / silo'ed. The means are what's important.
For new team members sitting in on CRs give them a window into team, culture and code. This isn't easy to duplicate otherwise.
Finally, and I'm surprised it wasn't mentioned, even in passing. I would imagine there are legal implications. Turning your back on an accepted best practice and then sonething goes sideways...questions might be asked and fingers pointed, etc.
Casting aside CRs might be a short cut, but short cuts - regardless of paradigm - eventually catch up to you.