Meetup 是如何解决技术债务问题的

定期解决高优先级技术债务问题可以实现产品的持续健康度。Meetup 的 CTO Yvette Pasqua 解释了如何通过解决技术债务来达成有影响力的结果。她建议先从影响力大的技术债务开始，并就其产生的结果进行沟通交流。

Pasqua 在 Craft 2017 大会上呈现了有关大规模解决技术债务的演讲。InfoQ 通过问答、总结和文章的形式对大会进行了报导。

在演讲结束后，InfoQ 采访了 Pasqua，内容包括如何量化技术债务、如何改进产品健康度、他们从解决技术债务中学到了什么、Meetup 使用了哪些工具来量化和减少技术债务，以及如何建立以产品健康度为中心的文化。

InfoQ：技术债务是可量化的吗？

Yvette Pasqua：从我的经验来看，我很反对花太多时间去尝试量化技术债务。如果你真的要这么做，可能需要花很多时间，而结果通常不会很准确，因为技术债务种类繁多，而且它们中的大部分都没有明确的定义。

我在演讲中引用了 Matt Holford 的文章“ Can Technical Debt Be Quantified ”，Matt 是 DoSomething.org 的 CTO，他在文章中表达了对量化技术债务的看法，他认为“技术债务通常是不可量化的”。在快速发展的技术公司，我认为对技术债务进行量化并不会带来太大的价值。相反，我认为应该将精力放在那些高优先级的技术债务上，系统性地解决这些技术债务，并把它作为组织的长期实践。所以，我建议将技术债务按照优先级进行分类，而不是对它们进行量化，然后尽快解决高优先级的技术债务。

InfoQ：在 Craft 大会上，你讲到了持续的产品健康度。你能详细地解释一下什么是持续的产品健康度吗？

Pasqua：我们要让整个公司在解决技术和产品债务这个问题上步调一致，因为这是一个影响面很广的事情。我们知道，如果想要获得成功，就不能仅仅把它看成是一个工程问题，我们需要让公司的每一个人都清楚什么是技术债务、为什么解决技术债务对我们来说如此重要以及我们的计划是什么。于是，我们把它们总结成一个简单清晰且积极正向的东西：持续产品健康度。简单地说，持续产品健康度就是“持续地关注整个代码基库而不仅仅是产品特性”。积极正向且清晰定义的产品健康度正是人们想要的东西。特别是对于那些工程领域之外的人来说，秉持这种理念是非常关键的。在我们把持续产品健康度作为帮助公司更快达成产品策略和目标的同时，他们可以尽情地畅想公司的未来。

InfoQ：你们是如何改进产品健康度的？

Pasqua：我们曾经解决过的一些高优先级的技术债务包括如下几项。

• 我们从使用自有数据中心的 RabbitMQ 服务器转成使用 AWS SQS。我们不想把时间花在消息服务的运维和伸缩问题上，我们想专注在 Meetup 的产品迭代上。我们比较了各种托管解决方案，最后决定迁移到 AWS SQS 上，它给我们带来了重大的工程生产力提升、简化了系统、改进了可靠性。到目前为止，我们对我们的这个决定感到很满意。
• 我们想要提高大单体代码基库的单元测试覆盖率，因为之前的覆盖率很低。我们花了很多时间为新代码和已有代码编写单元测试。这样可以加快大单体应用的持续部署速度，因为我们可以尽可能多地依赖测试框架底层的东西。我们不仅关注总体覆盖率，也尽量让修改过的“活跃代码”接近 100% 的覆盖率。我们设定了测试覆盖率目标，使用 Coveralls 收集覆盖率的度量指标，并把它们展示给工程师看，我们发现这样可以显著提高覆盖率。
• 在过去几年，我们将数据中心迁移到云端，解决了很多技术债务问题，我们从中获得了巨大的好处。关于这些，我们有很多话要说，但我们最想说的是，最好从一开始就使用云端托管服务，这样就不需要经历中间的迁移过程。我们还将系统的很多组件变成无状态的，并将基础设施构建成代码的形式，当系统组件发生崩溃时就不会对系统状态造成影响，而且可以进行自动伸缩。我们将需要人工介入的有状态组件数量降到最少。

我在博客上介绍了我们的迁移过程。

InfoQ：你们在解决技术债务问题的过程中学到了什么？

Pasqua：我们在解决技术债务问题的过程中学到了一些事情。

• 持续地迭代，产生更大的影响力。就像通过产品迭代将产品推向市场一样，我们需要不断地迭代解决技术债务问题的方法，获得越来越有影响力的结果。可能你不会在一开始就成功，但要坚持快速地迭代跟进，评估影响力，快速地从失败中学习，然后再把它们应用到下一个迭代中。
• 你可能需要在沟通上做一些额外的工作，特别是在工程领域之外。你需要为产品和公司目标画出一幅清晰的蓝图，并把它与解决技术债务问题关联起来。否则人们就不会明白为什么要花那么多时间在解决技术债务问题上。
• 把最具影响力的事项放在第一位，不要把精力花在低影响力的事项上。就像产品迭代一样，如果你不花大力气把具有高影响力的事项放到路线图上，你的团队就会被吸引到那些低影响力的事项上，因为它们更易于计划、实施和完成。作为一个工程领导团队，我们需要积极地、有策略地提升具有高产品健康度事项的优先级，这样才能把我们的团队引导到少量具有高影响力的事项上。

InfoQ：你们使用了哪些工具来量化和减少技术债务？

Pasqua：为了达成公司的目标，我们建立了一些系统，形成了独特的工程文化，并总结了三个指导性设计原则，然后通过这些原则来衡量减少技术债务给我们带来的影响。这些原则包括：系统简单性、平台可靠性和速度。我们通过各种指标来衡量这些属性。

• 我们的团队每天将多少研究产品投入生产？我们计划在 2017 年增加 30% 的量，我们主要就是以这种方式来衡量工程速度的。
• 速度：我们评估我们的工程技术和流水线，识别出阻碍交付产品的瓶颈，并持续地为自己设定更高的目标。我们评估的项目包括：构建时间、自动化时长、部署时间、工程师上手新框架的时间。
• 可靠性：我们量化系统的可用性，当前的目标是达到 5 个 9。我们也量化页面的总数和使用 PagerDuty 的系统组件数量，并计划将它们降低 30%。
• 简单性：这一部分最难以量化。在我们看来，简单性带来的最大好处就是更少的软件缺陷。所以，我们认为量化简单性最好的度量指标就是工程师每周花在解决重大软件缺陷上的时间。

InfoQ：你们做了哪些事情来建立以产品健康度为中心的文化？

Pasqua：我们从中学到了很多，在过去的一年半当中，我们努力建立一种工程文化，改进产品健康度，而我们仍然在不断前进。我们让每个人都知道什么是产品健康度，让他们知道为什么产品健康度这么重要，以及我们要如何着手解决这些问题。我们使用了非技术用语与其他人交流项目背后的“什么”以及“为什么”，这样每个人就可以很容易地理解项目的目标，了解这些项目能够为产品和公司达成什么样的目标，以及这些项目会对工程文化的哪些部分（简单性、可靠性、速度）产生影响。其中最后一项最为重要，我们正在观察我们所做的每一件事情对简单性、可靠性和速度所产生的影响，然后为最具影响力的事情设置最高优先级。很重要的一点，工程师正在做的事情要与我们想要的文化变革合拍，这样每个人就可以朝着相同的目标迈进。

查看英文原文： Tackling Technical Debt at Meetup