📄 bigdesignupfront.html
字号:
<head><title>Big Design Up Front</title></head><body><h1><img src="logo.gif"> Big Design Up Front</h1><strong>Summary:</strong>
<p>The term <a href="BigDesignUpFront.html">BigDesignUpFront</a> is commonly used to describe methods of software development where a "big" design is created <em>before</em> coding and testing takes place. Several <a href="ExtremeProgramming.html">ExtremeProgramming</a> (XP) advocates have said that such "big" designs are not necessary, and that most design should occur throughout the development process. While Xp does have initial design (the <a href="SystemMetaphor.html">SystemMetaphor</a>), it is considered to be a relatively "small" design. Much of this page disputes the amount of up-front design required for software projects.
<p>See also <a href="http://c2.com/cgi/wiki?ClarityUpFront">ClarityUpFront</a>, <a href="http://c2.com/cgi/wiki?DesignDiagramsArentEvil">DesignDiagramsArentEvil</a>, <a href="http://c2.com/cgi/wiki?TheDeadlineOnBigDesignUpFront">TheDeadlineOnBigDesignUpFront</a>, <a href="http://c2.com/cgi/wiki?AdequateArchitectureUpFront">AdequateArchitectureUpFront</a>, and <a href="http://c2.com/cgi/wiki?CanAnArchitectureEmerge">CanAnArchitectureEmerge</a>.
<p>[Note: the following discussions were reordered for clarity.]
<p><hr>
<hr>
<strong>Some Upfront Design Required?</strong>
<p>[This section originally followed the Smalltalk design/prototyping discussion.]
<p>Even in Smalltalk, though, <em>some</em> design has to be done upfront, especially on really big enterprise-scale systems. There has to be some sense of what goes on the desktop, how many services there are and how many machines are needed to support them, what has to connect to the legacy systems and how, and that sort of thing. I can't really stand up in front of a project review team for a $60M call center installation and suggest that they "read the code" in order to understand whether the resulting system will satisfy the very real 3-second response-time constraint.
<p>I prefer the <a href="http://c2.com/cgi/wiki?DesignIsNotaDevelopmentPhase">DesignIsNotaDevelopmentPhase</a> approach, where the idea is to capture the design, and therefore encourage it to evolve. Presumably the big seams begin to stabilize relatively early on, while some small ones stay in flux until deployment (or even afterwards...).
<p>--<a href="http://c2.com/cgi/wiki?TomStambaugh">TomStambaugh</a>
<p><em>Even in Smalltalk, though, some design has to be done upfront [...]. [What goes on the desktop, number of services and support machines, legacy connections, etc.]</em>
<p>Which of these things can't be decided one at a time, when its turn comes to be implemented?
<p><em>I can't really stand up in front of a project review team for a $60M call center installation and suggest that they "read the code" in order to understand whether the resulting system will satisfy the very real 3-second response-time constraint.</em>
<p>What makes reading the document more convincing? When our top customer challenged whether our system could be fast enough, we measured it, ran it in 10 parallel processes and measured it again. Did the math. <strong>That</strong> was convincing. --<a href="RonJeffries.html">RonJeffries</a>
<hr>
<em>Which of these things can't be decided one at a time, when its turn comes to be implemented?</em>
<p>The ones that have to be funded by the client <em>before</em> the subsystem is built. The ones where the client wants to know ahead of time how much the total solution is likely to cost.
<p><em>What makes reading the document more convincing?</em>
<p>The fact that the document is written in English, and most of the review team (particularly the managers and recommenders whose approval is needed to close the phase and pay the bill) haven't read or written code in 30 years, if at all. Many system problems, such as call centers, don't succumb so readily to simple demonstrations of blazing speed. In my example, the *response time* of a call center is as likely to be affected by network load and the number of network transfers (because of network latency) as the performance of any one system. A data transfer that requires 100 hops at 100 milliseconds per hop is going to burn 10 seconds in transfer time, even if the participating systems are infinitely fast.
<p>In the hardware world, the "design", especially of a complex system, is how you answer questions about how close to critical limits you are, what margins of safety you've built in, how you know that a particular beam is thick enough or cooling element big enough. The same sort of thing has to be done in software, especially in mission- or life-critical applications. And it is NOT all in the source code, it's as much in the interconnections among components. And those *aren't* in the source code.
<p><hr>
<strong>Design and Architecture</strong>
<p>The words <a href="BigDesignUpFront.html">BigDesignUpFront</a> do bring to mind something of the aim of much architectural design in the building sense. Good design often follows where Big Ideas precede Detail Design. Conversely it is rare for small scale, pragmatic Detail Design alone to bring forth Great (or even worthy) Architecture.
Of course some Big Ideas are so far removed from the pragmatics as to be spurious as Design generators.
As noted in NOOHasNothingToDoWithSoftware, the key seems to be to correlate Big Ideas that have a genuine relationship with the item being designed.
<p><a href="BigDesignUpFront.html">BigDesignUpFront</a> in architecture does not require that every aspect of the design is predetermined. However it does provide a powerful reference for evaluation of subsequent ideas in the iterative design process.
--<a href="http://c2.com/cgi/wiki?MartinNoutch">MartinNoutch</a>
<p>We are perhaps learning the need to be humbler at this stage of software development Martin. But I guess the nearest parallel in <a href="ExtremeProgramming.html">ExtremeProgramming</a> to what you're referring to as good and necessary <a href="BigDesignUpFront.html">BigDesignUpFront</a> in physical architecture is the <a href="SystemMetaphor.html">SystemMetaphor</a>. After that greatness comes (if it ever does) through brilliant teamwork on the detail. But see also the unresolved questions in <a href="http://c2.com/cgi/wiki?ExternalAndInternalDesign">ExternalAndInternalDesign</a>. --<a href="http://c2.com/cgi/wiki?RichardDrake">RichardDrake</a>
<p>I'm not sure about the <a href="ExtremeProgramming.html">ExtremeProgramming</a> people or the exact meaning of <a href="BigDesignUpFront.html">BigDesignUpFront</a>, but a high-level up-front design is generally regarded by most as important to large-scale object-oriented software systems. There's a tremendous amount of quantification to support the position. However, in software, this high-level design is very dynamic and changes as implementation is created. For a long time, one could get away with nothing more than <a href="http://c2.com/cgi/wiki?CodeAndTest">CodeAndTest</a> and Refactoring, but as systems become more complex, a need arises for some consideration to high-level designs and strategies. This is may be why there is such a rift between <a href="http://c2.com/cgi/wiki?SoftwareArchitect">SoftwareArchitect</a><strong></strong>s and <a href="ExtremeProgramming.html">ExtremeProgramming</a>. Extreme Programmers don't agree with this position -- and they may be right for the type of apps they develop. But some <a href="ExtremeProgramming.html">ExtremeProgramming</a> enthusiasts are even hostile to the idea of <a href="http://c2.com/cgi/wiki?SoftwareArchitecture">SoftwareArchitecture</a>. --<a href="http://c2.com/cgi/wiki?RobertDiFalco">RobertDiFalco</a>
<p><hr>
<strong>Design Documents</strong>
<p>I'm clearly the only programmer left who doesn't use smalltalk at all.
<p>I'm in an environment where I get pieces of a very large system to write. I start out by writing up a little analysis document that I use to ensure that I understand the requirements. I then write up a high level design and check to make sure that it will take care of all the requirements in the analysis. Then I refine the high level design into a low level design. I often write code to do this, sometimes I decide that <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a>, other times I <a href="http://c2.com/cgi/wiki?UsePrototypesToChallengeAssumptions">UsePrototypesToChallengeAssumptions</a>. I don't, however, allow the design document to omit any information that is needed in order to understand the code. That means that I'm always twiddling the design doc while I'm writing the code. It's not really all that onerous either because I use the design doc as a sort of checklist that tells me when I'm done with the code. If I change my mind about how to do something I change the doc so that I can check off what I've really done. If I didn't do that then I'd have stuff on the doc that never got checked off and I'd have code that got written for no apparent reason. It seems like the same kind of relationship the Extreme guys have with Unit Tests. One result is that the design is definitely not done until the code is. We keep our design docs in revision control and I find that I always check in my designs when I check in my code.
<p>I guess my point is that I believe strongly in <a href="BigDesignUpFront.html">BigDesignUpFront</a> -- but only for a little part of the whole program at a time. <em>Wouldn't that be LittleDesignAllAlong<a href="http://c2.com/cgi/wiki?edit=LittleDesignAllAlong">?</a>?</em>
<p><em>An <a href="http://c2.com/cgi/wiki?ExtremeProgrammer">ExtremeProgrammer</a> might write tests to represent what the code had to do, and then code until they ran. What is the documentation cycle adding to the story? If you have the tests, why aren't they sufficient to know when you're done? And if you don't, how do you know when to check something off? --<a href="RonJeffries.html">RonJeffries</a></em>
<p><hr>
<a href="http://c2.com/cgi/wiki?SmalltalkAsDesignPrototypeLanguage">SmalltalkAsDesignPrototypeLanguage</a> [moved to another page]
<p><hr>
<strong>Other Discussion:</strong>
<p>I don't keep up to date on the methodology wars, and it seems everyone's more
on a patterns bandwagon of late, but last I recall ~92 the prevailing
sensible view (i.e. matching mine) seemed to be some variation on cyclical
development (recursive-parallel, iterated "analyze a little, design a little,
code a little, test a little", whatever).
<p>Haven't looked at <a href="http://c2.com/cgi/wiki?TheDeadline">TheDeadline</a>, but the writeup here make it sound as though
a lot of experience is being discarded, especially as indicated in the "don't allow implementation until the very last minute" notion.
<p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -