Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don't let code become stale.
You guys review?
this post was submitted on 14 Nov 2023
691 points (97.1% liked)
Programmer Humor
19623 readers
88 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
I kind of with the sentiment. Review pre merge though, but only block the merge if there are serious faults. Otherwise, merge the code and have the author address issues after the merge. Get the value to production
This is some poe's law shit. I can't tell if you're serious or just committing to the bit.
Sorry about the confusion. It's not sarcasm. I'm just sick and tired of people blocking my PR because of an argument about wether the function should be called X or Y or Z or D
Ah. Yeah those kind of nitpicks are annoying. We try to specify when comments are blocking or non blocking on reviews.
But I definitely block a lot of reviews over no tests, bad tests, no error handling, failed linting. And the occasional "this doesn't do what the ticket asked for"
I'm with you. I've worked on a few teams, one of the first was a company where two teams were contributing code changes to the same product. The other team "owned" it and as a result it took ages, sometimes months, to get code changes merged. It meant more time was spent just rebasing (because merging wasn't "clean") than working on the actual feature.
My current role, we just do TDD, pair programming, and trunk-based development. We have a release process that involves manual testing before live deployment. Features that aren't ready for live are turned off by feature flags. It's quick and efficient.
Fundamentally I think the issue is the right tool for the job. Code doesn't need to be managed the same way in a company as it does in an open-source project.
Code doesn't need to be managed the same way in a company as it does in an open-source project.
Open-source projects are usually longer lived more maintainable, more stable, and more useful than any closed source code I've ever worked on for a company. Partially because they're not under contract deadlines which create pressure to "deliver value" by a certain date, but still. Might be helpful for companies to consider adopting practices the open-source community has shown to work, rather than inventing their own.
Get the value to production
Ugh, not this SAFe Agile (tm) cultist bullshit. The "value" is working, bug free code, which you get when you put it through review and QA before it gets to production.
There is no value in spaghetti piled on top of rotten spaghetti. Tech iCal debt is real and if you're just shippin it and plan to fix it later, y'all gonna have a bad time. Nothing more permanent than a temporary workaround.
There's often features and bug fixes worth more than the ones introduced in the PR. I've yet to see bug free code just because it's went through review and QA.
Surely you've seen bugs caught because code went through review and QA though. Those are bugs that would go into production if following the "advice" in this post.
I'm saying identify the bugs through review, and fix them. Just do it in a new PR unless they are critical
load more comments
(5 replies)
It can work if you have a test zone and only a small amount of people work on a given code base.
Also checks to ensure the code compiles and tests pass before merging, as some quality gateway.
Probably unpopular opinion, but peer reviews are overrated. If coders are good AND know the project, the only thing you can do in a PR is nitpicking. They are more useful for open source collaborators because you want to double-check their code fits with the current architecture. But people here are reacting as if peer reviews could actually spot bugs that tests can't catch. That happens rarely unless the contributor is junion/not good.
If coders are good AND know the project
Those are some pretty big ifs.
Code review can't fix incompence though. I lost count of how many times my boss told me "review that PR well because X is not very good". Also my point is that they are overrated, not that they are useless.
load more comments
(2 replies)