关注微信 ：javalearns 随时随地学Java
或扫一扫
我在上大学之初就听说了自上而下开发模式和自下而上开发模式。当时我并没有在意它们的区别——因为就是一个彻头彻尾的自下而上开发的程序员。
然而，随着阅历的积累，我慢慢的完全改变了我的立场。我认为，是敏捷开发和TDD让我发生了这样的变化。我非常强烈的感觉到，我想对每个人大声说：在一个敏捷开发团队里，自下而上开发是反模式的。
假设有一个四个人的开发团队，要完成一个Web应用中的下列这些任务。
- 创建控制层(controller) – 创建服务层(service) – 数据库查询 – 按照自下而上的开发方法，两个程序员将负责开发复杂的数据库查询功能。当这部分代码可以使用后，另外两个程序员将开始开发控制层和服务层。
这种开发模式的问题来自痛苦的集成过程。开发服务层的程序员写代码时很有可能无法遵守最初计划时团队制定的接口规范，这样，复杂数据库查询开发的程序员就不得不修改他们的查询接口。
这是一个很简单的例子，但你可以想象一个含有30多个小任务的story的情况，有更多的程序员参与，更复杂的业务，这时自下而上的模式就很麻烦了。
经过过去这些年的开发，我开始转变成使用自上而下的开发模式。我的第一步开发动作是用假方法模拟出流程中需要的底层接口、服务实现。里面没有真正的逻辑，只实现了对象间交互需要的部分。在这个开发阶段里没有测试，没有TDD。因为里面没有逻辑。代码非常简单，很方便让同伴进行代码审查和计划实现。
这样一来，任何一个程序员都可以自由选择开发任何一项任务。如果接口需要改变，则不会发生自下而上模式中的那种依赖另外一组程序员修改进度的情况。另外一个好处是，从一开始，任何一个功能点都是可以做用户测试的。
自上而下的开发方便每一步都采用TDD开发。每一阶段开发有各自的测试程序，这保证了各个对象间协作逻辑的正确，保证了业务逻辑实现的正确。之前我说过最初的底层模拟阶段是没有测试的。但这不意味着我们没有对它们做TDD开发，我们的测试代码最终会驱动对这些模拟功能的真实实现。顶层的业务逻辑的确定决定了底层的数据服务接口，如果在底层需要增加一个新类，这很容易，它只是底层的实现，不会影响上层的业务流程。
这种自上而下的开发方法并不是一个新事物，然而有很多人仍然没有看到它的好处。我计划在随后几个月里对这种实用主义风格的TDD做进一步的讨论。
关注微信 ：javalearns 随时随地学Java
或扫一扫
随时随地学Java
文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92024 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！