?? thesourcecodeisthedesign.html
字號:
<head><title>The Source Code Is The Design</title></head><body><h1><img src="logo.gif"> The Source Code Is The Design</h1>Years ago I read an article that completely changed how I thought about
software design. I hope that it XP picks this up because I see it as
a very insightful view which XP completely validates empirically. For
me, it couldn't have come at a better time. When I first read it, I was
effectively post-documenting a project using IEEE software documentation
standards and cursing the incredibly surreal waterfall process.
<p>The name of the article is <em>What Is Software Design?</em> It was written
by <a href="http://c2.com/cgi/wiki?JackReeves">JackReeves</a> and published in The C++ Journal Vol. 2, No. 2. 1992. I
think the journal is defunct, which is a shame. I really wish everyone
had a chance to read the article.
[...not to be confused with the "C <em>Users</em> Journal" (now the "C/C++ Users Journal") at <a href="http://www.cuj.com/">http://www.cuj.com/</a> ].
The article is available at <a href="http://gosh.exeter.ac.uk/~cs98abh/archive/documents/what_is_software_design.html">http://gosh.exeter.ac.uk/~cs98abh/archive/documents/what_is_software_design.html</a>.
<p>Essentially the point is this. When the original <em>phases</em> of software
development were laid down, they were just plain wrong. Requirements,
Design, Implementation, and Test are not what we think they are. Design
is not something that you do only before you code. Implementation is
not the act of coding. We can see this if we look realistically at what
they are in other engineering disciplines.
<p>(from the article):
<p><DL><dt> <dd><em>The final goal of any engineering activity is to create some kind of documentation. When a design effort is complete, the design documentation is given to the manufacturing team. This is a different set of people with a different set of skills from those of the design team. If the design documents truly represent a complete design, the manufacturing team can proceed to build the product. In fact, they can proceed to build much of the product without further assistance from the designers. After reviewing the software development lifecycle today, it appears that the only software documentation that actually seems to satisfy the criteria of an engineering design are the source code listings.</em>
<p><p></DL>This is how people build bridges and buildings and toasters. See also: <a href="http://c2.com/cgi/wiki?AnalogyBetweenProgrammingAndManufacturing">AnalogyBetweenProgrammingAndManufacturing</a>
<p>Think about it.. When you are programming, you are doing detailed
design. The manufacturing team for software is your compiler or
interpreter. The source is the only complete specification of what the
software will do. The cute boxes in class diagrams are not the design,
they are a high level view of the design.
<p>What are the ramifications? (paraphrased from the article)
<p><UL><li> <em>Software runs on computers. It is a sequence of ones and zeros. Software is not a program listing.</em>
<li> <em>A program listing is a document that represents a software design. Compilers, linkers, and interpreters actually build (manufacture) software.</em>
<li> <em>Software is very cheap to build. You just press a button.</em>
<li> <em>Software is expensive to design because it is complicated and all phases of the development cycle are part of the design process.</em>
<li> <em>Programming is a design activity; a good software design process recognizes this and does not hesitate to code when coding makes sense.</em>
<li> <em>Coding actually makes sense more often than believed. Often the process of rendering the design in code will reveal oversights and the need for more design effort. The earlier this happens, the better.</em>
<li> <em>Testing and debugging are design activities - they are the equivalents of design validation and refinement in other engineering disciplines. They can not be shortchanged.</em>
<li> <em>Formal validation methods are not of much use because it is cheaper to build software and test it than to prove it.</em>
<p></UL>-- <a href="http://c2.com/cgi/wiki?MichaelFeathers">MichaelFeathers</a>
<hr>
<DL><dt> <dd>Well! I just did a <em>major</em> refactoring of this page -- it is now seven(!) pages on the article itself and the topics that came out of it. Now I understand what Ron says about needing to refactor all the time. Ugh.
<p><dt> <dd>If you don't like where I put something, don't whine about it, fix it. Also, I don't like the "See" references -- a bit more lead-in would be good. And finally, I think this page and a few of the offspring are <em>still</em> too long...
<p><dt> <dd>-- <a href="http://c2.com/cgi/wiki?BillTrost">BillTrost</a>
</DL><hr>
See <a href="http://c2.com/cgi/wiki?DocumentationBeyondTheSourceCode">DocumentationBeyondTheSourceCode</a>
<a href="http://c2.com/cgi/wiki?SourceCodeAndModeling">SourceCodeAndModeling</a>
<a href="http://c2.com/cgi/wiki?TheWhatButNotTheWhy">TheWhatButNotTheWhy</a>
<a href="http://c2.com/cgi/wiki?SelfDocumentingCode">SelfDocumentingCode</a>
<a href="http://c2.com/cgi/wiki?WhatIsSourceCode">WhatIsSourceCode</a>
<hr>
<em>"The final goal of any engineering activity is to create some kind of documentation."</em>
<hr>
Since this topic seems to be generating some interesting discussion (still) I have posted the original article on the web at <a href="http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm">http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm</a> Needless to say, I am thrilled that finally someone is starting to look at this. To me, the entire software industry has a <em>serious</em> quality problem. However, as <a href="http://c2.com/cgi/wiki?WilliamEdwardsDeming">WilliamEdwardsDeming</a> has repeatedly shown, the only way to really improve quality is to modify the process. In order to modify the process, you have to first understand it. -- <a href="http://c2.com/cgi/wiki?JackReeves">JackReeves</a>
<p>This confuses me more than the average thing, all of which confuse me. I would have thought that the final goal of software engineering was to produce the program. Is this just another proof that there isn't any such thing as software engineering? --<a href="RonJeffries.html">RonJeffries</a>
<p><em>His formulation is confusing because we use the word documentation differently. Consider engineers making a bridge. They make plans (which he calls design documents) and hand them to the construction team building the bridge. EE's make schematics (which he calls design documents) and hand them to the techs with soldering irons. We make source code (which he calls design documents) and hand it to the computer which manufactures software. The parallel is striking. We are just the first branch of engineering that had a way to go directly from design to product at the press of a button. Building, or implementation, is so easy in software that we overlooked it and called programming implementation. We forget that every coding decision is a design decision which impacts the capabilities of the product. -- <a href="http://c2.com/cgi/wiki?MichaelFeathers">MichaelFeathers</a></em>
<p><DL><dt> <dd>This is very pretty but I don't think it is true. I know our need to abstract and draw parallels but I'm not sure how accurate this one is. But then again, Michael, I also don't feel comfortable with the idea that source code is the construction material analogous to girders or other composable parts from the physical world. Both viewpoints (i.e. source code is design documentation and source code is construction material) seem wrong to me. However, once again I will say that is is a <em>very</em> nice formulation -- I kind of wish it <em>were</em> true. --<a href="http://c2.com/cgi/wiki?RobertDiFalco">RobertDiFalco</a>
<p><p></DL>This resonates with some thoughts about project management. It seems like a common error in software project management is in treating all the stuff that developers do as a <em>manufacturing</em> activity. This seems to be a driver behind a lot of poor management decision making, and unrealistic goal setting.
<p>Maybe if software managers understood better (I could just leave it there ;-) that software product (executables) may indeed be <em>manufactured</em> in any quantity in a short time, flawlessly and cheaply by the machine, they wouldn't try so hard to map all the activities upstream from final build onto a production line.
<p>I guess everyone from <a href="http://c2.com/cgi/wiki?FredBrooks">FredBrooks</a> on has being saying these things, but Micheal's comment really crystallized this idea for me.
<p>(If you are a software development manager reading this, be assured I'm talking about someone else.)
--<a href="http://c2.com/cgi/wiki?KeithBraithwaite">KeithBraithwaite</a>
<hr>
The position of the article was not that source code makes all other
documentation obsolete, it is simply that the act of programming is
designing. To be quite honest, I sometimes fear that people who read
about XP superficially may get the impression that it is "let's go in
like gangbusters and hack something up." Especially those who come
from places with formal trails through a development process, and the
managers chant "what do you mean you don't have a pile of documents??"
You don't really hear the word design thrown around in XP. Yet, I do
believe, from experience, that <a href="http://c2.com/cgi/wiki?WardAndKent">WardAndKent</a> are right. You do just have
to try things out in code. It is how you solidify and validate design.
<a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a>.
<p>The thing about <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a> is that it recognizes that coding is part of designing. The difference between someone who can step up to the computer and program/design something well without having elaborately diagrammed it, and a hack who paints himself into corners is really one of experience, talent, and motivation to learn. The artificial line between programming and design causes tremendous waste. Everyone thinks that software is intrinsically different. That it requires a completely different approach from anything else in engineering. It isn't different, we just misunderstood it. We believed that coding and testing were not part of design. They are just like prototyping on a breadboard. Part of design.
<p>This is one of the <a href="http://c2.com/cgi/wiki?TwoIrreparableMistakesOfTheSoftwareField">TwoIrreparableMistakesOfTheSoftwareField</a>, IMHO. -- <a href="http://c2.com/cgi/wiki?MichaelFeathers">MichaelFeathers</a>
<hr>
See <a href="http://c2.com/cgi/wiki?UnderstandingHotDraw">UnderstandingHotDraw</a> and <a href="http://c2.com/cgi/wiki?TheSourceCodeAndTheArchitecture">TheSourceCodeAndTheArchitecture</a>.
<hr>
''It looks like you buy it but you are looking for something else.
Suppose you visit NASA and you ask to see the design for a Saturn V.
The handtruck full of documents comes in and you are lost. Then someone
comes up with a one page breakdown of the major components. You are
back on track again. Does that mean that the one pager is the design
and the handtruck contents aren't? No. It just means that there are
many views into the design.''
<p>See <a href="http://c2.com/cgi/wiki?XpCritique">XpCritique</a>.
<hr>
I can certainly see why we want the source code to be the design, but
I'm not convinced it is <em>all</em> of the design. For example, for folks
using file-based programming environments and their languages, there
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -