3 ms·

Peeves about the items in the linked post: > 1. The change is not really a refactor Is anything ever really just a refactor, though? > 3. Another refactor is

Peeves about the items in the linked post: > 1. The change is not really a refactor Is anything ever really just a refactor, though? > 3. Another refactor is already in progress Ah, but - in large and poorly-maintained codebase, it is always the case that some refactoring is already in progress, likely stalled for weeks, months or years as priorities have shifted without it having been completed. > 4. The code is unlikely to change If the code is unlikely to change, there's a good chance you might want to refactor it out of your repository anyway, into some low-frequency-of-changing library. > There’s no benefit to improving code that never changes Oh, there are lots of benefits to improving code that never changes! And that's because other code _uses_ the code which never changes. And if originally the use is clunky, but you manage to improve it by your refactor, youve' done well indeed. > 5. There are no tests A repository which lacks test coverage is extremely likely to be in dire need of all kinds of refactoring. Waiting until someone (maybe even yourtself) writes tests for most code, before doing anything in the mean time - well, it basically means giving up on yourself. > we can start by writing some tests! Well, that's nice, but - if we do that, then no refactoring would get done, and we'll have to write code based on ugly and unweildy older code, which only adds stuff to refactor later. Plus, who's to say the tests don't fail _already_? :-(

Fishkins 2y ago
> Ah, but - in large and poorly-maintained codebase, it is always the case that some refactoring is already in progress, likely stalled for weeks, months or years as priorities have shifted without it having been completed. This is true, and something I also thought of when reading that point. I don't think it's necessarily a counterargument, though. It's probably a better idea to spend your time helping to complete the previous refactor instead of starting your new one. Codebases in which many refactorings are started but not completed can be worse than ones that aren't refactored at all. There could be exceptions if your new changes is very small, localized, and unlikely to interfere with the other changes going on.
- einpoklum 2y ago
  > It's probably a better idea to spend your time helping to complete > the previous refactor instead of starting your new one That is a fair suggestion - when practicable. Often, it isn't, because of the very reasons which made the old refactor stall in the first place, e.g.: * The target factor of the code was not such a good choice to begin with. * The code in question is critical and any change to it is discouraged or feared. * The code in question is the responsibility of different groups of developers / different departments, and they, or their managers, are not in the mood for collaboration. etc.
zingar 2y ago
Original author here :) > Is anything ever really just a refactor, though? I think you're making the point that very few worthwhile business goals could be achieved purely by refactoring. Which is true. Some part of the work will probably be the safe mechanical steps that make up refactoring ("replace conditional with method", "extract method" etc), and some part is "normal" "non-refactoring" change. The reason for this point is that I see developers avoid important conversations because they claim they're "just refactoring" and so they can safely make a change without involving anyone else. They're wrong unless they have a good handle on the difference between the two types of work. > it is always the case that some refactoring is already in progress When I've seen the "paused refactor" phenomenon, it isn't actually refactoring ... there's negotiation and consideration of trade-offs and impacts on various parties, because some important parts of the code need to actually do something different. But probably there are more cases in the world than I've personally seen. But really in this case I am thinking on the level of developers who will extract a method while at the same time changing the content of the code being replaced. Without running any tests, committing etc. The start and end of the one step is easily in their grasp, but they think they can save time by mixing two steps at once. > If the code is unlikely to change, there's a good chance you might want to refactor it out of your repository Interesting point. The cases that were in my head were more like unique things that wouldn't group together well with anything else. What kind of code do you typically move out of a repo? Would it be fair to say that in the case of extracting unchanging code, we're recognising that there is some difference between our intentions for the code that stays and the code that doesn't? And that by extracting it we're acting on a recognition that the intention has changed since we first wrote it? > other code _uses_ the code which never changes... And if originally the use is clunky, but you manage to improve it by your refactor Wouldn't this be more like changing my [previously] unchanging code to make it better fit the use cases of the client? > Waiting until someone (maybe even yourtself) writes tests for most code I wouldn't recommend writing tests for most of the code before any refactoring. There is certainly some small part that can be tested and then refactored while the rest stays untested and unchanged. Then on to the next test and refactor and so on. > who's to say the tests don't fail _already_? I guess I didn't mention this case explicitly, but I'd expect someone to fix the tests (or scrap the old and write _some_ new) and then get on with refactoring.

Fishkins 2y ago

> Ah, but - in large and poorly-maintained codebase, it is always the case that some refactoring is already in progress, likely stalled for weeks, months or years as priorities have shifted without it having been completed. This is true, and something I also thought of when reading that point. I don't think it's necessarily a counterargument, though. It's probably a better idea to spend your time helping to complete the previous refactor instead of starting your new one. Codebases in which many refactorings are started but not completed can be worse than ones that aren't refactored at all. There could be exceptions if your new changes is very small, localized, and unlikely to interfere with the other changes going on.

einpoklum 2y ago
> It's probably a better idea to spend your time helping to complete > the previous refactor instead of starting your new one That is a fair suggestion - when practicable. Often, it isn't, because of the very reasons which made the old refactor stall in the first place, e.g.: * The target factor of the code was not such a good choice to begin with. * The code in question is critical and any change to it is discouraged or feared. * The code in question is the responsibility of different groups of developers / different departments, and they, or their managers, are not in the mood for collaboration. etc.

zingar 2y ago

Original author here :) > Is anything ever really just a refactor, though? I think you're making the point that very few worthwhile business goals could be achieved purely by refactoring. Which is true. Some part of the work will probably be the safe mechanical steps that make up refactoring ("replace conditional with method", "extract method" etc), and some part is "normal" "non-refactoring" change. The reason for this point is that I see developers avoid important conversations because they claim they're "just refactoring" and so they can safely make a change without involving anyone else. They're wrong unless they have a good handle on the difference between the two types of work. > it is always the case that some refactoring is already in progress When I've seen the "paused refactor" phenomenon, it isn't actually refactoring ... there's negotiation and consideration of trade-offs and impacts on various parties, because some important parts of the code need to actually do something different. But probably there are more cases in the world than I've personally seen. But really in this case I am thinking on the level of developers who will extract a method while at the same time changing the content of the code being replaced. Without running any tests, committing etc. The start and end of the one step is easily in their grasp, but they think they can save time by mixing two steps at once. > If the code is unlikely to change, there's a good chance you might want to refactor it out of your repository Interesting point. The cases that were in my head were more like unique things that wouldn't group together well with anything else. What kind of code do you typically move out of a repo? Would it be fair to say that in the case of extracting unchanging code, we're recognising that there is some difference between our intentions for the code that stays and the code that doesn't? And that by extracting it we're acting on a recognition that the intention has changed since we first wrote it? > other code _uses_ the code which never changes... And if originally the use is clunky, but you manage to improve it by your refactor Wouldn't this be more like changing my [previously] unchanging code to make it better fit the use cases of the client? > Waiting until someone (maybe even yourtself) writes tests for most code I wouldn't recommend writing tests for most of the code before any refactoring. There is certainly some small part that can be tested and then refactored while the rest stays untested and unchanged. Then on to the next test and refactor and so on. > who's to say the tests don't fail _already_? I guess I didn't mention this case explicitly, but I'd expect someone to fix the tests (or scrap the old and write _some_ new) and then get on with refactoring.