设计杂谈二——变化的设计思想（1）

应该说我接触设计方面的东西很晚，所以很多旧的概念方法，仅仅限于书面知识，比如structural programming中的jackson方法，仅仅是课堂上学过而已，工作的时候已经完全忘了。正式收到设计方面的训练，是在98年接受Rational Rose的培训。Rose是我所接触的第一个设计工具，而RUP则是我接触的第一种正规的开发模式。所以我开始的时候接受的完全是正规的OOAD方法：建立用例；通过用例分析以及需求分析建立高层数据模型；动态分析；模型细化。。。等等等等。应该说我对于这种方法是全盘接受的。但是，在实际工作中，基本用不上：

很简单的一个例子：在实际工作中，包括项目经理在内，几乎没有权力决定一个软件什么时候完成。做出这个决定的，基本上都是市场的人员。而开发的人力，则基本是固定的，尤其是软件功能加强的时候，招聘新的开发人员基本上没用。至于软件的功能，对不起，也是市场部的说了算的。这样一来，一个软件开发中的三个因素：时间，人力，以及功能，都已经确定了。至于这三个点是不是能放进一个三角形，呵呵，这就是软件开发人员的工作了。于是乎可怜的开发人员首先想到的，根本不是什么需求分析或者是按部就班的设计。因为我们根本没有奢侈的权利。我们唯一能做的，就是把各种功能尽量简化，哪怕一些明知可以让软件在长期受益的东西，也一定要放弃，否则根本没办法按时完成。

而且客户的需求是无时无刻不在变化的。要你更改需求，你也没办法，毕竟是人家付钱。但是如果需求更改，往往来不及这么一步一步地做下去。

2000年，我第一次接触了我的偶像Martin Fowler（其实在98年就已经拜读过他的UML Distilled一书，不过真正的敬佩是从2000年开始的）。那时看到的，是他的一片关于continuous integration的文章（有兴趣的人可以去Martin Fowler的网站：www.martinfowler.com 看看他的文章，至少我觉得是字字珠玑）。当时刚刚接管一个大型项目，这个项目已经滞后了，而且内部的东西作的一塌糊涂，到处是bug。更有甚者，程序员为了赶工，把空白的方法当作完成的代码交给测试人员，等测试出来了再当成bug修改。如果这东西一个月测试不到，就一个月不用管了。老实说，遇到这种情况，我几乎抓狂，也想过离开（当时有其他的原因，倒不完全是因为这个项目作的太烂）。但是看了Martin Fowler的这篇文章之后，我马上有了茅塞顿开的感觉，马上把ant和我们当时自己开发的一套测试工具整合起来，开始了我的第一个类似XP的试验（当时把XP的想法和上面的经理们商量了一下，结果大家的反应竟然是哄堂大笑）。