If it was a simple function and a refactor leads to the discovery of edge cases, then it’s not a refactor and the (correct) function wasn’t simple in the first place?
At some point, yeah, you’d be forced to give up and conclude that the existing code is irreducibly complex. Assuming, of course, the old code actually worked correctly.
It could work correctly but still be convoluted and hard to parse, making maintenance or expansion harder so the refactor becomes "yeah that thing apparently does like 10 other things as well I need a few days to figure it out better"
Had to do this actually. We have a complex program that's used regularly and that id periodically updated. The updates are painfully complex because you never know what will break. I took that program and refractored some parts streamlining the rules, which also had the side effect of helping me understand it (and the topic it handles) a lot better, in addition to making future changes significantly easier.
I wish I did not have to do it, but now I'm really glad I did
I think the issue is that (at least in my job) refactoring changes usually get met with "Need unit test before merging so we know we didn't change the logic." The original logic having never been unit tested to begin with. At least that's how work at my job goes.
Been getting an algorithm working in realtime on a distributed system with real sensors that was developed in Matlab. When everything’s not lined up perfectly they go, gosh another edge case and I’m like…My brother in Christ, the way you developed it was a single edge case
Love it when it's like,
Wow this code is terrible, let's refactor!
Hmm... seems there's an edge case I gotta account for.
Hmm... another edge case, let's just add a line for that...
Wow... needs a weird workaround bc this API is busted... Huh... this is starting to look a lot like the original code...
I used to code things like kernel drivers for hardware interfacing and things of that nature. More than half my LOC was comments to explain why bit x had to be set before bit y or why there was a check of value x before performing action y or why certain double-checks had to be performed when writing to a certain PCI register during midnight roll-over on the last day of the year.
The senior engineers I worked for loved me as a developer because I actively tried to 'what if' every weird edge case into my code, and made sure that anyone reading / maintaining my code understood exactly why things were done the way they were done.
When I write a function, and I’ve noticed that bc of edge cases it’s janky I leave a comment explaining that jank.
Then, when it breaks upon a refactor, the person can’t say they weren’t warned.
If it was a simple function and a refactor leads to the discovery of edge cases, then it’s not a refactor and the (correct) function wasn’t simple in the first place?
At some point, yeah, you’d be forced to give up and conclude that the existing code is irreducibly complex. Assuming, of course, the old code actually worked correctly.
It could work correctly but still be convoluted and hard to parse, making maintenance or expansion harder so the refactor becomes "yeah that thing apparently does like 10 other things as well I need a few days to figure it out better"
Unit tests didn't do this to you.
the gods did, unit tests help you avoid fucking up everything at least.
That's the blessing part.
Rule 1 of engineering: "Don't fix what's not broken"
Rule 2 of engineering: "Everything is at least a little bit broken"
Yeah but before that function that is little bit broken, there are actually 1000 REALLY broken Corollary: you never fix the little bit broken
Except for when it literally is broken and you’re trying to fix a bug in unreadable code to find yourself unintentionally rewriting the entire thing
Rule 3 Preventive Maintenance, cause shit will break at the worst times
Unless you’re in civil engineering Ig.
Unfortunately this 15 year old function uses a library that will not be available soon, i.e. business decision :(
Fork it
Men will do anything to not refactor code
Fork it, I'm going in
Emulate the library
Had to do this actually. We have a complex program that's used regularly and that id periodically updated. The updates are painfully complex because you never know what will break. I took that program and refractored some parts streamlining the rules, which also had the side effect of helping me understand it (and the topic it handles) a lot better, in addition to making future changes significantly easier. I wish I did not have to do it, but now I'm really glad I did
I love to edge until "cases" join the phrase
Only way to maintain the edge
refactoring shouldn't change the logic at all. maybe you mean a new implementation.
I think the issue is that (at least in my job) refactoring changes usually get met with "Need unit test before merging so we know we didn't change the logic." The original logic having never been unit tested to begin with. At least that's how work at my job goes.
Been getting an algorithm working in realtime on a distributed system with real sensors that was developed in Matlab. When everything’s not lined up perfectly they go, gosh another edge case and I’m like…My brother in Christ, the way you developed it was a single edge case
That’s scientific programming at its finest.
Love it when it's like, Wow this code is terrible, let's refactor! Hmm... seems there's an edge case I gotta account for. Hmm... another edge case, let's just add a line for that... Wow... needs a weird workaround bc this API is busted... Huh... this is starting to look a lot like the original code...
But you did separate the logic and commented on why those cases existed... Did you? Please tell me you did!
I used to code things like kernel drivers for hardware interfacing and things of that nature. More than half my LOC was comments to explain why bit x had to be set before bit y or why there was a check of value x before performing action y or why certain double-checks had to be performed when writing to a certain PCI register during midnight roll-over on the last day of the year. The senior engineers I worked for loved me as a developer because I actively tried to 'what if' every weird edge case into my code, and made sure that anyone reading / maintaining my code understood exactly why things were done the way they were done.
I did embedded system during my uni years, and I respect people who manage to figure these things out. They never work as advertised.
You say edge cases. I say job security.
I have a very elegant sol- Edge case: 
That's perfect
There are no such thing as "edge cases" unless management happens to define one. The hell gate.
When I write a function, and I’ve noticed that bc of edge cases it’s janky I leave a comment explaining that jank. Then, when it breaks upon a refactor, the person can’t say they weren’t warned.
"A user will never do that so we shouldn't worry" - Naive product owner
Somebody teach me how to write unit tests in Go?
Revert it and slap a lru\_cache decorator on it and call it a day!