3 ms·

Some duplicated code is okay, but duplicated math code seems more risky than duplicated CRUD code or other business logic. Math code/functions seem easier to un

Some duplicated code is okay, but duplicated math code seems more risky than duplicated CRUD code or other business logic. Math code/functions seem easier to unit test to me, deal with much simpler data types, and are a great use case for unit tests unlike CRUD code. CRUD and business logic often has dependencies that must be mocked too and math functions can likely be pure. Math code also seems way more amenable to being consumed as passed-in functions that are consumed as a black box, then those things call the math functions and get the result, and really don't care how the math was done. But it's then good to signal (debug logging) what math function was passed in and why. Here, you can have OvalSpecialCaseMathFunction() along side the regular ones too. I'm probably falling into the same pit as the author here, but it doesn't seem like duplicating every "kind" of code has the same cost/benefit.

tinco 5y ago
Same here, baffled at that everyone's just taking the boss's judgement as gospel. Provided that he tested his refactor well, as his colleague I would be stoked someone went and cleaned up my code. It's not just about reducing lines of code and increasing abstraction, which I agree are bad metrics. It's about legibility. He took a block of 140 lines of dense math descriptions of objects, and reduced it to nicely structured semantic code. It's a 100% improvement, if that code has a bug, anyone could read it and find it. The author said they would later need support for different behaviour that would have made his code more convoluted. Well big deal, it's not like there was a way to do it without violating open/closed anyway. This code is so easy to understand, anyone can read it and go "ah this won't work with the new requirements, let's delete it and start over". Not saying this code 100% needed to be refactored, but if you're an engineer and you see it and you think you have some spare energy to pretty up a piece of the codebase, and you diligently test and verify your implementation, why not do it? I wish my team would do this more often.

tinco 5y ago

Same here, baffled at that everyone's just taking the boss's judgement as gospel. Provided that he tested his refactor well, as his colleague I would be stoked someone went and cleaned up my code. It's not just about reducing lines of code and increasing abstraction, which I agree are bad metrics. It's about legibility. He took a block of 140 lines of dense math descriptions of objects, and reduced it to nicely structured semantic code. It's a 100% improvement, if that code has a bug, anyone could read it and find it. The author said they would later need support for different behaviour that would have made his code more convoluted. Well big deal, it's not like there was a way to do it without violating open/closed anyway. This code is so easy to understand, anyone can read it and go "ah this won't work with the new requirements, let's delete it and start over". Not saying this code 100% needed to be refactored, but if you're an engineer and you see it and you think you have some spare energy to pretty up a piece of the codebase, and you diligently test and verify your implementation, why not do it? I wish my team would do this more often.