Refactoring : Improving the Design of Existing Code

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. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.

If you want to actually do refactoring, read the first four chapters completely. Then skip-read the catalog. Read enough of the catalog to know roughly what is in there. You don’t have to understand all the details. When you actually need to carry out a refactoring, read the refactoring in detail and use it to help you. The catalog is a reference section, so you probably won’t want to read it in one go. You should also read the guest chapters, especially Chapter 15.

• Refactoring
  • When you find you have to add a feature to a program, and the program’s code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.
  • Before you start refactoring, check that you have a solid suite of tests. These tests must be self-checking.
  • Refactoring changes the programs in small steps. If you make a mistake, it is easy to find the bug.
  • Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
  • Only changes made to make the software easier to understand are refactorings.
  • The Rule of Three: Three strikes and you refactor.
  • Don’t publish interfaces prematurely. Modify your code ownership policies to smooth refactoring.
• Bad Smells in Code
  • Duplicated Code
  • Long Method: you should be much more aggressive about decomposing methods
  • Large Class: When a class is trying to do too much, it often shows up as too many instance variables.
  • Long Parameter List
  • Divergent Change: when one class is commonly changed in different ways for different reasons
  • Shotgun Surgery: Divergent change is one class that suffers many kinds of changes, and shotgun surgery is one change that alters many classes.
  • Feature Envy
  • Data Clumps
  • Primitive Obsession
  • Switch Statements: The object-oriented notion of polymorphism gives you an elegant way to deal with this problem
  • Parallel Inheritance Hierarchies: every time you make a subclass of one class, you also have to make a subclass of another
  • Lazy Class: A class that isn’t doing enough to pay for itself should be eliminated
  • Speculative Generality: Speculative generality can be spotted when the only users of a method or class are test cases
  • Temporary Field
  • Message Chains
  • Middle Man
  • Inappropriate Intimacy
  • Alternative Classes with Different Interfaces
  • Incomplete Library Class
  • Data Class: classes that have fields, getting and setting methods for the fields, and nothing else
  • Refused Bequest
  • Comments: When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.
• Building Tests
  • Make sure all tests are fully automatic and that they check their own results.
  • A suite of tests is a powerful bug detector that decapitates the time it takes to find bugs.
  • Run your tests frequently. Localize tests whenever you compile—every test at least every day.
  • When you get a bug report, start by writing a unit test that exposes the bug.
  • It is better to write and run incomplete tests than not to run complete tests.
  • The key is to test the areas that you are most worried about going wrong.
  • Think of the boundary conditions under which things might go wrong and concentrate your tests there.
  • Don’t forget to test that exceptions are raised when things are expected to go wrong.
  • Don’t let the fear that testing can’t catch all bugs stop you from writing the tests that will catch most bugs.
• Putting It All Together
  • Get used to picking a goal: Somewhere your code smells bad. Resolve to get rid of the problem. Then march toward that goal.
  • Stop when you are unsure: Stop. If the code is already better, go ahead and release your progress. If it isn’t, throw away your changes.
  • Backtrack: If you have refactored for an hour, it will take only about ten minutes to replay what you did.
  • Duets: There are many advantages to working in pairs for all kinds of development
  • A big refactoring is a recipe for disaster.
  • When you are going to add some new functionality to an area, take a few minutes to clean it up first.