The power of preparatory refactoring - Martin Fowler

#refactoring #martinfowler #cleancode #evolutionarydesign #waterfall #tdd

In this video, Martin Fowler the author of the book Refactoring speaks on the power of preparatory refactoring before the addition of a new feature and why an evolutionary software approach can lead to less frustration for developers in the moments they find better solutions to already solved problems. Thoughts?

[wknight]

I always tell my team that a PR should contain at least 2 commits: 1 to implement your feature or fix your bug, and 1 to clean. It doesn't usually matter to me which order they happen in. You can refactor first, in order to make your feature easier to implement. Or you can refactor last, and make it look like your feature was always part of the design. So many inexperienced and middling coders are content to just stuff another if/else block in an existing method, and when you add these up over time you end up with garbage unmaintainable code.

[magnusmalmborn]

It's also easier on the reviewers to have two changes, one that just reorganizes the code but keeps the function, and one that changes the functionality in hopefully concise ways.

[arnthorsnaer]

Incredibly good advice which I’ve practiced for years and has resulted in healthy and malleable codebases and a fearlessness towards them. The refactoring is not a sign of some bad decision in the past, it’s a sign of an healthy codebase. A codebase which can no longer be refactored is emblematic of fear and stagnation.

[gauravdubey]

Spent the last week doing this. It behaves exactly the same — but now we can actually add new features!

[auxmobile]

This is actually what causes the evolution of programming languages. If we hadn't addressed that need for 'preparatory refactoring' in a more systemic way, we would still be writing programs in machine code.

[StefanErwinBaumer]

I read the title as "predatory" refactoring and the concept presented is a lot less exciting than I had hoped for, though still great advice

[javastream]

It depends. But overall refactoring produce massive gains in the majority of the cases.

In the minority you end up in a disaster or over-engineering.

Developer with 20+ years here.

[InconspicuousChap]

There is an old principle "Design before you implement". By trying to put a stake in the ground before anyone else does the business has transformed IT into a sloppy coding factory, working in continuous rush (stupid sprints and such) and never having time to think. Now the world has billions lines of shitty software, and the whole competition has been reduced to who produces the most shit in a given amount of time.