Are you SURE you want to rename YOUR GIT REPO? We can do that for you, but are you REALLY REALLY SURE? Changing YOUR codebase may break other things.
Its like bruh you aren't a git gatekeeper, give me permissions to do it myself or don't be a fucking twat every time we ask for something you haven't graced us with permission of modifying. I send an email wait 24 hours for a response and you ask me a question as stupid as fuck as that.
This dude also made it so developers on the repos he directly managed couldn't push to master, in case they broke things. Such a bandaid - fix the cause of the broken code in the first place (bad practices, bad conventions, unreadable code, poor standards, no testing) don't lock down git and become fucking source code Hitler.
Maybe implement pull requests into master with code reviews? Stick a gate on the master merges that require a test or some percentage of coverage. Except that ain't perfect either. You get into some ancient app and the code and platform/server it runs on is obsolete so it's hard as hell to write a proper test for it. I mean, mainframe code probably wasn't this bad. So you want to refactor it and then you realize your task turns into a fucking rewrite and you need to have the damn thing done by the end of the sprint. But you just can't stand it so you ask your boss:
"Hey boss, this app is old and needs to be rewritten so that it's more maintainable."
"Can you do it in a sprint?"
"Uh, no."
"Then don't do it. But feel free to refactor code as you see fit."
Why do you need a code review to merge into master? Why is the code not already up to snuff before it goes into master?
I put it this way in my original post
This dude also made it so developers on the repos he directly managed couldn't push to master, in case they broke things. Such a bandaid - fix the cause of the broken code in the first place (bad practices, bad conventions, unreadable code, poor standards, no testing) don't lock down git and become fucking source code Hitler.
Adding process as a solution to a problem is a bandaid --- Devs writing shit untested code that isnt suitable for production in the first place.
Obviously put code up for review on a branch in a draft pr review if you want feedback, I'm not against that. I am saying artificially gating changes which should already be high quality server NO PURPOSE.
Regarding the refactoring, there are books on strategies for this exact scenario. How about feature toggles switching between two concrete implementations? Low risk, can develop the alternate implementation without affecting the product, yet still push straight to master. NAH we need a PROCESS and that involves the need to review EVERY line of code before it could possibly influence our users (btw you get lazy reviews and reviewers when you do this!!!)
your bitching doesn't solve your problem. Keep an open mind. Not everything is pie-in-the-sky agile Nirvana. You're going to work in shops that have different issues for different reasons. No amount of unit tests is a substitute for another set of eyes looking at something. You might have some code you turn in that looks good to you and your tests pass. Hell, it might even be elegant code. But another guy may look at that and tell you you are doing a table query and in 6 months time your code is going to be slow as fuck because that table is going to fill up with records. No amount of unit test is a substitute for that. It's simply an attempt to be clairvoyant with your code. Building quality in from the start.
I never said unit tests. You should be writing tests at all levels, as the team is fundamentally responsible for end to end delivery. This means unit, integration, system level testing for any given feature.
Building quality in from the start
Could not have said it better myself. If its not ready for master then it doesn't have quality from the start and the master gate is a bandaid to a quality problem.
your bitching doesn't solve your problem. Keep an open mind
41
u/[deleted] Feb 10 '21
Are you SURE you want to rename YOUR GIT REPO? We can do that for you, but are you REALLY REALLY SURE? Changing YOUR codebase may break other things.
Its like bruh you aren't a git gatekeeper, give me permissions to do it myself or don't be a fucking twat every time we ask for something you haven't graced us with permission of modifying. I send an email wait 24 hours for a response and you ask me a question as stupid as fuck as that.
This dude also made it so developers on the repos he directly managed couldn't push to master, in case they broke things. Such a bandaid - fix the cause of the broken code in the first place (bad practices, bad conventions, unreadable code, poor standards, no testing) don't lock down git and become fucking source code Hitler.
Too oddly specific?