Yes, I think that's the whole point.
> Some of the tips are even quite dangerous and highly context dependent, like creating a base class when two classes share common functionality. That sounds like a refactoring nightmare to happen.
I don't see where that hypothetical danger lies. Deduplicating code is a basic refactorizarion step.
> I’m currently working through a difficult refactor and the most important tips I can give are:
I'm afraid you're going the wrong way about this. No wonder you associated "danger" with refactoring.
The basic steps you take to refactor legacy code are:
- identify code paths that are affected if you touch a specific component,
- identify invariants and expected state changes through that code path. If there is none, add your own (see code seams)
- add tests to verify those invariants (see software vise tests)
- proceed with refactoring.
If you want to learn more, I recommend you pick up the book "working effectively with legacy code" by Michael C Feathers.
Deduplication is one thing and fine, but creating inheritance hierarchies should not be used for simple code reuse, but for representing relationships.
Yeah, I am a pretty big fan of inheritance, but that makes me cringe. Don't do this unless you understand the semantics of the class, and even then probably don't.
I’m currently working through a difficult refactor and the most important tips I can give are:
- test everything after each change,
- make (very) small adjustments.
- Use version control.
- sometimes make large sweeping adjustments, copy the main logic of it to a scratch file and then create small commits that bring you to that larger change.
- don’t be afraid to reset to your last “checkpoint”, sometimes you just go a wrong direction / overengineer something. Just throw it away and use it as additional guidance to build the right thing.