Loose Notes on Refactoring

 

Note: I’ll possibly replace these thoughts and others with a coherent document when time permits such a thing to be a priority.

Intro

I’ll here be talking a little about refactoring by defining the terms, making a few observations, and addressing a few objections I have encountered to refactoring, its goals, or similarly-aimed methodologies. For a lot more and better info than the supplementary thoughts in these notes, visit http://www.refactoring.com. This is not intended as an introduction to refactoring, but as a set of notes that could supplement an introductory-level discussion of refactoring.

 

Definitions

Following Martin Fowler, Refactoring: Improving the Design of Existing Code:

Refactoring: (noun)  A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactor: (verb)  To restructure software by applying a series of refactorings without changing its observable behavior.


Observations

To make the software easier to understand and modify: Time spent coding does not have to be time spent "generating new functionality" to be time productively spent.

1. "How much more does my program do today?" is the natural way to think about progress in software development, as opposed to "Is what I've done today responsible for optimizing  development?" or "How much time am I going to spend tomorrow reinventing the wheel and debugging my own code?"

2. Coding is "90% debugging" -- bugs are more costly than lacking progress in functionality.

3. "How much functionality can I add within the hour?" is probably the way that most people code. "How much functionality can I add before the deadline?" is a better question.

 

A False Dichotomy: Add Functionality or Rewrite
Most, I would guess, consider two alternatives:

(1) Continue "updating" the functionality of an existing program, or

(2) If the current program seems unmaintainable, make a new program from scratch.

In both approaches, marginal development, rather than marginal development speed, is the focus.

 

Youthful Objections to Refactoring

Some of us new to the software development world would seem to reject the notion that thoughtful design has practical use at all:

"They'll just redo the program, because (1) the changes in code would tangle up so badly that it's easier to redo everything than to perform coding gymnastics on the existing code, and (2) time spent on design is time wasted that could be spent making it do more, and (3) nobody actually DOES it in practice"

Thoughts on objections:
(1) Often the very reason that software changes DO tangle the code up badly is because the code was poorly designed. Sometimes improving the design of the software on the fly reduces this burden.

(2) Again, maximizing development speed across each subinterval of time does not imply that average development speed is maximized over the entire interval.
(3) Perhaps few people do it in practice, but largely out of (a) lack of stellar CS education and (b) the novelty of the enterprise. Software engineering is projected to be the fastest growing job in the US over the next ten years in the U.S.

Additionally,

(4) The claim is that "refactoring is useful," not that "refactoring is always useful." Sometimes problems are so naturally laden with complex interdependencies that make the current code useless towards the development of the next. In other situations, design changes facilitate development. When this is the case is a matter situational judgment. Sweeping generalities don't work here: there is no "golden hammer" that solves every problem in CS. Refactoring is but one of many tricks in the bag, and often inappropriate to a given problem.

(5) There is a saying: "Anyone who writes reusable code doesn't know the meaning of job security." In other words: "I can use bad design to inflate my costs and screw over my managers." Managers who are already thwarting the possibility such attempts are doing well.

In summary, seeing the utility of refactoring involves losing one’s sense of functionality-lust, and overcoming some objections to refactoring that may come along with being green to the methodology. For more info, see http://www.refactoring.com.