727
Merge then review
(programming.dev)
Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don't let code become stale.
Before everyone loses their minds, in Extreme Programming there are safeguards other than PR reviews. Before you submit a PR, you are supposed to have written the tests and to have written your code with pair programming, so your code already has some safety measures in place. On top of that, when you merge and deploy, more tests are run, and only if all of them are green do your changes go into production.
Pair programming? Then the code is already reviewed.
Yes, that's part of the point. Dumping all at once into a merge and asking people to comprehend it all isn't particularly realistic.
I commented out the tests because they were failing, pipelines were green so I merged. Now it's running on prod. What do you do?
Fire you for destroying the tests. It's intentional sabotage.
Give you public kudos for moving fast and breaking things. We need more fearless cowboys like you around here
I would fire you for incompetence and sabotage. Problem solved.
I just made a github action that merges anything updated in master into feature branches automatically. you get pinged if there's a conflict but the automerge keeps drift to a minimum so it's less common and fixed sooner.
better than merging poorly tested/reviewed code.
and yeah, a small team of superstars doesn't need reviews so much, but most teams have a range of devs with different levels of experience and time working with particular parts of a large codebase. Someone more senior or more expert derisks people picking up tickets and improves code quality.
it also leads to plenty of good conversations about the best way to implement, so overall it's a win.