3 ms·

I've never worked anywhere that code reviews were more effective than communication (ideally pairing). The process feels like a kludge to try and solve code qua

• anthonyb 14y ago
  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 14y 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 14y ago
      Yup. That's exactly what we do here too. Good results and a noticeable increase in quality.
    • anthonyb 14y 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 :)