关于设计的可扩展性。

我想设计的可扩展性应该是基于对业务深入理解的基础上。如果只是按照需求说明书上，该做什么就做什么，那样能有扩展性吗？

有啊，需求的变得时候你的设计也跟着变不就扩展了么？

“可扩展性”在我的理解是能在需求发生变化的时候以最小的代价去应付变化。如果你对业务不是很理解，能做到这种预先留下余地吗？

那你就去熟悉业务喽

我想可能还有用户操作习惯这些应该也属于需求吧。
用户操作习惯可能要跨行业了，比如你设计界面过程中可能要想到用户将来可能在这里加个菜单项，你就得想到可能要改动数据结构来支持这个菜单项，怎么办？预留呗，就是可扩展设计了。
自然，xper本质上是讨厌专门的设计成可扩展的。

xper本质上讨厌拍脑袋的“可扩展性”。“可能要想到……”，凭什么想到？是你自己想出来的，还是用户需求提到的，或者是做类似项目总结的经验？发生这个可能性的概率有多少？没有充分的证据支持，你就不应该提供“可扩展性”，客户给你钱不是叫你去玩设计的。

按我个人对xp的理解，任何可扩展性的设计都不可取。
我个人对xp的理解就是从局部到整体，没有什么整体上的设计，也不谈任何可扩展性。

设计是为了满足需求，但是需求是可以有可扩展性的。

决定要做什么的那一方，是可以拍脑袋想可能的扩展功能的，只要给出合适的优先级。

而实现的那一方，则应当避免这种倾向。

如果任何扩展性的设计都不可取，那么应付后期需求变化的成本会不会很高呢？我想关键是我们能否找到一个充分的证据支持，而对业务的熟悉应该算是一个吧。

   那我们还谈XP做什么？扔了.......

   空谈可扩展性是没有任何意义的，他来自客户需求/经验/Refactoring。

需求：
  客户说：通常我们做销售都要打一定的折扣，一般来说老客户打8折，新客户打9.5折。这些都不体现在账户上.......呃，对了，个别客户是直接返现金。
  调研人员： 有没有其它的打折方式
  客户说： 呃.........暂时没有了，不过我也不确定，等我想到后告诉你

  这就是需求，你要灵活的打折策略，就需要所谓的可扩展性。

经验：
  上述调研人员就敏觉的嗅探到了打折策略的不确定性，他知道在这儿多下些功夫了。

Refactoring：
  打折策略代码如果最初仅仅支持固定几种，而且难以扩展，而打折策略在变化，代码在腐化过程中，有人会Refactoring之，并且让他越来越适应打折策略的变化。