Planned_and_Evolutionary_Design.pdfVIP

设计已死？ Scrum中文交流社区 设计已死？设计已死？ 作者：作者：Martin Fowler 译者：译者：Daimler Huang Planned and Evolutionary Design 我将在这篇文章中说明软件开发的两种设计方式是如何完成的。或许最常见的是演进式设 计。它的本质是系统的设计随着软件开发的过程增长。设计 (design) 是撰写程序代码过 程的一部份，随着程序代码的发展，设计也跟着调整。 在常见的使用中，演进式设计实在是彻底的失败。设计的结果其实是一堆为了某些特殊条 件而巧妙安排的决定所组成，每个条件都会让程序代码更难修改。从很多方面来看，你可 能会批评这样根本就没有设计可言，无疑地这样的方式常会导致很差劲的设计。根据 Kent的陈述，所谓的设计 (design) 是要能够让你可以长期很简单地修改软件。当设计 (design) 不如预期时，你应该能够做有效的更改。一段时间之后，设计变得越来越糟，你 也体会到这个软件混乱的程度。这样的情形不仅使得软件本身难以修改，也容易产生难以 追踪和彻底解决的 bug 。随着计画的进行，bug 的数量呈指数地成长而必须花更多成本去 解决，这就是 code and fix 的恶梦。 Planned Design 的做法正好相反，并且含有取自其它工程的概念。如果你打算做一间狗 屋，你只需要找齐木料以及在心中有一个大略的形象。但是如果你想要建一栋摩天大楼， 照同样的做法，恐怕还不到一半的高度大楼就垮了。于是你先在一间像我太太在波士顿市 区那样的办公室里完成工程图。她在设计图中确定所有的细节，一部份使用数学分析，但 是大部分都是使用建筑规范。所谓的建筑规范就是根据成功的经验 (有些是数学分析) 制 定出如何设计结构体的法则。当设计图完成，她们公司就可以将设计图交给另一个施工的 公司按图施工。 Planned Design 将同样的方式应用在软件开发。Designer 先定出重要的部份，程序代码 不是由他们来撰写，因为软件并不是他们 建造[译注3] 的，他们只负责设计。所以 designer 可以利用像 UML 这样的技术，不需要太注重撰写程序代码的细节问题，而在 一个比较属于抽象的层次上工作。一旦设计的部份完成了，他们就可以将它交给另一个团 队 (或甚至是另一家公司) 去 建造 。因为 designer 朝着大方向思考，所以他们能够避 免因为策略方面不断的更改而导致软件的失序。Programmer 就可以依循设计好的方向 (如果有遵循设计) 写出好的系统。 Planned design 方法从七○年代出现，而且很多人都用过它了。在很多方面它比 code and fix 渐进式设计要来的好，但是它也有一些缺点存在。第一个缺点是当你在撰写程序 代码时，你不可能同时把所有必须处理的问题都想清楚。所以将无可避免的遇到一些让人 对原先设计产生质疑的问题。可是如果 designer 在完成工作之后就转移到其它项目，那 怎么办？Programmer 开始迁就设计来写程序，于是软件开始趋于混乱。就算找到 designer ，花时间整理设计，变更设计图，然后修改程序代码。但是必须面临更短的时程 以及更大的压力来修改问题，又是混乱的开端。 此外，通常还有软件开发文化方面的问题。Designer 因为专精的技术和丰富的经验而成 为一位 designer 。然而，他们忙于从事设计而没有时间写程序代码。但是，开发软件的 设计已死？ Scrum中文交流社区 工具发展迅速，当你不再撰写程序代码时，你不只是错失了技术潮流所发生的改变，同时 也失去了对于那些实际撰写程序代码的人的尊敬。 建造者 (builder[译注3]) 和设计者之间这种微妙的关系在建筑界也看得到，只是在软件界 更加凸显而已。之所以会如此强烈是因为一个关键性的差异。在建筑界，设计师和工程师 的技术有清楚的分野；在软件界就比较分不清楚了[译注2] 。任何在高度注重 design 的环 境工作的 programmer 都必须具备良好的技术，他的能力足够对 designer 的设计提出质 疑，尤其是当 designer 对于新的发展工具或平台越来越不熟悉的状况下。 现在这些问题也许可以获得解决。也许我们可以处理人与人之间的互动问题。也许我们可 以加强 designer 的技术来处理绝大