关于 XP 中的设计 - 是百川归海， 还是歧路悲歌

to armlinux-w：
我的想法也是比较接近于 Martin Fowler 的（XP 支持者中比较保守的那一派），因此我们仍然会有一个比较短暂的前期设计阶段。这个阶段是我唱主角，但是程序员一定要参与进来，做一些外围的设计工作。这个阶段不会很长，一般不超过两周时间。

我想采用什么样的开发过程与你所在的团队成员的经验和能力有很大的关系，就我们现在这个团队来说，完全没有前期设计是非常危险的。那样我肯定会手忙脚乱的，因为手下的程序员不要说设计，其实编程都有很大的欠缺。国内的很多软件公司其实都存在这个问题，人员的流动性太大，好不容易带出来的人跑掉了，团队中的很多程序员都是新手。如果无法改变这个状况，只能想办法适应。这种状况的开发团队我认为是不适合严格采用 XP 的。这些程序员实在是差得太多，别说重构和 TDD 了，先把代码写整齐再说吧。其实这个阶段的程序员最适合的还是一种命令的方式，必须要非常具体地告诉他们该做些什么事情，然后他们才可能完成工作。等到他们有一定经验了，再逐步将 XP 的各种最佳实践加入进来。

就象我上面说的，对于这些方法论，只有在你不把它们当作教条的时候，它们对于你才是真正有价值的。尽信书则不如无书。

同意。我也认为 XP 对人员的素质要求很高， 对coach 的要求更高。

对于前置设计我来说点自己的看法（本来是等到umlchina下期出来以后，把 Rosenberg的访谈看完整之后再作一个对XP的完整的解释，现在有点觉得太遥远，就先来点）。

这次访谈中的一位回答中说了上面的话，这段话我感觉很重要。我没有那些学位，但是我很小的时候就开始玩无线电，所以知道电路图的重要。当然如果把软件的设计文档可以比喻为电路图，那么这些文档无疑是整个开发过程中最重要的。然而问题恰恰是这些软件设计文档根本就不能和电路图相提并论。实际上电路图并不是一个模型，它是实实在在的可以运行的，你可以凭着电路图计算出每一点的电路的电压和电流，计算出负载，计算出每一个元件应该的参数。实际上有了电路图，就等于有了这个电路，你可以在一个虚拟的环境下运行这个电路，而跟你已经拥有这个电路完全一样。特别是你已经设计出了线路板图以后，你的这个设计就和普通的实物没有什么差别，连线路之间的互相干扰，和器件发热造成的影响你都可以通过这个图预测出来。
我当然希望软件设计也可以做到这个地步，可惜这完全不现实。首先你的设计文档完全不可以运行。当然你可以说不是很多人在研究可运行的UML，可惜当UML可以直接运行的时候，UML能否再称为一种设计语言就成为了问题，大概得情况是你还需要为这些UML再设计出一个设计。不能运行你实际上只是凭着猜想和所谓的逻辑推断，研究这个程序在运行中的状态。
其次软件中的设计和普通的电路设计不同之处还在于，一个线路图的实现方式基本上就只存在一个，并且在后期的修改（比如你的收音机有点存在线路之间的干扰，你可以在你发现这一点之后再加一个屏蔽）也有些不是很困难。而软件的情况完全不同，谁都知道一个uml的图示或者一个设计文档，如果不足够的详细，那么实际的实现可能会有十分大的区别，这一点的存在会使你的设计对于实现的控制降低到最小。而同时由于你的设计会受到实现的影响，所造成的后期修改由于你存取的前期大量投入的做法，将使你后期的修改变动变得非常困难而不是容易。实际上尽早发现象电路线之间的互相干扰是最好的解决方式，而不是你给所有的线路都加上屏蔽。
实际上软件中的前期设计和我们见到的设计完全不同，基本上不存在物理或者化学定律的束缚，这既是我们的优势也是我们的劣势。

而同时我们也要注意，是不是前期的设计在XP中完全的不存在呢？在XP中当然存在前期的设计，不然的话你从什么地方得到的系统隐喻呢？如果没有前期设计那么小组之间的接口是怎么设定的呢？难道真的如同某些人暗示的那样，xp就是一群人听到客户的发言之后马上就投入coding的一场儿戏？
XP中不是没有了前期设计，而不是把前期的设计降低到一个可以接受的水平，可以控制的范围，可以理解的区域。人们对于前期设计的依赖，实际上是受到对工具的开发熟悉程度，对于领域的熟悉程度，对于协作者的熟悉程度，所以约束的。在一个可以控制的范围内，在保障协作的前提下，尽量的把前期的设计降低到最少。为什么要这样做呢？
实际上任何代码都不能保证没有错误，而更加重要的是任何设计更不能保证其没有错误。一个电路设计我们可以说在理论上是合理的，但是如果谁说一个软件设计在理论上是合理的那简直就是不懂软件。对于设计最重要的一点就是能保证其正确的执行了设计的意图，并且完全的可以控制副作用。电路图我们可以在一个虚拟的环境下验证其是不是合乎我们的要求，而软件设计我们怎么验证其正确性呢？唯一的办法还是用代码的运行来验证它。而既然你已经动用了代码，为什么你会认为要尽量晚的去coding呢？

前期的设计永远都存在，任何人在coding前都要想一下。有些人习惯把问题完全想明白，然后再干。有些人习惯先干起来，通过实践把问题想明白。至少我个人认为人的脑力是有限的，单纯的凭空设想是靠不住的。当然如果你过于的在实践中投入，实际上一样有问题。而XP的好处就在于，让你必须在一个非常短的时间内见到效果，并且不断的停下来审时度势的作出新的判断。

而说到XP是不是要求有高素质的人员，我想说任何的方法都需要高素质的人，没有高素质的人任何方法都是不可靠的。而进一步我们是不是就能说只有高水准的人才能适应XP呢？我看恰恰相反，高水准的人几乎可以在任何方式下工作，而且在XP的方式下他们往往可能会感觉不舒服。
实际上XP对于人员的要求很少，一个是交流的能力要比较强，一个是要习惯遵守纪律。XP和RUP一样是一种强约束的方法，并且在我看来XP的约束更加强，其管理的严格是别的方法所不能比拟的。首先由于XP的需求的粒度本身就非常的小，普遍的就只需要2-3个小时，有些几分钟就可以实现。而在这样一个粒度下，实践中很容易就把时间给浪费了。人们太容易沉醉在完成上一个usestory的欢乐中而希望休息一会儿了。而由于xp实现的代码共有和持续集成，造成的SCM压力非常的大。目前国内的团队我认为唯一可能存在能力上困难的地方也就是缺少SCM方面的支持。但是真正的问题还在于我们是不是能严格的遵守SCM的纪律约束，是不是习惯于细小频繁的checkin/out。同时由于xp对于互相交流的依赖，使得我们在作出接口等方面的权衡能力必须要加强。这个能力的加强核心的因素不是在技术上的，而是一种人格上的。也就是你能不能有一个整体的感觉，不为了一些鸡毛蒜皮的事情在一些细节上扯皮，不为了一些莫名其妙的荣誉因素和人斗争不止。
实际上XP对于人格的要求要远远高于对技术的要求，xp可以说是一群热情高涨的、勤勉好学的新手最好的入门方法。

学习了 without EJB 中描述的容器的低侵入性以后，我现在觉得一个好的开发方法也应该具有这样的特点。一个好的开发方法应该是低侵入性和容易掌握的。XP 的各种最佳实践如果认真执行了在我看来都是有价值的。
测试驱动+重构：真正能做好了，代码的质量就有了保证。
结对编程：是一种非常有效的沟通方式。
持续集成：保证产品经常维持在一种可用的状态。
计划游戏+user story：保证要做的功能确实是用户真正想要的和对用户最有价值的。
迭代开发：保证了用户的充分参与，每次迭代结束都有新的东西给用户看，以便他们能及时提供自己的反馈意见。

也就是说，XP 的这些最佳实践从一个程序员的角度（我应该算是一个老程序员了）来看都是非常有意义的，即使不采用 XP，如果有机会我也会尝试这些最佳实践的。

但是其它的一些开发方法中的很多活动在程序员看来其意义就很值得怀疑了（例如很容易陷入政治斗争漩涡的无休止的设计评审）。如果难以充分理解这些活动的价值，就不可能真正把这些工作做好。所以我认为到目前为止，XP 是所有这些开发方法中对程序员打搅最小、侵入性最小的开发方法（当然还有人说了，我们的野球拳让程序员天天都在编程，比 XP 的侵入性更小。但是你总要有一些设施来保证产品的质量吧？）

xp 对于系统隐喻的描述过于含糊.


完全同意.



是否应该尊重个人的行为习惯. 不要强求一律, 用框框来限制人呢?

关于此， 我的意见有好几点：

1. 可以与电路图对应的软件设计， 只能是原代码， 这个观点就是那篇经典文章的观点，“ 代码就是设计”。
2.  以代码就是设计的观点来看，软件设计和其他设计的一个根本的不同在于，设计是工程活动中建造性活动的终点。 不象其他工程活动，设计是制造的蓝图， 设计的错误会导致大量的实物废品， 设计错误的代价非常昂贵。 软件的设计错误（代码就是设计的观点），是修改设计自身，以及重复测试， 错误不会向下游的制造环节延伸和扩展。
所以软件设计（代码是设计的观点），错误的代价远远小于其他工程活动中设计错误的代价。 因为错误的代价小， 软件开发对于设计错误的容忍度是相对大的。
3. 代码就是设计。 这和我们通常所说的设计显然不是一个东西。 通常的设计当然是比代码更为概略的东西。 就象写一本书， 有时需要一个提纲。对整个活动提供一个方向性的指导。 为什么需要这样的设计， 我的理解是复杂性。 因为软件设计是空前复杂的智力活动。 因为复杂， 所以设计活动分化出不同的阶段。 体系结构设计，概要设计， 详细设计， 代码， 阶段的多少， 与复杂程度成正关系。
4. 对于电路图设计， 通常都是一个人进行， 所以可以一步到位。就象我一个人写程序， 可能也是除了代码之外， 不需要其他设计的。  如果一个电路图的设计复杂到需要很多人协同设计， 我想一个概要的缺乏细节的总体设计是需要的。 不知道是否有这种情况。 我大学是 学电子工程的， 不过现在完全是做软件了，
5. 总的观点：
   代码就是设计。 设计也是设计。
   有点绕口。 第二个设计指的是： 构架设计， 高层设计，详细设计。

   它们都是设计：只是因为软件设计活动太复杂， 需要将设计活动进一步分解分化。 每一步都需要创造性。

越是紧密的协作， 对纪律的要求越高。
xp 的极短的迭代周期，使项目的 visibility 非常高。 确实对纪律的要求好象太高了。 好在是结队编程， 一个人不在状态时， 另一个可以顶上。也许结队编程本身就是舒缓压力的一个手段。

从这个意义来讲， kent beck 强调 XP 的实践要整体实施才大见威力，就是这样的互相补偿吧。

pair programming <-> 纪律的压力

我看大家如果有兴趣， 研究一下  XP 的各项实践是怎么相互支持和补偿缺陷的， 应该很有意思， 可以将对 XP 的了解深入进去， 而不是象我写这篇文章一样， 整天就围着 xp 是否要设计这样的问题绕来绕去。:-)




非常赞同。我一直说 XP 需要高素质，潜台词就是人的素质， 而不是编程的水平。 互助， 开放， 共享，民主，信任，共同的荣誉和利益。 太多的私心杂念是无法实施 xp 的。 举一个例， 没有互助与分享的精神
， pair programming 怎么实施。 没有相互的信任， review 活动很容易演化成攻击性的挑刺活动。 会议会成为某些人抓住机会表现自己的地方。

这个地方我提出一个问题：
XP的团队中怎么引入健康的竞争？ 怎么handle 利益的分配？
是否干脆就不引入内部竞争， 团队成员共同成长， 不让任何一个队员掉队， 只与外部竞争。

低侵入性， 这个值得琢磨。

比较XP 和传统方法：

XP更 依赖于 ：
    团队的完整性（ 紧密沟通，相互支持的团队成员）
    完备的自动测试
    重构
    持续集成
传统方法：
    更多的依赖好的构架和设计。