Code Refactoring

Code Refactoring



What Is Refactoring?



Refactoring is Waste




Why Not Make It Right First Time?









– Bob


[29 March 2015]



  1. dancres said:

    “Passes the same tests” is not a great yardstick – how many teams have a suit[e] of tests checking all “-ilities”?

    A suggested refactoring: suit becomes suite 😉 [Done, thanks – Ed)

    Nice write-up.

  2. Interesting. When we’re practising TDD with katas, a common practise when following the Red, Green Refactor, is at the green stage. We ask ourselves, how can we get to green with the simplest, least effort change. Maybe a line or so. If it’s too big a change it means we need to comment out that test and refactor ourselves into a position where it’s easy to make that change and get our new test to pass.

    Following this logic, our refactoring becomes more focussed, almost using triangulation as our motivation. We also have an end goal in sight or “when to stop”.

    Very thought provoking article. Thanks.

  3. johnicholas said:

    One perspective on refactoring is that refactoring is what programmers call algebraic manipulation, just like “line” means “a rope on a boat”.

    Algebraic manipulation is a form of thinking explictly. Thinking explicitly means using an external memory, like a piece of paper, as a cognitive aid; it’s very valuable for dealing with ideas that are too big to fit in your working memory. Sometimes this is chewing them (from external memory into chunks in long-term memory) until you can deal with them.

    Algebraic manipulation also consists of bouncing back and forth between pure formal manipulations (such as an application of distributive law) and informal, domain-specific interpretations. For example, a physicist might explain centrifugal force by writing down equations without centrifugal force, doing some manipulations, and then interpreting the result as describing a world with centrifugal force. The physicist translated informal language to formal language, performed domain-independent refactorings on it, then translated the formal language back to informal.

    Analogously, a programmer skilled in a particular idiom may be able to come to a particular problem domain, understand it partially, translate their partial understanding into formal code, manipulate the formal code using problem-domain-independent refactorings, and then interpret the resulting code as suggesting a different understanding of the original domain.

Leave a Reply


You are commenting using your account. Log Out / Change )

Twitter picture


Facebook photo


Google+ photo


Connecting to %s

%d bloggers like this: