WhatIsReworking

MeatballWiki | RecentChanges | Random Page | Indices | Categories

The above taken from Wiki:WhatIsReworking; the author of all the following text is SunirShah and he grants permission to MeatBall to copy the material.

Reworking is what school children might call, "Do over!" It means, quite simply, redoing some work done previously. On this site it has two main usages:

1. Reworking writing.

As explained briefly on Wiki:WhatIsRefactoring, it is possible to refactor the semantics (denotative meaning) of a work. However, natural language isn't limited to semantics (or functionalism). It contains connotative meaning as well, normally called style (e.g. rhetoric). The style of a work comes from the structure of the writing, the relationship of the words. It is strictly not possible to refactor a piece of writing and preserve the style.

Consider the difference between, "Quickly, John ran to Jane." and "John ran quickly to Jane." Functionally the two sentences are equivalent, but stylistically they are quite different. The first sentence emphasizes the speed at which John ran whereas the second (more weakly) emphasizes the characters in the narrative.

But more practically, refactoring text is really rare (although it is possible say by moving a section of discussion to a separate page on a wiki). Reworking is much more common. Restating what was said, removing what's not interesting, explaining points in further detail.

So, when someone says they are refactoring a page, they are more likely to be reworking it so it reads better.

A big goal when reworking is to preserve the relationship of the work under revision to other works in the system. Thus, when reworking a page on a wiki, one doesn't want to have to adjust the relationships it has to other pages. (This could be false if the discussion becomes meta, but we'll ignore those cases because they are self-defeating anyway.)

Think about renovating a basement bathroom in the house. A good contractor can do the job without changing the upstairs bedrooms. A really good contractor may not even affect the surrounding rooms.

2. Reworking code.

Typically, this is done in order to improve the system, say by cleaning up code or by optimizing. With respect to cleaning up code, reworking fits on the spectrum between Wiki:CowboyCoding and Wiki:DesignByContract from refactoring to a little bit towards Wiki:CowboyCoding. Strictly speaking, refactoring is a special case of reworking (see below, Wiki:WhatIsRefactoring).

Refactoring is good when you want to guarantee functional equivalence. Say when you are confident in how a subsystem works but not how it is written. Strict refactoring prevents additional bugs from being introduced. On the other hand, it preserves existing bugs.

The looser version of reworking is to just rewrite it to improve the quality. Really, this almost assumes that the programmer is perfect (ala Wiki:CowboyCoder), and thus won't introduce bugs. But it's also limited in scope, thus reducing the amount complexity that the programmer has to worry about. So, by virtue of its increased flexibility, it has the potential to be more optimal than refactoring, even if refactoring is guaranteed to work. People who can afford to trade defects for time to market may appreciate this approach. Or those who understand the solution (and how to write it) well enough that any bugs introduced will be easy to detect. How that's done is another issue, of course. It could be false, too, as happens whenever one moves out of guarantees into the riskier world of contingent flexibility.

Another question is at what level do we want to guarantee functional equivalence. If you consider the system to be an onion of interfaces (not really true in many cases, but let's pretend), then you can select one layer and lock that down with Wiki:RegressionTests. Anything beneath that you can rework without maintaining equivalence to corresponding units in the previous revision of the system. This once again balances flexibility against scope. While this may seem like refactoring, strict refactoring would preserve equivalence down to the atomic units in the system as well.

One thing that reworking can do, as well, is remove defects or add features. This can be easy to do even by cleaning up code. It may be difficult to preserve a defect from one revision to the next, especially one that you weren't necessarily aware of. Or it may be more elegant to add functional points. If you believe in complete Wiki:RegressionTests, you have to be mindful of that latter case. It's possible to make all the Wiki:RegressionTests pass while ending up with a superset of features; thus, you have to write new tests for anything you've consciously decided to add or anything that emerges from the system and gets used.

Theoretic mumblings.

Fundamentally, we can view all linguistic systems as a graph G = (V,E). Each functional (logical) point can be represented as a vertex. Refactoring transforms G to G' = (V,E'), where E' does not equal E. Reworking transforms G to G' = (V',E') where G' does not equal G, but V' may or may not equal V and E' is not equal E. Clearly, refactoring is a special case of reworking when V' = V.

However, if G was abstracted as a node in a metagraph H, a good reworking on G will make a commensurate transformation on H to H. That is, H shouldn't change.

: I don't get the last bit. What is a metagraph, and how could it be possible to modify only G and yet change the structure of the metagraph (i.e. isn't the last bit a tautology?)

: Also, I note that I use the term "reworking" to mean any kind of editing of a page. I try to use it instead of "refactoring" because "refactor" is jargon.

: -- BayleShanks

CategoryReworking

WhatIsReworking

Discussion