Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Seen this several times when someone refactors. The code is much simpler and easier to read, but does not actually work for several important test cases anymore.

I've never thought of simplicity adding upfront cost. That's probably true, but also true that it pays dividends later on in the project.



If it no longer works then I don't consider that to be "refactoring" but "rewriting".

I think of refactoring as a series of SIMPLE transformations that clearly do not have any effect on the correctness (or incorrectness) of the code. That is, there is no possible change in behavior.

And think of the word "factoring" as in high school algebra. or rather "factoring out" something.

I have a dozen examples of this calculation. How about let's refactor it into a function, and replace all the instances with a function call?


> I think of refactoring as a series of SIMPLE transformations that clearly do not have any effect on the correctness (or incorrectness) of the code. That is, there is no possible change in behavior.

This kind of transformation is precisely what the person who coined the term meant: Taking code which works and turning it into easier-to-read code which works precisely as well, because refactoring never introduces a change in behavior.

To quote Martin Fowler and Kent Beck:

> A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs.

[snip]

Not a direct quote this time:

> Fixing any bugs that you find along the way is not refactoring. Optimization is not refactoring. Tightening up error handling and adding defensive code is not refactoring. Making the code more testable is not refactoring – although this may happen as the result of refactoring. All of these are good things to do. But they aren’t refactoring.

https://dzone.com/articles/what-refactoring-and-what-it-0


Simplicity is ALWAYS something desirable to achieve. Correctness comes first.

As code is originally written, people are (or should be) using the most "obviously" simple approach.

A Breakthrough in simplicity is often the result of additional thinking and hard work. (And cost)


Maybe the test cases / requirements are "wrong"? I think simplicity is the ultimate test that you found a good problem!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: