|
锁定老帖子 主题：关于设计的可扩展性。
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-01-18
zidoing 写道 如果任何扩展性的设计都不可取，那么应付后期需求变化的成本会不会很高呢？我想关键是我们能否找到一个充分的证据支持，而对业务的熟悉应该算是一个吧。
我说的是xp，并且是极端的xp。我个人认为xp对应付后期需求变化的对策是重构，甚至极端情况下有可能大规模重构，取决于重构手段够不够凌厉。并且xp中程序员和业务方是彻底分离的。对业务的熟悉度应该是其他方法要求的。 个人见解，并且xp不代表所有的东西。 |
| 返回顶楼 | |
|
发表时间：2005-01-18
ddd 写道 gigix 写道 xper本质上讨厌拍脑袋的“可扩展性”。“可能要想到……”，凭什么想到？是你自己想出来的，还是用户需求提到的，或者是做类似项目总结的经验？发生这个可能性的概率有多少？没有充分的证据支持，你就不应该提供“可扩展性”，客户给你钱不是叫你去玩设计的。 按我个人对xp的理解，任何可扩展性的设计都不可取。 我个人对xp的理解就是从局部到整体，没有什么整体上的设计，也不谈任何可扩展性。 那么就是你的个人理解出了偏差。 |
| 返回顶楼 | |
|
发表时间：2005-01-18
weihello 写道 那我们还谈XP做什么？扔了....... 空谈可扩展性是没有任何意义的，他来自客户需求/经验/Refactoring。 需求： 客户说：通常我们做销售都要打一定的折扣，一般来说老客户打8折，新客户打9.5折。这些都不体现在账户上.......呃，对了，个别客户是直接返现金。 调研人员： 有没有其它的打折方式 客户说： 呃.........暂时没有了，不过我也不确定，等我想到后告诉你 这就是需求，你要灵活的打折策略，就需要所谓的可扩展性。 经验： 上述调研人员就敏觉的嗅探到了打折策略的不确定性，他知道在这儿多下些功夫了。 Refactoring： 打折策略代码如果最初仅仅支持固定几种，而且难以扩展，而打折策略在变化，代码在腐化过程中，有人会Refactoring之，并且让他越来越适应打折策略的变化。 在你这个例子中，我认为如果采用XP的话，应当反对扩展和预先考虑。 另外，要注意XP中业务需求和技术实现两者互相独立的事实，业务需求方不应当把不明确或可能的要求传递给技术实现方，由技术实现方去考虑扩展，这个是不负责任的做法。 |
| 返回顶楼 | |
|
发表时间：2005-01-18
扩展性（好大的话题）
这三个字怎么解释，怎么才算扩展性？系统的扩展性？还是指业务逻辑可以方便的改变？ 咱们具体谈谈： 有一个CMS，原来的操作是管理员添加新闻，然后新闻发布在在网站上 后需求变化： 发的新闻需要负责人这个权限的人审批以后才可发出 后需求再变化： 某些人发的新闻无需审批，有的需要审批才可发出 。。。。。（后又产生了许多需求变化） 我觉得人们很难预知需求，我们能作的仅仅是让代码尽可能的脱藕，尽可能的单独调试，尽可能的达到组件式的拼装，尽可能的在出现需求变化以后可以尽快的适应需求完成需求。 而对于替用户多想一些没有提到的功能，那么就要深入领域，深入行业，才能超前想出一些功能。 个人想法，大家继续：） |
| 返回顶楼 | |
|
发表时间：2005-01-18
XP理论上不要做过头的事情。但要看度，一种权衡
如果是要你设计一套复杂的规则系统，那是不现实的。 但也要分场景的，在条件和变量范围可以确定的情况下，一个简单的扩展显然受益无穷。 这是有经验和无经验的两种截然不同的反应。 |
| 返回顶楼 | |
|
发表时间：2005-01-18
weihello 写道
我个人对xp的理解。 它在赌：需求的变化使任何可扩展设计都无能为力，那么便不用可扩展设计。 它还在赌：扩展性的设计能扩展出来的功能，重构时候一样扩展出来，并且不花费太多的功夫。 |
| 返回顶楼 | |
|
发表时间：2005-01-18
清风 写道 扩展性（好大的话题）
这三个字怎么解释，怎么才算扩展性？系统的扩展性？还是指业务逻辑可以方便的改变？ 我觉得所谓的设计扩展性（技术层面）是这样的： 当业务方明确一个要求的时候，技术实现方可以用相对较快的速度将其实现并发布。 |
| 返回顶楼 | |
|
发表时间：2005-01-18
ddd 写道 我个人对xp的理解。 它在赌：需求的变化使任何可扩展设计都无能为力，那么便不用可扩展设计。 它还在赌：扩展性的设计能扩展出来的功能，重构时候一样扩展出来，并且不花费太多的功夫。 我的理解和你略有差异： 我认为xp主要是针对技术实现而言的，对于业务需求而言谈的较少。 因此稍稍修改如下： 需求不明确时，（技术实现者预先考虑的）可扩展设计投下的成本和期望效益比 < 需求明确时，（技术实现者）重构的成本和期望效益比 |
| 返回顶楼 | |
|
发表时间：2005-01-18
ddd 写道 weihello 写道
我个人对xp的理解。 它在赌：需求的变化使任何可扩展设计都无能为力，那么便不用可扩展设计。 它还在赌：扩展性的设计能扩展出来的功能，重构时候一样扩展出来，并且不花费太多的功夫。 XP不是随便找几个会写代码会重构就可以成立团队的，它是有纪律和有组织的，团队本身内部提供了互相咨询，他们之间有经验的差别，有认识事物的能力差别。 很多东西是潜在的，虽然一些经验尚浅的人不具备。比如，代码上如接口编程，再比如业务上一些细节，新手显然没有注意，但是无需客户交流，有经验的成员还是会告知并更正。 所谓的不可知的扩展，无论什么开发方法学都是无法避免的。你的这种做法显然两眼一摸黑的XP类型的。 |
| 返回顶楼 | |
|
发表时间：2005-01-18
clamp 写道 ddd 写道 我个人对xp的理解。 它在赌：需求的变化使任何可扩展设计都无能为力，那么便不用可扩展设计。 它还在赌：扩展性的设计能扩展出来的功能，重构时候一样扩展出来，并且不花费太多的功夫。 我的理解和你略有差异： 我认为xp主要是针对技术实现而言的，对于业务需求而言谈的较少。 因此稍稍修改如下： 需求不明确时，（技术实现者预先考虑的）可扩展设计投下的成本和期望效益比 < 需求明确时，（技术实现者）重构的成本和期望效益比 呵呵，一般来说，我们的程序员对业务谈得比技术上多，除了技术新手。 在迭代周期内，我们花在业务讨论上的时间是技术上的数十倍。 |
| 返回顶楼 | |
