ReFactoring, supposedly "improving the design of existing code", is to design what walking is to mapping. When you take a walk, you might see a pretty bird on a tree and offer it some corn. Or you might step in dog droppings and whip out a plastic bag to clean them up. You might start a riot, kiss a girl, or perform many of the important observation and maintenance tasks explained by DoctorSeuss on Mulberry St. In other words, in Refactoring you've honed your work, communicated with your peer programmers, and made your shared world just that little bit brighter. You began with code and you ended with code - and if you've done it right, it's better code. After all, if TheSourceCodeIsTheDesign then ReFactoring is, as it should be, just "improving existing code". * ''But if the source code is the design, then improving existing code is improving the design...'' * (SC=D & R=D) => R=SC ??? Maybe we should do this over in EprimeLanguage ... * ''No, algebra is fine. SC=D therefore I(SC)=I(D).'' * =I(R) ??? Perhaps a little calculus might help. Would you believe R= dSC/dT. D= S Analysis d Architecture. Okay, maybe not so helpful ... * ''"I()" is the improve function. If source code is design, then improving source code is improving design.'' * Yes, I understand this. So if Refactoring is Design then improving design is improving refactoring. Which is improving improving refactoring. Which is ... * ''No, you don't understand this. Refactoring isn't ''the'' design (noun). Source code is the design (noun). Improving a design (noun) is one form of design (verb). So refactoring is design (verb), not design (noun).'' * Apologies. I should have said I understand what you meant by I(). Now let's look at this using EprimeLanguage and see if that might actually help. Source code represents the design. The process of design improves the source code's representation of design. So far I believe we agree? And I agree ReFactoring improves the representation of the design by the code. My point is it does something else too - something more direct and important. It improves the representation of the design by the developers' collective interactions. It creates a shared reality within which the developers communicate with each other opportunistically through CodeAsHumanLanguage. It operates on representation of the design by the dynamic interaction of the developers as a community. * ''I have no idea what that means or why I would want it.'' * Which part didn't you understand? * ''The modification of design with the word "representation" (source code doesn't represent the design, TheSourceCodeIsTheDesign)'' ** "It depends on what the meaning of the word 'is' is". Design begins in someones' heads. It's represented there by something other than source code. It is communicable between people without source code via CRC, whiteboarding, conversation, etc. Design represented as source code has the excellent property that it expresses a behavior that can be verified automatically. Refactoring improves the source code's representation of its design - not its behavior. ** ''The verb design begins in someone's head. The noun design is the source code. The source code doesn't "represent" the noun design, it ''is'' the noun design. It's the design we feed to the compiler/interpreter that manufactures the end product. It can't be verified automatically, but it can be built automatically.'' *** So ... that stuff with the whiteboards/CRC cards/conversations is not design? *** It isn't the noun design. *** Why not simply do away with the noun design since it apparently is an exact synonym for "source code". Then there is only the verb design and the source code, which are not the same things. And we can save everyone money replacing their worn out dictionaries. And we can delete this ThreadMess which will save Ward about 0.000000000000000000000001 of a cent. Whoops, half that. Anyway, some. *** ["Design" and "source code" are not always synonyms. In the abstract, design is an abstract representation of the high level ways that intent of functionality is realized by a potential implementation. The source code can sometimes, to some extent, '''model''' the design. Sometimes the same is true of UML, whiteboards, conversations, design documents, other times, they are not accurate models. But there's a difference between a representation and a model. A representation captures everything, it's a one to one mapping. In base 10, "16" is a representation of "2 to the fourth power". A model, on the other hand, an abstraction (or in some cases a concrete realization) that leaves out some (ideally inessential) information that is present in a complete representation.] *** [In other words, a representation is complete, a model is not. A '''good''' model leaves out inessential information. A '''bad''' model leaves out some essential information. A representation leaves out no information (but may still be "good" or "bad" relative to different criteria than that.] *** [People who say "the source code is the design" are basically saying that the source is an accurate model of the design, whereas design documents, conversations, etc, are notorious for being poor models of the design. In all cases, some important information (e.g. about underlying intent) may nonetheless be missing, or at best implicit.] *** Not this person. When I say the source code is the design, I don't mean it's an accurate model of the design. I mean it is ''the'' design. It is the document that will be used to build the product. The builder will not contribute to or re-interpret the design, but will blindly build it as instructed. -- EricHodges * ''And the stuff about "developer's collective interactions", "shared reality" and "dymanic interaction of the developers as a community".'' ** Think of ReFactoring as a way of Wiki-izing a codebase. Developers write and read code; by ranging across each others' code their interactions express their collective ownership of their code. As they refactor they share a reality defined by the code's representation of the design. And as they interact they share responsibility for maintaining and improving their reality. So Refactoring is a conversation among programmers; design (verb) is an instruction to programmers. ** ''Refactoring doesn't "wiki-ize" a code base, it just makes it prettier and easier to maintain. It isn't a conversation and the verb design isn't an instruction. It's the act of creating the noun design.'' *** OpenYourMind. *** ''Don't be bossy.'' *** Okay. Please OpenYourMind. ** [Refactoring means to make changes which do not change functionality. Good refactoring improves the code or design in some way (such as clarity, size, speed) without changing the functionality. Bad refactoring makes the code or design worse in some way, but still without changing functionality. If functionality changes, for better or for worse, it shouldn't really be called refactoring (call it "botched refactoring", perhaps, if the intent was to leave functionality unchanged, but the intent failed). '''But''', good refactoring of code or design can be an important precursor to changing functionality.] The process of design is (up front) performed in the absence of code. It needn't begin with code and it needn't end with code. It's documentation of the intent of code. It begins as an answer to analysis - which, at its most concrete, is merely an AcceptanceTest - and it ends with parameterization and combination of elements of technical architecture. It tells you you should go to Mulberry St, but it doesn't tell you what you'll do there. So it's like making maps of all the places you might go, rather than actually going and then doing. Different gazintas, different gazoutas, different experience; so now I believe the old choice on RefactorOrDesign was forced. This is to say, it loses the community aspects of ReFactoring. So: Listening, Testing, Coding, and ReFactoring - that's all there is. Anyone who says different is selling - or buying - something. ---- Where does the formulation at the top of the page get us? is not . Are we done? Meanwhile, consider this description of the design[ing] ''activity'': : ''the process of inventing things which display new physical order, organization, form, in response to function...'' -- ChristopherAlexander, NotesOnTheSynthesisOfForm So, taking "inventing things" at face value, some refactorings (such as ExtractClass) have a excellent claim to being the manifestation of design thinking - let's say, it becomes recognized that some responsibilities are spread around a little too much, and that pulling out a class to meet them all in one place will make a bunch of stuff easier to understand (=> easier to change, maintain etc). You can now argue the toss as to whether this is ResponsibilityDrivenDesign expressed through refactoring (the one-line description of ExtractClass includes a weasel-word: "relevant") or the plain magic of refactoring itself. Or something between (combining) the two Then again, something like PullUpField perhaps has a rather weaker claim to being a manifestation of design by itself, although it isn't hard to imagine such a thing being part of a sequence of refactorings that do manifest design - perhaps marshalling the "relevant" things into an agreeable place from which they might be extracted. Back at the larger scale, ExtractPackage looks ''very'' much like design, too. But these are all somewhat sterile, self-serving operations by the programmer, for the programmer. Alexander's description of design states that it is done "in response to function". Well, refactoring supposedly follows the addition of new passing tests which (in TDD-land) are justified by the next unmet requirement. Now consider WhatIsAnAdvancer, where Ward states that advancers were discovered two years into maintenance. (Actually, it looks a lot as if Ward understates the case there; discovering advancers looks mightily like EmergentAnalysis.) ''Looks like just reinventing functors to my untutored eyes. As to "in response to function", design in a waterfall is done in response to analysis. Testing, in a waterfall, is "in response to function". Not blessing waterfall, but it seems Alexander's definition doesn't account for it.'' ---- RefactoringIsRetrospectiveDesign - almost every process I have refactored when maintaining other people's code has revealed the design of the aspect I have been interested in. The design was there, but difficult to see. Often, the "worst programs" - the really huge ones - are inspirations, written by gurus. But only understandable by the gurus without refactoring. -- PeterLynch ---- Might there be some confusion here between design of code (how we put pieces together to do what we want) and analysis of requirements (deciding what we want, or, to use a phrase above, "documentation of the intent of code")? ---- JuneZeroFive CategoryRefactoring