4 ms·

Are there really places doing post-production code review? That sounds like a terrible practice. I've worked for places that didn't have code review, and place

Are there really places doing post-production code review? That sounds like a terrible practice. I've worked for places that didn't have code review, and places with pre-production code review. The ones that didn't code review brought in code review practices (like they should). I have never seen a post-production review process though.

rjbrock 11y ago
There are, but they frame it more as an "architecture review". Often this takes the form of a 3+ hour meeting going over all code that devs have committed in the last month or so. It is a terrible system. If you aren't reviewing code before it goes in you are missing a HUGE opportunity to review for bugs and correctness before a client experiences a crash.
sheepmullet 11y ago
There are plenty of places that do code reviews post-commit, but these places pretty much always just have their CI push to a staging server and not prod.
- zzalpha 11y ago
  Post commit, sure... I still prefer pre-commit, but I get why some might do post-commit. But post-prod? Why even bother at that point? Might as well put off writing tests and so forth, too! Go BIG!
  - benjiweber 11y ago
    From the other side pre-prod code review just delays software getting into production. Delays here tend to lead to bigger, riskier changesets. I'd rather continuously-deliver sub 1hr of changes to production several times a day. Pair & Mob programming provide continuous code review pre-commit, but they don't provide all the benefits of traditional code reviews. It can be valuable to sit down as a team and or with others who didn't work on some code and think through how to make it better/improve it asynchronously.
    - zzalpha 11y ago
      From the other side pre-prod code review just delays software getting into production. Delays here tend to lead to bigger, riskier changesets. That makes no sense. If delays introduced by pre-prod code review result in "bigger changesets", you're clearly doing it wrong. In fact, if you batch up commits to deliver to prod on some semi-regular basis, the exact opposite should happen. Individual changesets would be exactly the same. Velocity may slow down (that is, it may take longer for any given changeset to make it to production), but you're producing higher quality code in exchange.

rjbrock 11y ago

There are, but they frame it more as an "architecture review". Often this takes the form of a 3+ hour meeting going over all code that devs have committed in the last month or so. It is a terrible system. If you aren't reviewing code before it goes in you are missing a HUGE opportunity to review for bugs and correctness before a client experiences a crash.

sheepmullet 11y ago

There are plenty of places that do code reviews post-commit, but these places pretty much always just have their CI push to a staging server and not prod.

zzalpha 11y ago
Post commit, sure... I still prefer pre-commit, but I get why some might do post-commit. But post-prod? Why even bother at that point? Might as well put off writing tests and so forth, too! Go BIG!
- benjiweber 11y ago
  From the other side pre-prod code review just delays software getting into production. Delays here tend to lead to bigger, riskier changesets. I'd rather continuously-deliver sub 1hr of changes to production several times a day. Pair & Mob programming provide continuous code review pre-commit, but they don't provide all the benefits of traditional code reviews. It can be valuable to sit down as a team and or with others who didn't work on some code and think through how to make it better/improve it asynchronously.
  - zzalpha 11y ago
    From the other side pre-prod code review just delays software getting into production. Delays here tend to lead to bigger, riskier changesets. That makes no sense. If delays introduced by pre-prod code review result in "bigger changesets", you're clearly doing it wrong. In fact, if you batch up commits to deliver to prod on some semi-regular basis, the exact opposite should happen. Individual changesets would be exactly the same. Velocity may slow down (that is, it may take longer for any given changeset to make it to production), but you're producing higher quality code in exchange.