Like commented out or just dead ends of live code?
> Why do you keep shit that might unleash complete havoc cause it hasn't been touched since years and noone knows id it still works?
That happens when you don't write test (we don't do that here; no idea why). It's the fear to brick ancient depends.
Story time: I once refactored old af code and everything seemed to work fine at first. Unfortunately, I fucked an unused internal API, causing issues later on when someone used it.
Did I introduce a bug in the core? No, but I did change some logic. I largely refactored small "findX" methods which basically, instead of returning null if it doesn't find anything, returned a new object based on the search input. This obviously invited a "Test the application manually and fix NullPointerExceptions on demand" situation.
Truly a shit show.
@ApparentlyHuman That is imho the weakest argument....
If it get's ripped out and things start to break, you can at least pinpoint where and why.
That's better than the very dangerous illusion that it might be unused but still functional.
Especially in your case, changing is API breakage. I'm talking about removing.
Two very fundamental different things.
Beeing doing the same for the last week. Also a massive code reduction, around 50%.
@IntrusionCM I'll admit I have left some commented out code here or there at times 'just in case' something goes wrong / I replaced that code and all hell breaks loose the next day or something and I want to put it back in...
But .... yeah that hardly ever happens so I sorta quit doing that after a while.
@N00bPancakes If it's a line of code or a block of code and the ticket doesn't get closed before the removal... I'm fine with it.
It's just this annoying behaviour that people use a mothertugging VCS...
Except for the most obvious and Most important function: to revert accidential code changes. If it isn't used, remove the tons of lines of codes, let the motherfugging frigging static code analyzers and test suites do their fairy glitter magic and if it really breaks later, revert the changes necessary from the god damn VCS.
@IntrusionCM fair point, but it's not always that easy. In my case, it silently crashed without an error in sight. The developer had to play the old "guess where it is" game across several components, each written in different languages (yes—glued together in one project), whilst questioning whether the JVM is the one silently crashing (niche field; don't ask). Not gonna lie, I still feel sorry for him. Poor guy debugged that beast of a project.
> For fucks sake. Clean up and remove shit when it's not necessary anymore.
"YoU cAn'T, tHeRe Is No BuDgEt fOr tHaT." I know we have a few projects at the company that are complete shitshows, but I can't refactor 'em because it wouldn't make us money.
> Like "let's implement monitoring without having any clue about how monitoring works and even less clues about how TCP/ HTTP works."
You'd be surprised how often you have to do shit waaay outside your comfort zone. We had this freelancer who was OK, but he believed async/await is for multithreading, and thus never used it for offloading the CPU while waiting for PLC feedback. Yes. the code is full of while(true) loops.
> Stop. Doing. Stupid. Things.
You'd have to realize first that you're doing stupid shit.
ltlian18356dI'm still surprised at how often I see experienced devs remove code by commenting it out and committing, in case we need it again later.
If only there were versioning tools for this. "It's hard to find"NOT IF YOu wrote proper commit messages~
We're not talking about refactoring.
We're talking about removal of APIs and not fully removing all code parts after the API removal.
Refactoring != Removal.
And the second part... Of course you need to know that it's shit. Which you can't when you don't question yourself.
Your example makes this obvious... How could he not ask your team and why has your team not helped him?
The longer this rant gets the more I'm getting angry.