Refactoring Inhibitors

With the notion of using simple, incremental design as your primary design driver, the refactoring step is where much of the real work gets done. Anything that keeps you from refactoring easily, or even from wanting to refactor, is bad. Very bad. When you stop refactoring incrementally, your system will start degrading quickly.

Be on guard for the following inhibitors to refactoring:

• Insufficient tests: Following TDD provides you with fast tests for every small bit of discrete logic you build into your system. These tests provide you with high confidence to change the code for the better. In contrast, when you have fewer fast unit tests and thus lower test coverage, your interest and ability to refactor shrinks dramatically. Your approach to coding becomes fear-based: “If it ain’t broke, don’t fix it!” You may well know that the right thing to do, for example, is to factor common code into a helper function. But you don’t, because those changes involve touching other code—not “yours”—that’s already working.

• Long-lived branches: Anyone who’s had to merge code from a separate branch with lots of activity knows that extensive refactoring makes for merge hell. Developers working on a branch may be asked to minimize the scope of their changes. Doing so might make merges easier but will also make the source base suffer forever. If you must sustain branches over long periods of time, seek to continually integrate from mainline. Otherwise, avoid long-lived branches.

• Implementation-specific tests: When test-driving, you specify the behavior of a class through its public interface. By definition, refactoring is changing design without changing externally recognized (public) behavior. Tests that have an awareness of what would otherwise be private details run the risk of breaking when those private details change. You want the ability to change the underlying structure of your code as needed, extracting or inlining methods at will.

  Heavy mocking or stubbing of collaborators can expose information to tests that otherwise would remain private. Done judiciously, using test doubles won’t cause problems. With careless use of test doubles, however, you may find yourself breaking lots of tests when you want to refactor your code. That’s a good enough reason for many developers to not want to bother refactoring.

• Crushing technical debt: The sheer volume of difficult code may be enough to cause many developers to give up. “Where do I start?” The worse you let your code get, the harder it will be to do anything about it. Make sure you always take advantage of the refactoring step.

• No know-how: Anything you don’t know can and will be used against you. You probably know a bit about design, and you learned about simple design in this chapter, but learn more. If you don’t have a solid grounding in design, odds are you won’t refactor enough.

• Premature performance obsession: Many of the ideas promoted in this book about design center around small classes and functions, which incurs the overhead of creating additional objects and calling extra methods. Many developers resist such changes and are content with longer functions and classes.

  Ensure you first create a clean, maintainable design. Profile the proper design to determine whether it exhibits performance deficiencies. Optimize the code only if absolutely necessary. Most optimizations increase the difficulty of understanding and maintaining the code.

• Management metric mandates: If their standing in the company or considerable money (in the form of salaries or bonuses) is tied to specific goals, smart employees will do whatever it takes to meet the goal. If the goal is represented by a singular metric, chances are that sharp developers will find a way to more easily achieve that number, whether or not doing so serves the real business need.

  As an example, consider the defect density metric, defined as defects per kilo lines of code (KLOC). (Note: You can also capture defect density as defects per function point, but the effort to calculate function points is not trivial. Most shops go with the simpler measure, defects/KLOC.) If your manager heavily emphasizes shrinking defect density, the team will react accordingly. Ensuring the code exhibits fewer defects is harder than “gaming” the metric. The easier route is to increase the lines of code.

  Perhaps you believe most programmers aren’t that devious. Perhaps not. But when you ask them to factor two near-duplicate 1,000+ line functions into a single function, they’re thinking about the loss of a KLOC and the accordant increase in defect density. Good luck convincing them that eliminating the duplication is important.

• Short-sighted infatuation with speed: “Just ship it. Stop spending time on refactoring.” Can you blame a project manager for not understanding the importance of keeping your system’s design clean? Sure, it might look like you’re speedy for a while, but you’ll eventually suffer dramatically (sometimes devastatingly) for letting your system’s quality slide.

  Just say no, and otherwise keep your refactoring to yourself. Work to keep your code clean every few minutes as part of the TDD cycle. If asked, you can say “This is how I work as a responsible professional.”

  You must take advantage of the opportunity that each passing test provides you; otherwise, code cruft will build up quickly and begin to slow the rate of development. You might even feel compelled to ask for a refactoring iteration. Don’t! Nontechnical folks have no idea what refactoring is. They will simply translate your request as “The programmers just want to play around with the software, and I won’t get any business value this iteration.”

  Unfortunately, no matter how hard you try, you will inevitably have iterations where a new feature doesn’t fit easily into the code, causing you to deliver the feature later than expected. When this occurs, ask for forgiveness, and run an honest investigation into how you might have prevented the additional effort. Don’t let it happen habitually.