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

自上而下(Top Down)开发模式是指从一个应用的最高点开始开发。从最高点逐步往下层编码,直到开发完所有的任务。一旦写完了最下层的代码,开发任务就完成了。使用这种方式,你需要设计、编写出所有你需要的但还没有实现模拟接口、服务、伪代码。

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

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

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

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

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

分享这篇文章:
[英文原文:Top Down vs Bottom Up ]

5 Responses to 自上而下的软件开发和自下而上软件开发

  1. null says:

    自下而上的开发方式=>导致痛苦的集成过程=>解决方法是面向接口编程,TDD=>使用自上而下的开发方式

    所以自下而上的开发方式的问题在于不可以面向接口编程.
    是吗?

  2. 消失风雨中 says:

    感觉有点不对劲
    好像是理论和实际脱节,
    自上而下的的方法应该先定义接口然后实现,但通常会出现接口定义错误而导致实现出错的问题,也就是作者说的自下而上会出现的问题.
    而自下而上的方法应该是根据需求写实现,说白了,用到哪儿写到哪儿,等某一业务功能实现才会抽象出接口,这时接口一般是不会出现问题的.

    明白了,这一块
    “按照自下而上的开发方法,两个程序员将负责开发复杂的数据库查询功能。当这部分代码可以使用后,另外两个程序员将开始开发控制层和服务层。”是错的,一般这种情况都是自上而下才会出现的,因为接口定义完成了,大家认为这按这个实现不会出问题,所以把本层所有功能实现了,但是,因为没有实际的代码,接口设计过程疏忽,导致接口与实现需求不符,实现也根着出错了.

    而后面作者说的自上而下的方法,却恰恰是自下而上的方法,只不过大家一般是先写实现,再抽象出接口.

    可能是大家对自上而上和自下而上的理解不同吧

  3. 白头发乌鸦 says:

    自下而上的是设计
    自上而下的是开发

  4. 虔诚的小学生 says:

    楼主描述的是由底层开发过渡到项目架构设计的进阶过程,这个需要时间和经验进行提炼的,有参考意义!

  5. leon says:

    为什么不先规定好借口在说?

发表评论

电子邮件地址不会被公开。 必填项已用*标注

壹加壹等于