Engineering Blog

A few months ago, I spent a couple of hours on and between plane rides reading Martin Fowler’s “Refactoring: Improving the Design of Existing Code”.  I thought it was really good so I thought I’d share some bullet points (page numbers in parenthesis).  It also has a huge catalog of various refactorings with examples.

• “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure” (xvi)
• If you need to refactor, do it before adding a feature, then add the feature (7)
• “Before you start refactoring, check that you have a solid suite of tests.  These tests must be self-checking.” (8)
• “Never be afraid to change the names of things to improve clarity” (15)
• “In most cases a method should be on the object whose data it uses” (17)
• “[Temporary variables] are often a problem in that they cause a lot of parameters to be passed around when they don’t have to be.  You can easily lose track of what they are there for.”  Use Replace Temp with Query refactoring. (21)
• “Don’t worry about [performance] while refactoring.”  After running a profiler you may need to optimize, but you’ll be in a better position to do it. (32)
• Refactoring to eliminate switch statements with enums: Replace Type Code with State/Strategy (39)
• “The rhythm of refactoring: test, small change, test, small change, test, small change” (52)
• Kent Beck’s two hats: adding function and refactoring.  “When you add function you shouldn’t be changing existing code; you are just adding new capabilities.  You can measure your progress by adding tests and getting the tests to work.  When you refactor, you make a point of not adding function; you only restructure the code.  You don’t add any tests (unless you find a case you missed earlier); you only change tests when you absolutely need to in order to cope with a change in an interface … always be aware of which hat you’re wearing.” (54)
• Don Roberts’ Rule of Three: “the first time you do something, you just do it.  Second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway.  The third time you do something similar, you refactor.” (58)
• What makes programs hard to modify: hard to read programs, programs with duplicate logic, programs that require additional behavior that requires you to change running code, programs with complex conditional logic (60)
• When not to refactor: if it’s easier to rewrite, current code has bugs, close to a deadline (66)
• Generate a plausible first shot at design, code, then refactor.  Refactoring changes the role of upfront design.  If you don’t refactor, there’s a lot of pressure in getting that upfront design right. (67)
• “Even if you know exactly what is going on in your system, measure performance, don’t speculate.  You’ll learn something, and nine times out of ten, it won’t be that you were right!” (69)
• “Whenever we feel the need to comment something, we write a method instead.  Such a method contains the code that was commented but is named after the intention of the code rather than how it does it.” (77)
• “Don’t forget to test that exceptions are raised when things are expected to go wrong” (100)
• “There is a point of diminishing returns with testing, and there is the danger that by trying to write too many tests, you become discouraged and end up not writing any” (101)
• Previously mentioned huge catalog of refactorings with examples
• When to stop refactoring: when you lose confidence in your next step.  If the code you’ve written makes the system better keep it otherwise trash it. (410)
• Refactor in pairs (411)
• “Refactoring first is less dangerous than adding new code.  Touching the code will remind you how it works” so that adding new code becomes easier/faster. (412)