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

如果我们项目的时间跨度比较长，中间可能会有其他项目的开发（其他项目也会打上自己的分支），一般都会打上分支,命令如下：
cvs tag -b
合并我们有专门的测试工程师进行，合并脚本也算比较简单吧,主要就是下面的命令
cvs up -j

xp 不太强调设计的一个原因， 我认为是：

技术发展的成熟。 由于软件行业的各种技术手段和解决方案趋向成熟， 加上开发组织自己的积累。 所以，技术问题渐渐向焦点以外旁移， 领域问题成为考虑的重点。

我想这也是为什么会提出 MDA的一个原因。

j2ee 强调的 separation of concern， 也反映这样的趋势。

对于国内开发组织来说， 需要多少设计， 还是要看本组织的技术积累是否足够， 别人成熟不等于自己成熟。

代码 = 设计 这个等式要成立是有条件的，不是说知道了这个等式就可以想都不想直接从事编程工作，也不是说任何代码（哪怕是写的乱七八糟惨不忍睹的代码）都等于设计。要做到代码 = 设计需要付出艰辛的努力。一般来说，我认为风格良好（要有一个编程规范）、进行过多次重构，消除了大部分臭味的代码才等于设计。

水平越是低的编程人员，经验丰富的设计人员越应该为他们多做一些预先设计。不过也不应该认为编程人员在编程过程中就完全不应该做与设计有关的工作。再伟大的设计师，在设计阶段也不可能想清楚所有的细节问题，这些问题在编程过程中存在着一个再设计的过程，而且这些设计由具体做这方面开发的编程人员来做是最恰当的（他们也可以在这些细小的设计工作中提高自己的能力，以后可以胜任一些更大的设计工作）。主要的设计人员以前必须从事过大量具体的编程工作，对于自己的设计的合理性和可行性完全有把握，确信自己有把握在编程人员遇到棘手问题的时候能够迅速帮助他们脱离难关，否则就很难控制项目的进度（不好意思，我这里把设计人员和 PM 的职责搞混了，因为在我们这里其实这两个角色都是由我来担任的）。设计人员和编程人员也不应该有一个完全明显的界限，设计人员也要参与编程，编程人员也要参与设计，唯一不同的是承担不同性质的工作的比例不同。一些重要的可以重用的代码应该由主要的设计人员来编写，而外围的相对简单的代码由级别较低的程序员来承担。这样的团队组织形式其实就是我一再提到的《人月神话》中说的那种外科手术式的团队。

其实现在大家都完全同意瀑布式的开发过程是一种错误的而且代价昂贵的开发过程，迭代开发的思想已经深入人心。是否需要做预先设计、做多少预先设计都不是非常大的问题，也不是原则问题。XP 的思想其实很朴素，就是把现在已经可以做的工作（根据以往的经验，如何做已经非常清楚了）尽快地做起来，转化为用户能够见的到的功能，让用户能够充分和及时地参与进来（你什么都不做出来，他们能提一些什么意见呢？）。用户及时而充分的参与是降低项目风险、保证项目成功的关键。能够做到这一点，并且确实能够迅速应对用户提出的需求变化，就是一个成熟的软件组织了。机械地照搬 CMM、RUP、XP 其实都是有问题的。一蓑烟雨任平生曾经对我说，他发现其实还是应该由过程来适应人，而不是人来被动地适应过程。这个观点是我们在实践各种开发过程时一定要牢记的，任何开发过程都应该根据你所在的团队成员的能力适当加以变化。以前 o6z 说实施过程改进前应该已经有了一个自己的行之有效的开发过程（就是我所说的野球拳），然后再参考某种标准的开发过程加以改进。如果自己连一个基本的做事方法都没有，对于什么适合自己、自己真正需要什么样的开发过程完全没有概念，那么 CMM、RUP、XP 都不可能成为你们的救 命稻草。我们最终的目的还是获得一种能够快速应对变化同时还能保证产品质量的能力（迅速交付让用户满意的产品的能力），而不是中规中矩地实施某种软件开发过程。XP 和各种敏捷方法其实是把这种主动性交到了我们自己手里，如果我们还是只能机械地照搬，就仍然不能达到理想的效果。最后只能怨天尤人，认为自己完全没有能力解决好这些问题，于是只能把张半仙李半仙之流的算命先生找来，给自己增加一点点的心理安慰。

可不可以把代码看成是设计的一个view，就像在MVC中提到的一样。M是设计，V是代码或者其他的比如UML图之类的，C是Process.
从这个角度来讲，我觉得代码应该是设计的最好表现，因为用代码来表现设计隐含的满足了设计的可测性，可实现性的要求。
但对设计人员的要求很高，就像小说里说到的人剑合一的境界一样。 具体的项目应该有适合自己的View和Control.

这句话应该反过来说， view 从来都是抽取某些部分，忽略某些细节。

The Crystals share a human orientation with XP, but this people-centeredness is done in a different way. Alistair considers that people find it hard to follow a disciplined process, thus rather than follow XP's high discipline, Alistair explores the least disciplined methodology that could still succeed, consciously trading off productivity for ease of execution. He thus considers that although Crystal is less productive than XP, more people will be able to follow it.

看到martin  fowler 的这段话， 觉得 crystal  更人性化， 我不太喜欢纪律过于严格的过程。 有时间要看一看crystal .

代码就是设计， 意思是说， 写代码也需要创造性，也需要从无到有。

从构架设计到编码， 这一系列活动都是设计。

我想起了一句话,纪律是给不遵守它的人准备的,对于遵守纪律的人来说,纪律根本就不存在

“代码就是设计”这种说法过于笼统，代码虽然是设计的结果，但能够充分体现设计的主要还是代码的组织结构。就象写文章一样，文章的神髓不在于使用了什么华丽的辞藻，而在于作者如何有效的组织词句、段落以至章节。

我读下来和用起来地感受，XP更多是上升到了哲学的高度，在方法上他仅仅是提到了一些常用的方法

问题是什么是设计，是不是可以把从问题域到实现的抽象和映射的行为都叫做设计？
就像光谱一样，是个连续的范围，而模型和代码可能分别在光谱的两端。至于在项目中如何作，那就要看平衡的技巧了。－－不好意思，从balance the discipline and agile methodology中借用这个比喻。
代码是设计是对的，但并不是说设计就是代码和只有代码才是设计！
问题在与什么是一个好的设计？怎样去平衡？有没有一些平衡的技巧和模式可以参考和帮助判断？