自上而下和自下而上开发策略的实际模型有哪些

自下而上(Bottom up)开发模式是指从一个应用的最底层开始开发。这种方式的考量在于认为最底层是应用中最复杂的部分，或者认为是最重要的部分。这种模式下系统将从一个个小模块做起，最终构建起整个系统。

我在上大学之初就听说了自上而下开发模式和自下而上开发模式。当时我并没有在意它们的区别——因为就是一个彻头彻尾的自下而上开发的程序员。

然而，随着阅历的积累，我慢慢的完全改变了我的立场。我认为，是敏捷开发和TDD让我发生了这样的变化。我非常强烈的感觉到，我想对每个人大声说：在一个敏捷开发团队里，自下而上开发是反模式的。

假设有一个四个人的开发团队，要完成一个Web应用中的下列这些任务。

1,创建控制层(controller) – 主访问入口，请求映射表。

2,创建服务层(service) – 服务层，简单业务逻辑。

3,数据库查询 – 复杂的数据库查询

按照自下而上的开发方法，两个程序员将负责开发复杂的数据库查询功能。当这部分代码可以使用后，另外两个程序员将开始开发控制层和服务层。

这种开发模式的问题来自痛苦的集成过程。开发服务层的程序员写代码时很有可能无法遵守最初计划时团队制定的接口规范，这样，复杂数据库查询开发的程序员就不得不修改他们的查询接口。

// 数据库接口和服务层要求不一致

query.Execute(id)

// 数据库层的实现是这样的。

query.Execute(id, typeId)

这是一个很简单的例子，但你可以想象一个含有30多个小任务的story的情况，有更多的程序员参与，更复杂的业务，这时自下而上的模式就很麻烦了。

经过过去这些年的开发，我开始转变成使用自上而下的开发模式。我的第一步开发动作是用假方法模拟出流程中需要的底层接口、服务实现。里面没有真正的逻辑，只实现了对象间交互需要的部分。在这个开发阶段里没有测试，没有TDD。因为里面没有逻辑。代码非常简单，很方便让同伴进行代码审查和计划实现。

// 控制器方法

public Result Index(IncomingRequest incomingRequest)

{

var res = service.Invoke(incomingRequest.X, incomingRequest.Y)

return new Result(res)

}

// 服务层方法

public QueryResult Invoke(int x, int y)

{

return query.Execute(x, y)

}

// 数据库查询方法

public QueryResult Execute(int id, int typeId)

{

// 这里没有数据库查询逻辑，这是只是一个空的模拟接口。

return new QueryResult()

}

这样一来，任何一个程序员都可以自由选择开发任何一项任务。如果接口需要改变，则不会发生自下而上模式中的那种依赖另外一组程序员修改进度的情况。另外一个好处是，从一开始，任何一个功能点都是可以做用户测试的。

自上而下的开发方便每一步都采用TDD开发。每一阶段开发有各自的测试程序，这保证了各个对象间协作逻辑的正确，保证了业务逻辑实现的正确。之前我说过最初的底层模拟阶段是没有测试的。但这不意味着我们没有对它们做TDD开发，我们的测试代码最终会驱动对这些模拟功能的真实实现。顶层的业务逻辑的确定决定了底层的数据服务接口，如果在底层需要增加一个新类，这很容易，它只是底层的实现，不会影响上层的业务流程。

这种自上而下的开发方法并不是一个新事物，然而有很多人仍然没有看到它的好处。我计划在随后几个月里对这种实用主义风格的TDD做进一步的讨论。

“自上而下”的设计从某个很高的抽象层次开始。你定义出基类或其他不那么特殊的设计元素。在开发这一设计的过程中，你逐渐增加细节的层次，找出派生类、合作类以及其他更细节的设计元素。

“自下而上”的设计始于细节，向一般性延伸。这种设计通常是从寻找具体的对象开始，最后从细节之中生成对象以及基类。

自上而下策略和自下而上策略的最关键区别在于，前者是一种分解（decomposition）策略而后者是一种合成（composition）策略。前者从一般性问题出发，把该问题分解成可控的部分。后者从可控的部分出发，去构造一个通用的方案。

自上而下设计的强项是它简单，因为人们是很善于把一些大食物分解为小的组件，而程序员更是精于此道。

自上而下的另一个强项是你可以推迟构建的细节。软件系统常常受到构建细节变化的骚扰，因此，尽早知道应该把这些细节隐藏在继承体系的底层类中，是非常有益的。

自下而上的一个强项是通常能够较早找出所需的功能，从而带来紧凑的、结构合理的设计。

自下而上的一个弱项是很难完全独立的使用。

1）自上而下的项目预算

这种预算方法的是，当上层的管理人员根据他们的经验进行的费用估计分解到下层时，可能会出现下层人员认为上层的估计不足以完成相应任务的情况。这时，下层人员不一定会表达出自己的真实观点，不一定会和上层管理人员进行理智地讨论，从而得出更为合理的预算分配方案。在实际中，他们往往只能沉默地等待上层管理者自行发现问题并予以纠正，这样往往会给项目带来诸多问题，有时甚至导致项目失败。

自上而下方法的优点主要是总体预算往往比较准确。其次，由于在预算过程中，总是将既定的预算在一系列工作任务间分配，避免了某些任务获得了过多的预算而某些重要任务又被忽视的情况。

（2）自下而上的项目预算

自下而上的预算方法要求全面考虑所有涉及到的工作任务。和自上而下预算方法一样，自下而上预算方法也要求项目有一个详尽的WBS。自下而上预算方法也涉及到一定的博弈形势。例如，当基层估算人员认为上层管理人员会以一定比例削减预算时，他们就会过高估计自己的资源需求。这样又会使得高层管理人员认为下层的估算含有水分，需要加以削减，从而陷入一个怪圈。

自下而上预算的优点是，基层人员更为清楚具体活动所需的资源量。而且由于预算出自于基层人员之手，可以避免引起引起争执和不满。

---