On Re-* (Rearchitecting, Restructuring, Refactoring and Rewritting)

Sometimes, the eagerness for adopting new terms in technical conversations or blog entries like this, provokes misconceptions around not so new terms and ideas. Recently, I've read an article on InfoQ called Refactor or Rewrite? that has caught my attention. And now, I want to write about those terms: Refactor and Rewrite. But, let's add also two other Re-* terms to this mix: Rearchitect and Restructure.

On Rearchitecting (vs Restructuring) vs Refactoring
In his short bliki entry Refactoring Malapropism, Martin Fowler discusses about how sometimes the "refactoring" term is used when is not appropriate. In particular is discussed the confusion with the term "restructuring". As it is shown in his book Refactoring: Improving the Design of Existing Code, a refactoring task on a particular bunch of code implies appliying a specific tecnique/s for doing small behaviour-preserving transformations on that source code. The key point here are the words "specific technique/s" and "small", that qualify the transformations described in the core chapters of the book. To me, restructuring means something bigger and abstract. Something that does not only imply transform a particular piece of code, but to re-arrange the components that define the architecture of the system. Rearchitect/Restructure a system implies to apply coarse-grained transformations, as for example, the so-called architectural patterns (See the POSA books). That's why to me the term "restructuring" a system is equivalent to "rearchitecting" that system (and I prefer the term rearchitect).

On Refactoring vs Rewriting
And what about refactoring and rewriting? To me, rewritting has to do with code readability and clarity in two dimensions related to the (art) of implementing code: adequate selection and combination of control structures and proper selection of class names, attribute names, relationships and method names. With regard to the control structures, I consider rewriting only in the context of a single method internals to improve readablity (e.g. rewriting a loop). Out of this scope, I consider it refactoring. Three interesting books that deal with rewriting and best practices when implementing code are the classical McConnell's Code Complete, Kent Beck's Implementation Patterns and Robert Martin's Clean Code.

I tend to separate modifications in the structure of the system (rearchitecting/restructuring and refactoring) from the internals of a method (that imply rewriting). Some people can ague that you can refactor the structure of some piece of code and at the same time you rewrite the identifiers of attributes, operations and parameters if required. In fact, in IDEs such as Eclipse or IntelliJ, you can find in the refactoring actions a "rename" entry. However, even with the help of IDEs, rewriting can introduce the risk of introducing bugs. Refactoring is also error prone if you don't follow the rules. So, it is better not to have two sources of errors at the same time.

To Conclude With...
So, we can categorize these activities in three layers: rearchitecting/restructuring (the most conceptually abstract at the top), refactoring and rewritting. Whether it is better to start performing architectural modifications on a system top-down or botton-up in this layered categorization is a different question. Sometimes, before making a refactoring it is better to do a rewriting. Sometimes in order to perform a refactoring it is better to rearchitect the system first. And, sometimes, of course, the other way around is preferable ;-) Of course, in the end this should depend on the arrangements made to face off the modifications on the system, that depend on variables such as the experience of the team members, number of dependencies between modules, current quality of the source code...

Have I missed another important Re-* term? ;-) If you want to continue exploring the Re-* world, another interesting blog entry can be found at Refactoring @ Scale.

An interesting reflection about why not to rewrite projects from scratch and in favour of applying re-* techniques can be found in Joel on Software.