关于设计的可扩展性。

我也发现我没回到正题上。

客户让你频繁的选择abcde第一种可能是他不是在你开发过程中给反馈，第二种是没有责任心。
一个有责任心的现场客户会很清楚什么地方要考虑到可扩展性，由客户提出，而不是开发人员自作多情，所以说开发人员在不了解业务的情况下把这个权利（总有人说这是责任，可能也是统一对立的东东吧）给现场客户。
现场客户说这里要做成可扩展的，开发人员就做，否则根本不考虑可扩展性。
所以说一开始不做成可扩展的，直到现场客户提出。

具体实施很难出现这种现场客户，不过我想不是xp的错，而是xp的适用条件可能在大陆有点苛刻而已。就只能见找拆招，尽量弥补了，或者根本放弃掉xp。

感觉xp团队是由一批相当自信且有能力的人组成的，它强调人的作用.
我想只要是个做软件的,没有人不会考虑扩展性.

其实，客户是不知道什么是"可扩展性"的。客户只能提出现实的业务需求，以及可能的变化。仅仅做到这一点，就需要一个非常好的需求调研人员了。
可扩展性只是在技术实现上的一个术语，虽然和业务相关，但是区分业务不同部分的稳定性/易变性，是需要设计者、调研者自己去做或者引导客户去区分的，至于怎么通过技术方法来应对，这和客户一点关系没有。
在项目的实施过程中，可扩展性是一个折中。对开发团队而言，需要考虑的是在开发周期 （验收之前）中不会因为架构设计在扩展性上考虑不足而在后期导致较大困扰。而对于信息部门而言，可扩展性从某种意义上来说远不如可集成性重要，或者说系统有较为完整的开放接口才是真正必须的。

现在谈谈第2点 -- 整体的设计和组件的划分

设计的可扩展性 一般表现在有限定制上

1 确定整个系统的接口(通讯方式 联系) 选择合适的技术和标准. 画草图是最实用的办法.

2 分割. 依靠你的业务经验 和客户的模糊需求 将系统分为相对独立的单元组件 用最简炼的语言描述每个单元的功能.

3 确定每个单元的 定制选项(根据您的经验和客户的需求)

4 权限系统
这个系统应该是完全独立的 不要将它和特定的组件关联. 在开发初期可以暂时不考虑 在最后加上. 

5 让每个小组 去决定组件的 交互 编码 数据库设计.

估计有人要骂我了. 数据库能随便设计? 多个组件共用一个数据怎么办 ?
其实这么做是大有好处的

(1)路是大家走出来的. 先看看那里被踩平了 再修路.

(2)互相不干扰 交流(打架)越少 工作越有效率.

(3)方便随时修改 测试.

(4) 保存原始的完整性 可以被重用.

有点黔驴技穷了 希望大家多多介绍自己的开发经验

由于个人表达能力问题，需要说明一下，我说过的这句是反话：
“而且，我们自信是最正宗的XP了， 因为我们的XP是CTO在UNCLE BOB的培训班学来的 ：）”

我的意思是同 “一蓑烟雨任平生”一样的，
不支持charon和DDD的XP必须要严格做到12条军规的说法，
当然其前题是我们敬重XP前辈的经验教训，理解每一条军规的作用与目的， 但是在有些时候，若是真的不合适，个别条也只能放弃了。必竟不能为了XP而XP。

在实践中，在项目前期，由于项目组新手较多，基于XP他们根本不明白要做什么，结果就是有那么一段时间，我们竟然变成了UP！

对我来讲，常规设计中的注重可扩展性，与XP中不要设计过度并没有冲突，比如说，若是我觉得有必要预留一个扩展接口，我会和客户讨论把它加到UAT中。
若是客户不愿意，而自己又觉得真的需要，那就自己加到UNITTEST中好了。

to rtdb:
嘿嘿，我都不知道什么是12条军规，可能我的路子比较野一点。
很乐意和有xp实战经验的人谈话。

关于自己要做点可扩展性的东西，那么以后更改的时候时刻都要记住这里的可扩展性不能变，还要直接干涉客户的测试，感觉没必要。

to charon:
现场客户确实不知道开发人员如何设计的，仅仅说：“将来这里要如何如何”，这个时候开发人员就说：“那这里为将来留出余地么？”，现场客户就说是或者不，这种为不为将来留余地就是业务方的业务上的决定，开发方根据这个决定做出设计上是否有可扩展性的决定。

hehe,那个12条军规完全是调侃。只是XP教科书那么说的，我并不是个xper.......，我只喜欢其中的有限几条。
但是从严格的角度说来，如果不符合12条军规，可以说自己在实践敏捷，但最好不要说是在XP. RUP经过裁剪以后还可以称为RUP，而XP的裁剪度有限得多。



如果是偶们的业务人员，这个时候就会回答：当然要留出余地了。
此时，调研人员又会谈论起代价来，但这个问题显然和业务人员缺乏沟通手段。而且，关键的一点是合同里面不会定得那么详细，显然不可能根据合同来否决这样的要求。一般来说，稍微大一些的项目，都是在合同签订之后才会进行实质性的需求，以前我见到过在合同开标之前请几家厂商来进行一周左右的需求调研的例子，但那不可能细节到某个程度。
所以说，在这类项目型开发中，可扩展性也几乎是开发方的责任，很难从业务方借到一个着力点。