Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
My hot take: PRs and branches are bad.
Everyone knows the shorter lived a branch is, the better. But PRs are designed to block them from merging.
Instead, work on the master branch directly, and continuously review code via paired programming or mob programming.
Shift reviews left, so they stop being gate keepers! -
Agree with the mob and pairing ^ 🍹🍻.
It's been the best thing our teams ever did apart from adopting TDD
In meantime speak to the dev. They might be happy to split their tidies into a separate PR that goes in before / after their main code change.
Atomic commits help too
Also comments in code are considered by most as a failure to write code expressive enough to capture what you're intending for it to accomplish -
@MammaNeedHummus oh god the number of times i've been told to rebase a 50-commit overhaul of something because "you only get one commit per PR" on public projects is fucking staggering. i hate it.
-
Fuck that's shit as @Parzi. Maybe introduce them to atomic commits? Idk
-
@Parzi this looks like a well written article about it: https://aleksandrhovhannisyan.com/b...
Related Rants
code review
the two code review personality types
review activity:
- dev A: requests code review, sets dev B and dev c (myself) as reviewers
- dev C comments: this review is marked with a complexity > 9000, touches > 20 files and has zero comments... also there's a lot of refactoring going on, making it hard for me to tell what the actual relevant changes are. can you please add more comments to this review?
- dev B (10 mins later): approved review
rant
code review