首先说明本文是软件开发方面，不是什么心理学、社会主义形态。

自上而下（top-down）：也称逐步设计，指从一个应用的最高点开始开发。从最高点逐步往下层编码，直到开发完所有的任务。一旦写完了最下层的代码，开发任务就完成了。使用这种方式，你需要设计、编写出所有你需要的但还没有实现模拟接口、服务、伪代码。相对于“黑匣子”，自上而下的设计方法更容易操作，“黑匣子”可能无法阐述基本的构成要素和模型。

自下而上（bottom-up）：指从一个应用的最底层开始开发。这种方式的考量在于认为最底层是应用中最复杂的部分，或者认为是最重要的部分。这种模式下系统将从一个个小模块做起，最终构建起整个系统。小模块之间是基于访问-处理而进行相互通讯，彼此间相互联系组成一个大的系统。

程序员中有些人有一些洁癖、强迫症的偏好，这并不是表示你写的代码有多强，这是一种不好的习惯，如果你养成了这种习惯，你会发现自己很难阅读别人的代码，而自己每天只能写一些小功能、小demo，同时自己写的小功能、小demo别人一样也看不懂。

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

• 创建控制层(controller) – 主访问入口，请求映射表。
• 创建服务层(service) – 服务层，简单业务逻辑。
• 数据库查询 – 复杂的数据库查询。

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

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

// 数据库接口和服务层要求不一致
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开发，我们的测试代码最终会驱动对这些模拟功能的真实实现。顶层的业务逻辑的确定决定了底层的数据服务接口，如果在底层需要增加一个新类，这很容易，它只是底层的实现，不会影响上层的业务流程。

即使是以后自己写框架，往往很多事情不是一步到位，我们需要什么，可能是未知的，我们就用一个“假的”对象或者接口作为代替，当大部分东西都凑齐了，再来编写那些“假的”对象或接口。

自上而下、自下而上的软件开发