自顶向下的系统设计真的好吗？

Question

今天重新翻了一下《敏捷软件开发》这本书，第六章，一次编程实践，作者讲述了自己开发保龄球游戏的整个过程，用的是测试驱动开发的方式，上来就开始写代码，一边写一边改进，也没有实现做一个完整的设计。

但是实际的业务中，接到一个项目，有经验的程序员都会先拆解任务，一个个功能考虑实现方式，最后才是开始编码，与书中提到的方式截然不同。

那么，像平时这种自顶向下的开发，真的有必要吗？我们为什么不先开发一块功能，再基于上面迭代呢？有时候拆解任务真的很费心费力，尤其是产品改需求的时候？

希望大家分享一下自己的想法

Answer 1

敏捷开发本身就是一个高速追随用户需求的开发模式，“先有再优”莫过于其核心思想之一。

如果是先定好整个系统的设计，拆解好任务，再逐个模块进行开发，等到用户真正用上的时候，也许用户需求已经变了，这时候黄花菜也就凉了。特别是互联网时代日新月异，一个功能能早日让用户用上，远比它是否完善来得重要。

另外，功能模块再难拆解，也远比废寝忘食开发出一个模块，之后因为用户需求的改变不再需要这个模块来得容易。再者，一个优秀的程序员以及合理的设计模式的使用，是不会造就一个难以拆解的模块的。

Answer 2

我是这样理解的:

区别于大公司小公司和大项目小项目。

如果一个项目开发周期三四年，敏捷开发肯定不适合，团队只追求效率上的，对产品易维护、安全等都不重视。这样问题也很大，虽说客户要求的功能实现较快，但更改的也快啊，普遍的产品经理和工程师吃亏受累。

大公司大项目从需求上就会重视，项目每个模块将采用的设计模式、算法等都最优后，才进行开发。而小公司小项目不能去拖的。。。

大多数大公司中的小项目都是外包出去，这样节约成本，改需求也很容易，不然走流程就能有几天。。。

敏捷开发对公司的利益大，对工程师产品经理等不易。现在的公司就采用敏捷开发的管理模式，代码不易维护，甚至可能要重新构建。也没有过多的人力进行安全测试，只是功能压力测一测。。。

敏捷真的是敏捷吗？我觉得是愚钝。。。

Answer 3

用什么方法还是要根据需求和条件来定。不能单纯的说某种开发方式就好。

比如有个大客户，有意向做个APP，然而需求方面不清晰，业务经理可能就是跟客户简单聊了聊说回来给他们做个DEMO。这时候肯定就不会自顶而下的设计了，因为根本不知道顶是啥样的。

只能先让设计师做UI，然后程序员直接按模块实现。

客户看了以后说哪哪要加要减去。这样来回几次才能真正了解到需求。

签了合同以后。这个时候才有了个比较完整的需求。之前的敏捷开发的东西基本就都废弃了。这会儿再自顶而下的开发。

如果一开始就扣吃技术框架层面的东西，你们可能压根就拿不上单子。 公司首要的是生存。