指标驱动开发（MDD）

相信大家对 TDD （测试驱动开发）、 BDD （行为驱动开发）、 MDD （模型驱动开发）和 DDD （领域驱动开发）都已经很熟悉了，然而今天大叔想介绍的是另一种 MDD ，指标（ Metrics ）驱动开发：Metrics-Driven Development，当然，这里的 M 如果换成 Monitoring 的话，其实意思也是差不多的，即 Monitoring-Driven Developmnt （监控驱动开发）。

MDD 这一说法最先被提出，应该还是 Etsy 这家公司的工程师 Mike Brittain ， Etsy 这家公司也很伟大，开源了很多软件，比如 Statsd ，一个用于收集、转发 Metrics 的软件和协议，现在被很多监控软件所采用。

在 2011年3月12日 （ https://codeascraft.com/2011/03/01/moving-fast-at-scale-sxsw/ ）的 SXSW 期间， Etsy 举行了一个小小的活动，向外界集中介绍了一些他们在进行快速产品迭代、发布上的一些经验，这个活动的主题就是 “Moving Fast at Scale” 。Mike Brittain （当时核心平台部的负责人，现移动产品工程总监）在这次活动中进行了主题为 “Metrics-driven Engineering at Etsy” 的演讲，提出了 Metrics-Driven Development 这个相关概念。

为什么会有人提出 Metrics-Driven Development 这个概念呢？在进入正题之前，我们还是先来回顾下 TDD 。

TDD 是测试驱动开发（ Test-Driven Development ）的英文缩写，也是敏捷开发中的一项核心实践和方法论。TDD 的思想是在开发功能代码之前，先编写测试用例代码，用于测试代码是否能满足设计之初的需求。

测试代码不是简单地测试，TDD 是通过这种方式，是将测试贯穿到整个开发过程，提高测试的可靠性和重要性。

需求分析和需求变更历来都是软件工程中一项难度比较大、风险性较高的工作，测试驱动就是通过测试用例，让开发者在早期阶段就考虑到代码层面的设计和编写，以及如何验证需求的问题，确保以一种代码化、自动化的方式来进行需求验证。

和 TDD 类似，既然可以在写业务代码之前先编写测试代码，那我们是不是可以考虑得更长远一些，将上线、监控、调试和故障调查以及优化也纳入到设计阶段来做？

回到上面图中的这句话，也就是说，你都不能衡量一个东西，你怎么去管理它呢？（至于这句话到底是 Edwards Deming 说的，还是 Peter

Drucker 说的，我们就先不去追究了 ... ...）

所以，也可以说 MDD 是这句管理学中的名言在软件开发领域的一个实践。

什么是 MDD 呢？这也是一种开发理念，或者叫做哲学，即 通过实时指标来驱动快速、精确和细粒度的软件迭代 。

MDD 的创新之处在于将应用程序（服务）的监控（ Metrics ）提高到系统整体这一层次，在设计初期就开始将 Metrics 设计也包括进来，就如同写代码之前，先写测试用来一样。也就是说，未雨绸缪，在系统出问题之前，在系统设计之初，就设计一套规则来评价系统的稳定性、健康状态以及其他各种的考核目标（即服务本身的 KPI）。

一言以概之， MDD 可以帮助我们更早地 发现问题 和 明确目标 。从一定意义上来说， MDD 也是大数据。

我们都知道，监控的主要目的是为了发现问题。但是除了能及时、没有遗漏地帮我们发现问题之外，  MDD 带来的另一个好处是通过对现状的可视化和具体化，来帮助我们对未来进行规划和预测，进而实现业务改善。

比如可以根据当前服务器内存使用率、网络带宽这些基础设施因素及趋势，预测未来一段时间的容量规划。

相对于传统上通过制定各种复杂、严格的研发规定，以及无数的评审、研讨会议来确保软件安全发布、稳定运行， MDD 理念的特别之处在于在应用程序本身中，采集必要的监控信息，通过持续交付方式，进行快速迭代并进行反馈和修正（请参考一下 PDCA 环或者 OODA 环的相关知识），所有决定都是基于对不断变化的情况的观察。

总之呢，毕竟要穿几尺腰的裤子，拦腰虎抱不准，目测不灵，还是得量量才知道。

图片来自： http://www.jituwang.com/tuku/201305/295805.html

程序运行起来才能为用户提供服务，才能为用户提供价值，为公司赚取收入；躺在 Git 仓库中的代码，编码风格再好，注释再详细，如果没有运行，并没有一毛钱的用处。

对于静态代码我们有各种工具和原则来进行管理，对于运行中的代码， Metrics 能为我们提供整个系统的详细情况，哪些代码执行过，执行过多少次，哪里有错误，有多少错误，都能让我们一目了然。

Metrics 不仅对软件系统而言必不可少，对业务系统来说，也能作为决策的强有力的根据，帮助我们减少犯错、提高决策速度和精准程度。

理论上来说，能被具体化、数字化的指标，都可以进行提高和优化，进而驱动业务提升，带来更多的商业价值。

MDD 定义中的快速、细粒度迭代等词眼，也是和 DevOps 等现代软件开发理念契合的。也可以说， MDD 基于敏捷开发、持续集成和持续交付这些软件开发方法论和实践发展而来。

DevOps 强调随时发布，每次细小修改发布之间，都可以通过 Metrics 来监控发布后所带来的各种指标的变动，快速发现问题，或者提供业务数据反馈。

MDD 和传统的 Ops 的最大区别，可能就是需要更多的从开发者的角度去设计这个 Metrics （监控）系统。即需要开发者在监控方面发挥很大的主观能动性。