siddharta.lists at gmail.com
Sun Dec 5 10:33:07 CET 2010
Refactoring just means changing the internals without adding/removing
functionality. The book is good, but refactoring can be applied in many
other contexts too. It has been happening long before the book came out. The
big insight in the book is not the refactoring patterns themselves. The big
insight is that its possible to make fairly large changes using small steps
where the application does not break at any of the intermediate steps. It
changes your thinking from I need to rewrite & retest to go from A -> B, now
its like how can I go there in small steps without breaking anything in the
Unless you plan to keep rewriting your app everything a change comes along,
I do agree that a self respecting developer needs to know refactoring (the
concept, not the book)
Refactoring myths -
- If I write perfect code the first time, then I don't need to refactor:
Wrong! Requirements change, and then your perfect code is no longer
suitable, so you'll have to go in and change the design before you can
implement new functionality. Thats refactoring.
- Refactoring means cleaning up bad code: Wrong! See above.
- Refactoring is only for OO code: Wrong! You can refactor anything, even
imperative of functional programs. I have used refactoring (including some
patterns from the book) on C programs.
- "I have not seen refactoring used on open source projects": Wrong! At
least on the django project refactoring occurs _very often_ to support new
functionality. When multiple database support was introduced, the ORM design
(which only supported single database) was refactored without changing
existing functionality. After that the multi-database feature was added.
Django has a policy of having unit tests for _all_ functionality, just to
support easy refactoring. I'm pretty sure it happens in all large projects.
- Refactoring is only for code. Wrong! We recently released a second product
which sits along with our first one, and it required completely changing the
architecture of the first one - we refactored the architecture to support
the new product over 3 months deploying small changes at a time.
Architecture changes, server configurations, database structure - everything
was changed making small changes every week on a running production system
with no downtime - thats refactoring too.
More information about the BangPypers