敏捷开发中认为源代码才是真正、并且唯一的设计，而其他的为了编写源代码而画出来的图或是写出来的描述，均是这份唯一的设计文档的辅助文档。
==================================
我个人认为源码是产品结果,就比如制造机床一样,源码就是机床这个产品结果,所谓编译,无非是给机床通上水电气,按下开关,让这台机床运转起来
而之前的按照某种工业标准做出的机床设计图纸——包括零件图、部件图、部件装配图、总装图（这些图纸都是包含有标准化概念的详细加工要求的）等，才是设计阶段的设计成果
当制造业的产品加工能力很强的时候，一整套完整的图纸可以送往任何一家有能力的加工厂，制造出最终可被客户使用产品
或者可以说，需求提供——设计过程——产品制造过程的三个标准分界是标准化语言的运用与终结
需求提供是指提供尚未形成标准化语言之前的东西的过程
设计过程是指用标准化语言刻画出设计成果的过程
产品制造过程则是根据设计成果选择材料并运用加工设备与加工技术将材料加工成最终产品的过程——软件制造中可能没有最基础级别的材料的概念（比如机械制造中的金属、木头等）、，不过控件可以视为中间级材料（类似于零件或部件的概念），加工设备就是各类开发语言，加工技术就是程序员的编码技术
机械制造中的标准化语言就是我们学习的机械制图的知识，机械制图的知识告诉我们如何用标准化语言描述你的需求，就目前的社会而言，多数情况下，任何一个零件的制造都是根据标准的机械制图图纸进行加工的，也有些极简单的要求会只根据手绘草图进行加工（通常用在要求极其粗糙的情况下）
未来软件设计的前进方向应该是向这个方向前进的
因为标准化的设计过程会有利于最终产品的维护与能力扩展，有利于在设计阶段而不是制造阶段发现问题，减小整体成本，也有利于产品的可阅读性（没有人愿意把一台机床全拆散了来维护或进行能力升级的，维护人员必然会希望有一套完整的图纸来阅读，借以判断问题可能出在哪或该机床是否有可以升级改造的潜力，即使是机床的总设计师也会希望如此，因为他不可能记得住所有他所设计过的东西的所有细节）
------解决方案--------------------------------------------------------
一个熟悉各类加工设备（各类编程语言）并具有高超加工技术（编程能力）的人
如果同时具备设计能力，则是综合效果会是比较强大的
因为他比一般的设计师更明白当前的加工设备与加工技术的缺陷在哪里，可以避免设计出难以加工的图纸
而现时他比一般的编程人员更懂得标准化的优势，可以避免设计及制造出让别人根本难以理解难以维护的东西
------解决方案--------------------------------------------------------
我对"源代码才是真正、并且唯一的设计"这话一直都觉得很白痴.
我认为,恰恰相反,源代码是实现的过程,连设计都算不上.
一个设计是建筑图纸,一个源代码只是一个照着图纸砌出来的建筑.
设计图纸是需要工程师才能制订出来的.而建筑,只要是能看懂图纸的建筑工人就可以堆砌的.
对我来说,一份规范且完整可靠的设计文档,远比源代码更有用.我宁愿只把设计文件存档而把源代码丢掉.甚至我觉得唯一最应该看重的就是一份真正意义上的"用户需求"文档,别的都可以没有,这个不能少,也不能走样.
我想这个分别取决于一个公司对他们制作出来的产品的态度和技术实力.
------解决方案--------------------------------------------------------
楼上的两位，别把无知当无畏。。
如果软件设计和你们所说的设计都一样，也不会有软件危机了？？？
在你设计一个软件之前：请确信一个标准：所有的变化中，唯一不变的是：需求一直是在变化的
如果你能弄懂这些。在来谈论这些吧，，
------解决方案--------------------------------------------------------
严重同意jonescheng(小块头无大智慧) 的说法
就敏捷软件开发而言,考虑到了软件的不断变化
适用于小的团队开发 ,如果大型团队来说,文档还是比较重要的
------解决方案--------------------------------------------------------
同意：敏捷开发中,源代码才是真正、并且唯一的设计
同意：所有的变化中，唯一不变的是：需求一直是在变化的
同一设计，
制造业销耗加工成本，再加工再销耗加工成本
软件业第一次加工消耗成本，后来几乎没有软件加工成本，只有服务成本
好的程序，层次清晰，需求逻辑清晰
制造业的图纸的工艺设计并不完整，需要加工部门做工艺，有时工艺完成后，需要修改设计图纸。
------解决方案--------------------------------------------------------
可能你选用的暗喻不大好吧,把软件开发比做机械制造.....
------解决方案--------------------------------------------------------
敏捷開發認為「源代码才是真正、并且唯一的设计」
因為敏捷開發不想浪費太多時間在他們認為無謂的「設計」上面。
Martin Fowler 在《UML Distilled》一书中提到，人们以三种态度来应用UML：
1.视其为草图
2.视其为设计蓝图
3.视其为编程语言，
XP、敏捷UP, 敏捷开发基本上将UML等图面设计皆视其为草图，
而RUP等则将其视其为设计蓝图，
至于正在努力的MDA，则打算将其视为是编程语言。
（注，MDA不是开发过程，本不应拿来对比，但一时想不到该放什么，不必深究）
基于这样子的态度，
当然他们认为「源代码才是真正、并且唯一的设计」。
这里头没有对错，
只是一种态度的问题。
至于上面有人提到「所有的变化中，唯一不变的是：需求一直是在变化的」
并且认为理解了这句才能讨论这个问题，
那是可笑的。
「所有的变化中，唯一不变的是：需求一直是在变化的」
这句话本身是对的，
但却与「源代码才是真正、并且唯一的设计」这个论点的认同与否无关。
也就是说两句话之间不存在因果、顺序的关系。
敏捷开发也罢、敏捷UP也罢，XP也罢、RUP也罢，
由于这几种开发过程都基于迭代式开发（非瀑布式），
因此基本上都是认同「需求变化」的。
不论什么开发过程，都有支持者，
也各有优缺点，
我们能否认同「源代码才是真正、并且唯一的设计」，
可以做为我们选择开发过程的选项之一，
但不能偏废。
因为不论哪一种开发过程，
都有其适用性与不适用性。
实际应用过程中会发现，
有时候视源代码为唯一设计反而轻松。
再者，源代码确实是一种设计，而不是一种产品。
有本书说这就是软件无法大量制造的原因。
是产品才能大量制迼，
设计则不行。
且不论这本书说的观点对错，
因为任何观点都是不断在改变的。
也许将来软件真的变成可大量制造的产品了也不一定。
总之，提出敏捷开发者，有其论点，
有其适用性，
也颇多人支持。
你可以认同或者不认同「源代码才是真正、并且唯一的设计」，
但你应该跳过「认同与不认同」，
看看它的论点与支持点，
在适用时你便多了一个可选工具。
------解决方案--------------------------------------------------------