好文章共享:设计已死?
英文原文版权由Martin Fowler拥有
Original text is copyrighted by Martin Fowler
Martin Fowler
Chief Scientist, ThoughtWorks
原文出处| 繁体版 | 译者:Daimler Huang
对很多粗略接触到 Extreme Programming 的人来说,XP 似乎 宣告了软件设计的死刑。不只很多的设计被嘲笑为 "Big Up Front Design"[译注1],连很多技术像UML、富有弹性的程序架构 (framework),甚至连模式 (pattern) 都不受重视,或是近似忽略了。事实上,XP内含很多设计理念,但是它与现有的软件流程有着不同的运作方式。XP藉由多种实务技巧 (practice) 赋予演进式设计 (evolutionary design) 崭新的风貌,让演进变成一种实用的设计方法。它也让设计者 (designer[译注2]) 面临新的挑战与技巧,学习如何使设计精简,如何使用重构来保持一个设计的清楚易懂,以及如何逐步地套用模式。
近期重大更新:2001年2月
(这篇文章是我在 XP2000 研讨会发表的演说,它会公布在研讨会讲义中。)
Planned and Evolutionary Design (经过规划的设计与演进式的设计)
The Enabling Practices of XP (XP有效的实作技巧)
The Value of Simplicity (简单的价值)
What on Earth is Simplicity Anyway (究竟什么是简单)
Does Refactoring Violate YAGNI? (重构违反了YAGNI吗?)
Patterns and XP (模式与XP)
Growing an Architecture (发展结构)
UML and XP (UML与XP)
On Metaphor (关于隐喻)
Do you wanna be an Architect when you grow up? (你将来想成为一个软件结构师吗?)
Things that are difficult to refactor in (很难重构的东西)
So is Design Dead? (所以,设计死了吗?)
Acknowledgements (致谢)
Revision History (修订的记录)
Extreme Programming (XP) 挑战很多软件开发常见的假设。其中最受争议的就是极力排斥 up-front design,而支持一种比较属于演进的方式。批评者说这是退回到了 "code and fix" 的开发方式,顶多只能算是一般急就章的程序设计罢了。支持者也常看到 XP 对于设计方法 (如 UML)、principle(设计准则)、patterns 等的排斥。别担心,仔细注意你的程序代码,你就会看到好的 design 浮现出来。
我发现自己正陷于这个争论当中。我的工作着重在图形化设计语言 - UML 以及 patterns,事实上我也写过 UML 和 patterns 的书。我如此的拥抱 XP 是否表示我放弃了这些理论,或是将这些反渐进式 (counter-revolutionary) 的概念从脑中清除了?
嗯... 我不想让你的心悬荡在这两种情境中。简单的说并不是;接下来的文章就让我来详细说明。
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。然而,他们忙于从事设计而没有时间写程序代码。但是,开发软件的工具发展迅速,当你不再撰写程序代码时,你不只是错失了技术潮流所发生的改变,同时也失去了对于那些实际撰写程序代码的人的尊敬。
建造者 (builder[译注3]) 和设计者之间这种微妙的关系在建筑界也看得到,只是在软件界更加凸显而已。之所以会如此强烈是因为一个关键性的差异。在建筑界,设计师和工程师的技术有清楚的分野;在软件界就比较分不清楚了[译注2]。任何在高度注重 design 的环境工作的 programmer 都必须具备良好的技术,他的能力足够对 designer 的设计提出质疑,尤其是当 designer 对于新的发展工具或平台越来越不熟悉的状况下。
现在这些问题也许可以获得解决。也许我们可以处理人与人之间的互动问题。也许我们可以加强 designer 的技术来处理绝大部份的问题,并且订出一个依照准则去做就足够改变设计图的流程。但是仍然有另外一个问题:变更需求。变更需求是软件项目中最让我感到头痛的问题了。
处理变更需求的方式之一是做有弹性的设计,于是当需求有所更改,你就可以轻易的变更设计。然而,这是需要先见之明去猜测将来你可能会做怎样的变更。一项预留处理易变性质的设计可能对于将来的需求变更有所帮助,但是对于意外的变化却没有帮助 (甚至有害)。所以你必须对于需求有足够的了解以隔离易变的部份。照我的观察,这是非常困难的。
部份有关需求的问题应该归咎于对需求的了解不够清楚,所以有人专注于研究需求处理,希望得到适切的需求以避免后来对设计的修改。但是即使朝这个方向去做一样无法对症下药。很多无法预料的变更起因于瞬息万变的商场,你只有更加小心处理需求问题来应付无法避免的情况。
这么说来,planned design 听起来像是不可能的任务。这种做法当然是一种很大的挑战。但是,跟演进式设计 (evolutionary design) 普遍以 code and fix 方式实作比较起来,我不觉得 planned design 会比较差。事实上,我也比较喜欢 planned design。因为我了解 planned design 的缺点,而且正在寻找更好的方法。
(未完)