关于设计的可扩展性。

别在纸上谈兵了，实际情况要复杂得多。

这也算是设计？

这不是设计，这是要求，包括未来可能的变化。
问如何通过可扩展的设计来满足这种要求。

ozzzzzz说扩展性有设计支持业务的可扩展性和设计支持结构的可扩展性两个方面的问题。
业务用折扣来举例，也许这个例子很特殊。因为在设计的时候计算折扣应该用一个函数实现，比如getZheKou，以后出现更改就在这个函数里改好了，但我觉得这种可扩展性并不是特意设计出来的，按我的意思这个属于模块划分带来的可扩展性。也就是说这种可扩展性不用动什么脑子，也谈不上玩设计。应该不在讨论范围内。

但如果出现其他情况不是折扣getZheKou能够解决的，就是说在这个函数里改代码也无法解决问题，立马带来所谓的结构的变动，更改/增加成员变量，更改/增加类等。为了应付这种可能带来结构的变动可能就要玩设计了，这种可扩展性是要动脑子的，并且可能是白花力气的。
我的关于"设计支持业务的可扩展性"个人结论是：设计支持业务的可扩展性在某些地方上可以通过常规手段比如封装到函数里解决，某些必须用专门的设计解决，前者是自然而然做到的，在你没为可扩展性而设计就已经这么做了，完全可以重构，而后者是违背xp的精神的。
推出的个人结论是：
1.当你心中专门想到了可扩展性而为可扩展性而对整体结构进行设计的时候，违背xp精神
2.当你根本没专门想到可扩展性就在设计编码的时候，你仍然在下意识的做着某些可扩展性的设计，同时在重构的时候，也在下意识的做着某些可扩展性的设计
3.专门做不更改结构的可扩展性设计没有必要性。既然都不更改结构，重构的过程还能够做很多可扩展性的设计(比如消除冗余代码)，那么在扩展的时候重构也一样能解决问题。
所以根本不用专门做可扩展性设计，脑子里根本就不用想这个东西。

btw：给帮助系统预留的可扩展性设计在我看来既不属于业务的可扩展性也不属于结构的可扩展性。我的个人想法是对可扩展性设计可能无法简单分类。

设计中的折扣问题往往都非常复杂，我一般都要求设计成为一种可订制的方式。当然在项目的初期迭代不需要这样的高级功能，但是在完成的时候这样的功能就必须具备。
我们谈xp和其他的任何方法论都要本着实事求是的态度出发，而不是说“要是怎么怎么了就违反了什么什么方法的原则”。这样的说法除了研究，没有任何的实践意义。
回到折扣这个问题，在很多没有经验的人看来我们只要把客户要求的作出了就行了，所以折扣这个问题可以不需要那么较真。但是实际上对于折扣这样的问题，存在一个功能设计的问题，而不是单纯的设计实现的问题。客户的需求不完整机会是注定要发生的，我们不能因为我们使用xp就忽视这个普遍性的问题。折扣并不是简单的通过一个函数就能解决的问题（当然在初期的迭代使用一个函数就可以了），而是存在着复杂的商业逻辑和时间逻辑，计算方式也经常性的会被调整，这样的问题客户往往会认为是天经地义的，所以经常不被他们显性的提出来，而你如果没有行业经验，往往就会在这个地方范错误。
业务的可扩展性设计必须是你专门的，针对性的，尽量周全的进行考虑，xp和其他敏捷方法只是能更好的提供一个开放者掌握行业经验的平台，但是具体的行业知识还是需要你去进行学习。

在做的过程中现场客户会发现折扣太简单这个问题，从而要求你改正，如果客户没发觉折扣这里设计的太简单了，那么就不用做。如果现场客户根本就不知道你做折扣这里用的什么商业逻辑和时间逻辑，是沟通不力吧。
>>这样的问题客户往往会认为是天经地义的，所以经常不被他们显性的提出来，而你如果没有行业经验，往往就会在这个地方范错误。
所以要沟通，所以要现场客户，在有现场客户的情况下，关于折扣的设计会被现场客户拍板敲定，已经不涉及可扩展性设计了(除非现场客户在这里要求你一定要做这种可扩展设计，但在这个时候需求已经确定，不再模糊)。
>>我们谈xp和其他的任何方法论都要本着实事求是的态度出发，而不是说“要是怎么怎么了就违反了什么什么方法的原则”。这样的说法除了研究，没有任何的实践意义。
把研究(这个词语有点大了)和实践没必要分那么开，我说的那句也不是定论，个人意见(或者说临时的想法)而已。实践过程中如果发现有问题，不一定是方法论的问题，所以还是需要研究的。有个比喻：程序运行有问题，程序本身错误或编译器错误都是有可能的，就得研究一下。
>>业务的可扩展性设计必须是你专门的，针对性的，尽量周全的进行考虑，xp和其他敏捷方法只是能更好的提供一个开放者掌握行业经验的平台，但是具体的行业知识还是需要你去进行学习。
暂时不谈有无必要为业务的可扩展性进行专门的设计，单单业务的可扩展性设计就可能带来结构上的可扩展性设计。

不是很同意，我们做项目应该为用户带来最大利益，即使是现场客户也很可能不理解目前的设计结构上的对扩展业务的影响，开发方的行业经验必不可少，开发方需要在业务上具有一定的预见性，并向客户阐述各种设计的利弊。我们只能要求现场客户的主要职责是回答问题，不能要求现场客户会发现你的设计的问题。

"我们只能要求现场客户的主要职责是回答问题，不能要求现场客户会发现你的设计的问题。"

赞同！

这里关于折扣问题如果没人提出来，是开发方的责任，不是现场客户的责任，但开发方提出后现场客户没解答或解答错误，是业务方责任。
如果这个问题可以通过业务方做的测试发现，而没有发现，是业务方责任，如果做测试也无法发现，那情况可能就多了。

业务方回答你：折扣以后肯定要变，但是我不知道怎么变。
你怎么办？

不能把所有的责任都交给现场客户的，毕竟他也只是客户的一个代表而已，
业务逻辑的整理是很困难的一件事情，所以需要有领域专家。