关于 软件设计 OOP 和 迭代进化

[whatisnew]

有过很多开发经验的人应该都知道，软件开发一开始的需求都是预估的。

在这样一个预估的需求下进行(重度OOP)设计，但是，快速迭代时，需求三天一小变，五天一大变，那么很快发现就这种(重度OOP)变成了累赘。。。严重拖慢了开发效率，产生了大量的废弃接口，不停的变更设计模式

那么就引申出来了两个问题：

1. 软件是迭代进化来的
2. 还是设计出来(足够满足三天一小变，五天一大变的业务需求)的

这里的 “迭代进化” 可以理解为：当原设计满足不了业务需求时，不停的小面积对系统进行重构

[endrollex]

设计的本意是计划、规划，进行预先的构思，也就是软件构架，更换那就是重构了，需求和功能都是构架设计下留有足够余地能方便实现，频繁变化说明设计本身有缺陷

[lxrmido]

有本书：《恰如其分的软件架构》，对这个问题有比较详细的探讨，不过，变得这么频繁的话，肯定是哪里出错了吧

[sivacohan]

变化这么频繁。需要确定是需求从宫保鸡丁变成了水煮鱼。还是最开始人家要满汉全席，你给理解为了沙县小吃。

[whatisnew]

我说的 “三天一小变，五天一大变”，不是字面意义上的每3〜5天就变

大家可以理解成：三天(＝3〜6个月)，五天(＝一年左右)

小变，比如：
一个 b2c 业务，原本结账需要用户授权，现免授权（但是在结构页增加了很多非预期字段）
大变，比如：
一个 b2c 业务，改成 b2b2c 业务。。。

[victor]

设计的目的就是让你将来在需求变化的时候，改起来更容易点。

[cover]

是 oop设计有问题， 一般不是先做接口，再设计类，接口一般不太变化，类的实现大量变化很正常，如果接口一直在动，就有问题了把，只要接口不动，和接口相关的代码就独立开发就好了。。

[abcfyk]

@whatisnew 这种我倒觉得其实设计阶段是应该要有预见到的。我和6L观点类似。接口设计应当满足未来一段时间需求（可能发生的）变化。接口内部方法设计只要做到松耦合，高内聚，我觉得程序的寿命会延长许多。

以PHP为例
interface CheckOut{
//...
public function getGoodsBySkuIdList($skuIdList);
public function validateGoodsIsSalable($goodsIdList);
public function checkOutMain(...);
}

class CheckOut implements CheckOut{
public function getGoodsBySkuIdList($skuIdList){
//...
}
public function validateGoodsIsSalable($goodsIdList){//...}
public function checkOutMain(...){//...}
}

PS: PHP是世界上最好的语言。 ：）

[bdnet]

没有银弹，主要还是看需求吧，如果这个需求每天都可以拍脑袋就改了，那么怎么设计都没用吧。。。这时候还是先画草图，明确核心业务逻辑才能进入具体设计和coding。这就是软件开发流程啊，不管是传统开发流程，还是 XP 都需要划清个个边界，将需求变更控制在一个范围内。不要忘了软件最擅长做的是有规律的可重复的事情，这一过程也就所谓的信息化。

[cb269267]

多健壮的代码都不可能从一而终始终不变，现在的快速迭代模式下，程序得不到良好设计的根本原因是都是谓的pm（product manager）和各种所谓的拍板人事，他们只会纸上谈兵，天天分析趋势，各种我觉得我认为的需求，project manager的能力才软件产品负责人必需的，否则你的产品火了起来，却持续不下去，经不起几轮需求变更就耦合得无法进行修改了