认识达内从这里开始

随着互联网的不断发展，越来越多的人都在学习软件编程开发等互联网技术，而本文我们就通过案例分析来简单了解一下，Java编程度量驱动开发基础知识分享。

你可能听说过广为人知的TDD实践——测试驱动开发，也可能听说过鲜为人知的BDD——行为驱动开发，或者可能听说过不为人知的ADD——混蛋驱动开发(在ScottBerkunn的博文里可以看到一个不错的开发实践名称列表)。但度量驱动开发(MDD)是本文才提出的。

那什么是MDD呢?我认为MDD是用度量驱动整个应用开发的实践。在使用MDD的公司里，所有东西都是可以度量的，无论是性能和使用模式，还是收益。此外，开发人员、运维人员、甚至业务人员所做的每个决定都是基于度量结果的。度量用来监控团队的绩效、解决性能瓶颈、估计硬件需求，或者在开发生命周期的任意阶段达成其他目的。

度量驱动开发的主要原则有：

给度量拥有者分配度量项

创建分层的指标，相互关联、发现趋势

利用度量做决定

每个度量项都应该有一个拥有者，他/她要掌握一定的知识和方法来推行、维护确定的度量结果。度量拥有者负责应用、服务，设置运行应用和服务的服务器，确保能正常监控、收集结果。度量拥有者要获取现有度量项的新结果，还要为新应用或功能设立新的度量项。

对度量进行结构化也很重要。按照一定标准分组或分层的指标能确保所有人(从业务人员到开发人员)更好地理解它们。而且指标分层后，能更容易相互关联、发现趋势，也能更快地找到、解决问题。

MDD让整个开发过程具备了可见性，所以大家能迅速而又准确地做出决定，错误也能被立即发现、修复。此外，可以度量的内容都能进行优化。换句话说，MDD能让你为应用“把脉”，并给你提供了一个持续改进的机会。

后，利用度量给Sprint设置目标，MDD也能借此很好地和其他惯常实践结合起来使用，比如TDD、BDD或Scrum。度量也能发现问题和生产环境中的使用模式，这在验收测试过程中很难被注意到。一个例子是LanceArmstrongBug：代码在测试时永远不会出错，但还是有证据表明它和预期结果不一致。另一个例子是从不会被使用的功能的业务Bug。这些Bug相关的证据可以用度量来收集。MDD确实能实现集中、高效的开发过程，过程回顾可以提高应用使用率。

谁创建指标?

当我们从无到有开始做一件事情的时候，你会有机会重新思考一些概念，给流程加入一些创新，甚至完全修改流程。我们在Adform就做了类似的事情。我们写完需求、构想好完善的监控解决方案后，发现期望和现实很不匹配。我们本想收集更多应用和服务相关的信息，因为它们带来收入和竞争优势。但监控完全由运维团队去做，他们对基础设施有深入的了解，却不怎么了解应用和服务的内部工作原理。

公司不会因为他们的服务器运行稳定(尽管这很重要)和有10G互联网连接而赚钱。公司赚钱是因为他们的应用和服务提供的功能，以及功能运行稳定(这和“服务器运行稳定”是不一样的)。因此要快速发现问题，把真正编写应用的人引入监控流程是必不可少的。事实上，当应用和期望不一样的时候，开发人员能很容易看出来，因为产品就是他们开发的，他们掌握着产品相关的所有知识。

重要的是，开发人员去监控还有更多好处：

开发团队能在开发过程中把监控点嵌入到应用里去

开发团队能从生产环境里快速获得应用相关的反馈(性能、Bug、使用模式)

开发团队能在开发过程中学习基础知识，可以预见一些瓶颈

运维团队长久以来一直在做监控——CPU、内存和IO已经溶入到他们的血液里去了，至于应用和服务的指标，拥有者应该是开发团队。开发团队掌握着应用相关的所有知识，还有改进所需的所有技能。这就是运维团队为什么不能单独做监控的原因。开发团队应该和运维团队一起设立、维护指标。在接下来的部分里，我将介绍我们公司是怎么开始改变、如何把开发人员引入监控和度量里的。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。