Refactoring Wiki Isa Metaphor

If refactoring by definition includes equivalence then is "refactoring" in regard to WikiPages only meant as a metaphor? Is it strictly speaking impossible to refactor text?

Rhetoric and Flow

First, you're right it is only a metaphor/loose analogy for how to deal with WikiPages. It can only inform, not instruct. See RavioliWiki where I took the analogy of wiki names :: class names.

However, it is not impossible to refactor text, provided you are only aiming to preserve meaning. Rhetoric is metainformation and will be lost. For instance, this sentence can be refactored. How? As, "This sentence can be refactored for instance." The two sentences have different rhythms and so will change the flow of the text. Extending this idea, though, you can move paragraphs of text around, change topic headings, delete rhetorical fluff, etc. Note that rhetoric is considered meaningless here (although it isn't really).

See WhatIsRefactoring, WhatIsReworking.

Editing as a form of Refactoring

An editor in the RealWorld (say of a newspaper), has the primary responsibilities of improving without changing meaning. This is often accomplished by improving grammar and spelling, reorganizing, etc. However this is not followed in practice because people try to improve and change meaning for the better. -- SunirShah

Proving (Testing?) equivalence in Refactoring

It seems to me that there is an important distinction between refactoring in contexts in which success is "provable" (I'll let alone possible) - mathematics, code - and those in which it is not - text, Wikis, architecture. This distinction doesn't keep me from doing something that people might call refactoring on these Wiki pages. I guess the distinction is that there is no logical proof to end any dispute as to whether whatever I did was pure refactoring. -- JohnAbbe

Actually, anyone who says you can prove equivalence with all code is lying to you. It has to do with that rhetoric thing again. There is functional equivalence, but that is really the most boring kind of equivalence. Consider functionally equivalent GUIs. A random arrangement of widgets is certainly functionally equivalent to those same widgets arranged in a nice, consistent, balanced fashion, but semantically they are lightyears apart. But, we've known for a long time that regression testing GUIs requires humans.

A better example of how UnitTests aren't sufficient. Given a nice data model class, you write a nice UnitTest suite for it. Then you proceed to muck about with it internally. In the midst of doing so, you introduce a resource leak. However, the system is still functionally identical to the previous state from an input/output point of view (at least from the interface-centric UnitTest point of view). The bug won't be caught, especially if the system provides no reflective calls to determine the state of the resource in question. -- SunirShah

Hmm. I admit all the examples I had been thinking of were of deeper bits of code being refactored to be more efficient or more cleanly designed but with the same API (funny, given how much of the programming I did was interface). Once you get to the user interface, I think you're right. So I guess RefactoringCodeIsaMetaphor? as well? OnlyMathIsPure?? -- JohnAbbe

How important is it to "preserve meaning"?

When I was an editor in the real world, I didn't think much about the edits that simply preserved meaning. Yes, you always did those at the very end, but those were the least interesting edits. The most interesting edits where the ones where I told the writer "You haven't answered this question, so can I see a rewrite in a few hours?" (I was a pretty difficult editor, but a number of people have told me that I taught them an awful lot about writing. After all, writing and editing is a learning process. A poorly structured essay hides its deepest flaws behind its most superficial ones; take care of the superficial ones and it's easier to see where you really need more work.

Regrouping as a easy first step

Wiki refactoring can work the same way; if you take care of the low-hanging fruit (regrouping is the easiest), then it's easier to see where the discussion still needs work. What parts of the discussion are undeveloped? What possibilities have been ignored? Where are people talking at each other but not reaching any common ground? It is also useful to use the metaphor used in code-refactoring. In code, the refactoring out the easy stuff exposes the difficult decisions, making it easier for you to make them. ExtractMethod a few times and it may help you realize you need to ExtractClass. MoveMethod a few times and it may give you a clearer idea of what a new, embryonic class wants to be.

UnitTesting and WikiPages

What in the "refactoring Wiki" metaphor corresponds to unit tests?

I wonder whether before we start a Wiki refactoring we could try to express the essential behaviour of the page which we want to preserve. By "we" I suppose I mean each party should do it individually. By "behaviour" I mean a list of the points that the final page should still convey. This list is not the refactoring; its an intermediate step. As such it does not need good English or persuasive rhetoric. It will describe the post-condition of the page without getting into how that post-condition is achieved. Someone clever can then refactor the page using the list of points as a measure of how well they have done. This may not work in practical terms, since it would create too much extra work and verbosity, and we would argue about (and in) the "tests" themselves until they became as bad as the page. Where is this worth trying?

The Reader's part in Testing WikiPages

Perhaps the unit tests are the readers. If someone sees before and after versions of a page and doesn't feel that the refactoring is valid, they complain - the test fails. If these are unit tests, it's not clear what the acceptance tests are.

Motivation In Refactoring

The problem with page refactoring is a motivational one. Someone with a strong motive to refactor a page probably wants to control the outcome too much to do a clean refactor. Someone with very weak motive to refactor could do a better job, but they lack the inclination, for the most part. Can we think of a way to find a middle? Fairness and yet energy? For a community that likes to talk about refactoring so much, we don't seem to like to do it anywhere near so much. Here's another example of the hyper/hypo-interest dilemma: "This page direly needs refactoring, but we'd better wait until the thread mess dies down." Then once that happens, who cares anymore? -- WaldenMathews

CategoryWikiMaintenance CategoryWikiRefactoring CategorySpeculativeStatement CategoryMetaphor