30 | 程序库的设计：Moco是如何解决集成问题的？

郑晔

你好，我是郑晔！
经过前面内容的讲解，我终于把软件设计的基础知识交付给你了，如果你有一定的经验，相信有很多东西你已经可以借鉴到日常工作中了。
但是对于一些同学来说，这些知识恐怕还是有些抽象。那在接下来的几讲中，我会给你讲几个例子，让你看看如何在日常的工作中，运用学到的这些知识，巩固一下前面所学。
我在第 9 讲说过，学习软件设计，可以从写程序库开始。所以，我们的巩固篇就从一个程序库开讲。这是我自己维护的一个开源项目 Moco，它曾经获得 2013 年的 Oracle Duke 选择奖。
Moco 是用来做模拟服务器的，你既可以把它当作一个程序库用在自动化测试里，也可以把它单独部署，做一个独立的服务器。我们先来看一个用 Moco 写的测试，感受一下它的简单吧！
public void should_return_expected_response() {
  // 设置模拟服务器的信息
  // 设置服务器访问的端口
  HttpServer server = httpServer(12306);
  // 访问/foo 这个 URI 时，返回 bar
  server.request(by(uri("/foo"))).response("bar"); 
  
  // 开始执行测试
  running(server, new Runnable() {
    // 这里用了 Apache HTTP库访问模拟服务器，实际上，可以使用你的真实项目
    Content content = Request.Get("http://localhost:12306/foo")
      .execute()
      .returnContent();
      
    // 对结果进行断言
    assertThat(content.asString(), is("bar"));
  });
}
这一讲，我就来说说它的设计过程，让你看看一个程序库是如何诞生以及成长的。
集成的问题不知道你有没有发现，阻碍一个人写出一个程序库的，往往是第一步，也就是要实现一个什么样的程序库。因为对于很多人来说，能想到的程序库，别人都写了，再造一个轮子意义并不大。
但是，这种思路往往是站在理解结果的角度。其实，程序库和所有的应用一样，都是从一个要解决的问题出发。所以，在日常的繁忙工作中，我们需要偶尔抬头，想想哪些问题正困扰着我们，也许这就是一个程序库或者一个工具的出发点。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

Moco：从问题出发的程序库设计 Moco是一个用于解决集成问题的程序库，通过作者的经历介绍了Moco的设计过程。作者在工作中遇到集成问题，因此决定开发一个模拟服务来解决这一问题。Moco的设计核心模型包括RequestMatcher和ResponseHandler，使得Moco可以灵活地组合各种HTTP元素，成为一个通用的解决方案。随着需求的不断出现，Moco的能力也得到了极大的提升，包括支持配置文件、proxy功能、template功能、match功能、mount功能以及REST能力。通过不断的扩展，Moco从一个静态设置的模拟服务器变成了一个能够动态配置的模拟服务器，能力得到了进一步提升。文章强调了软件设计是关注长期变化的学问，而一个好的设计应该找到一个最小的核心模型，所有其他的内容都是在这个核心模型上生长出来的。最后，作者鼓励读者注意发现身边的小问题，并用程序库或工具解决它。 Moco的设计过程生动展示了如何从实际问题出发，通过不断扩展和优化，解决集成问题的技术特点。这篇文章对于想要了解Moco设计思路和技术特点的读者来说，是一次深入而有启发性的阅读体验。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《软件设计之美》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(11)

最新
精选

人间四月天
真的很精辟，开发工作是很讲究套路的，从问题，需求，方案，设计，发现问题很关键，太多开发，眼睛里看不到问题，重复开发，功能不复用，不扩展，性能差，开发效率慢，系统质量低，工作中有太多的痛点，痛点即是问题，不追求问题本质，不勤于思考的开发，就是推代码，能跑就行，不管后续维护。如果发现不了问题，更谈不上解决问题，解决方案和设计，就是解决问题，需要积累经验，不断学习，实践，提升解决问题的能力，只有把发现问题和解决问题都做好的开发，才能成为架构师或者leader，更上一层楼。
作者回复: 总结得很好！
2020-08-05

13
Edison Zhou
老师这篇的讲解方式很像是一个TDD的案例，先从一个最基本的测试入手，它代表了一个最小化的核心模型，剩下的就是不断的迭代地去实现它并让测试通过。在不断地迭代中，让测试通过的同时，也在不断地进行重构，“抽丝剥茧”+“分离关注点”，最后形成一个好的设计。
作者回复: 你找到重点了。
2021-01-04

6
业余爱好者
记得不错的话，spring mvc test里面也有相似的概念，如RequestMatcher，ResponseHandler,今天才明白原来这是一种函数式编程的dsl。moco已clone,学习一下
作者回复: RequestMatcher和ResponseHandler是模型，函数式的DSL是接口。
2020-08-05

4
桃子-夏勇杰
郑大大，很好奇你的moco，也粗略地看了几次。有时间的时候，是否可以来个mock server的竞品分析
作者回复: 这种分析在网上可以找到，我来写的话，肯定会偏向Moco，不那么客观。
2020-11-07

1
jg4igianshu
https://github.com/dreamhead/moco
2020-08-05

11
阳仔
作为程序猿学习能力应该是自带属性，实际工作中，从解决问题出发，锻炼自身的软件设计和开发能力，这是一个层次。把问题抽象出来提供一个通用的解决方案，并提供程序库出来，这又是一个层次。自己和自己维护的代码一起进化，这应该是每一个开发者所追求的
2020-08-05

6
俊伟
郑老师真是我辈楷模。从2018年的10x专栏一直追到现在，常读常新。之前通过郑老师了解到TDD，现在工作中已经离不开这种先进的开发方式了。
2023-03-03归属地：北京

3
蓝士钦
在日常工作中，常常因为查bug导致阻碍开发进度，其实也是旧项目单元测试没做好，但是有一部分原因是集成测试没做，有些问题需要整个系统和外部系统串起来完整的调用才能定位问题。我想写一个易于集成测试的DSL，可以将测试人员写好的测试用例的描述内容作为集成测试的逻辑组装。大多数情况下都是测试人员在写自己的测试代码，通过系统的http接口调用进行测试。很难覆盖到系统和外部系统之间的调用，往往出问题的也是不同团队间的系统间调用，不同系统间调用老师有什么好的建议吗
2020-08-09

2
ifelse
注意发现身边的小问题，用一个程序库或工具解决它。--记下来这一讲很贴近开发
2022-05-22

1
Nio
程序员不能只当一个问题的解决者，还应该经常抬头看路，做一个问题的发现者。真实生活并不是本该就是现在这样，是存在各种各样的问题的，不应该局限于我们要解决什么问题，更多应该留出时间想想我们有什么问题，我们为什么有这些问题。
2022-04-17

1

收起评论