19 Sep 2012, 15:10

Andrew Hunt (75 posts)

I’m amazed at some folks resistance to this idea. Before widespread adoption of unit tests, refactoring was dangerous at best. But with the standard safety net of version control, automated build processes and unit tests, done correctly, there’s little immediate risk of breaking existing code.

But there’s still fear. Someone recently told me, “we don’t want to open up the whole system to potential redesign every time we fix a small bug!” Because that slim potential exists, therefore we will not refactor anything, ever.

This of course, violates one of the chief tenets of agile methods: take small bites. Nothing should be a big production number; if a large redesign is indicated, try and approach it in small, incremental steps.

Putting off small problems tends to fertilize them so that they grow into nice, large, healthy problems.

What do you think?

29 Apr 2013, 09:53

Richard Griffiths (1 post)

I think yours was the first or second book I read on coding! Along with Code Complete 2 :).

I enjoy mini refactoring - of a function, data structure, class structure.

Seeing it become tighter, cleaner, fewer special cases or dependencies is very satisfying if it goes right. Recently I was able, in a few minutes, change our reports program to no longer require the db to be passed as a trampy fifth parameter (in a list of about 8).

So resistance to refactoring doesn’t make that much sense to me; on the other hand, I’ve not been programming for long so maybe I just haven’t had time to grow “resistance” :).

  You must be logged in to comment