Refactoring

Tenets: SMALL, 1THING, PROTO, FILTER, 90cent

Central concept: Simplify, simplify.

The interest in refactoring these days is a formalization of what programmers, hackers, and other tinkerers love to do: twiddle with something to make it better. Its chief proponent is probably Martin Fowler, coauthor of the book Refactoring: Improving the Design of Existing Code. The fundamental idea behind all refactoring efforts is that it is possible to improve the internal structure of a software system without altering its external behavior.

One cool aspect of refactoring is that it helps you to realize that interfaces are important, perhaps more so than you may have understood them to be in the past. This is crucial when you're talking about a system consisting of a large number of small tools all playing well together. Unless you have defined solid interfaces between them, you end up with a large collection of totally random stuff with no rationale behind it. In other words, you have a mess.

Developers and other philosophers are writing volumes about design patterns and other techniques used in software refactoring today. Alas, people are finally writing about the processes that have been going on inside programmers' heads for years. This kind of analysis can only lead to a better understanding of what we do and a move towards improving what we do.

A common axiom of refactoring is that it should take place in small, incremental changes rather than large rewrites. Here the Unix philosophers and the refactorers share a common ground. Unix developers have worked in a small, incremental, iterative development style. However, like the difference between the XP methodology and the Unix philosophy, the Unix approach rests upon much common ground with the refactorers, yet departs from it in at least one aspect, that of the willingness to "throw stuff away." The refactorers rarely advocate total rewrites of anything. The Unix developers frequently build the First System, throw it away, and then build the Second System, knowing full well that this way is frequently the most expedient path to the Third System (i.e., the correct one). So the Unix developers are a bit bolder in this regard. Sometimes a system is so bad that the quickest way to software utopia is to take a different road altogether.

Many of the decisions one makes in refactoring are efforts to help the software conform to a particular design pattern or to invent a new design pattern if the situation doesn't fit any of the known ones in existence. All design patterns, no matter how eloquent, are simply supersets of the original design pattern; that is, every program is a filter. This is similar to the old adage, it's all ones and zeroes. The most complex numerical or logical system can always be reduced to a series of binary representations.

In refactoring, as one seeks the proper design pattern as a model for one's architecture, it is best then to remember that you probably don't fully understand a program's logical process until you can express it in the form of a filter with a single input and a single output. When you have arrived at that level of understanding, then you are ready to refactor.



Linux and the Unix Philosophy
Linux and the Unix Philosophy
ISBN: 1555582737
EAN: 2147483647
Year: 2005
Pages: 92
Authors: Mike Gancarz

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net