4 ms·

Well, in the places where I've seen it done right, the code reviews happen before the code is committed. Fixing existing code after it's already in the code ba

Well, in the places where I've seen it done right, the code reviews happen before the code is committed. Fixing existing code after it's already in the code base is a losing battle (particularly since it usually has to be re-tested), and you'll get pulled off onto "more important work". And it's not a kludge, it's a very good way of improving code quality (possibly up to the union of your better programmers' skills) and preventing dodgy crap from seeing the light of day. > Anything that prevents me from doing my job (shipping code) is going to cost the company money. I think you meant "working code" there - where "working" means "solves business problems" as wells as "not buggy" ;)

damncabbage 13y ago
Well, in the places where I've seen it done right, the code reviews happen before the code is committed. Do you mean before the code is merged? Either programmers at these places worked directly together (eg. pairing), or they weren't using a DVCS like Git or HG. We use GitHub at work, with code-reviewed Pull Requests. You do you work (pairing as you want), then ask for it to be merged. It gets reviewed by at least one peer, and you get feedback, discuss and make changes, and then merge those into trunk. You get the benefit of code review, while also being allowed to carry on with something else in the same codebase without sitting on your butt waiting for a code review. (Has anyone else tried this and had good or bad results?)
- jwilliams 13y ago
  Yup. That's exactly what we do here too. Good results and a noticeable increase in quality.
- anthonyb 13y ago
  Committed into master / dev branches, was what I meant to type. And yes, essentially pull requests, but in person rather than over the internet :)