技术债务就像俄罗斯方块，你永远都赢不了！

和大多数玩过俄罗斯方块的人一样，我也很喜欢这个游戏。我仍然记得第一次在任天堂游戏机上玩这个游戏时的情景。游戏的背景音乐仍然时常萦绕在我的耳边。俄罗斯方块不仅是有史以来最好玩的游戏之一，我们还可以拿它与技术债务作类比。

我将分享我和我的团队如何通过修改代码来减少技术债务，并修复了一个价值 100 万美元 / 年的 bug。

刚开始的时候任务都很简单，因为没有什么复杂性

在软件公司里，产品经理或项目经理与软件开发人员合作，根据客户优先级来开发和交付代码。我们把消除一行俄罗斯方块比作发布一个新功能。

在技术债务还没有那么多的时候，即使稍微复杂一点的任务也能轻松应对

交付一个复杂的功能等于要消除更多的行。

通常，为了按时交付，我们需要在业务需求（新特性、新产品）和代码（hack、捷径）之间做出权衡。要么修改产品策略，导致与以前的设计不兼容，需要额外的工作来迁移客户，要么同时支持新旧两套逻辑。

少量的技术债务是正常可控的

于是，技术债务出现了。俄罗斯方块中出现的空格就代表了技术债务。

所有的代码都会有技术债务，这是很正常的。在玩俄罗斯方块的时候，或多或少都会出现几个空格。

淹没在技术债务中

过多的技术债务导致新功能和 bug 修复无法在合理的时间内发布。

这个问题无法通过增加或替换开发人员来解决。在某种程度上，它之所以被称为技术债务，是因为我们需要偿还它。

偿还技术债务可以让你保持竞争力，让你的游戏可以继续。

游戏结束

就像经营一家企业一样，玩俄罗斯方块的时间越长，难度就越大。方块移动的速度越来越快，很难跟上它们的速度。

就像经营一家企业一样，你永远也无法在俄罗斯方块这个游戏中胜出。因为它没有真正的终点，你只能控制输掉游戏的速度。

就像经营一家企业一样，在俄罗斯方块游戏出现的空格会让你输掉游戏。

不久前，我和我的团队接到一个任务，负责更新产品代码中的账单和发票逻辑，以支持新的定价计划、新的支付处理器和改进的账单工作流。产品团队还在讨论某些细节，于是我们利用这段时间深入研究了现在的代码。在对代码有了更好的了解之后，我们就能够对即将到来的变更做出更准确的估计。

那些代码的基本功能是遍历每个客户的帐户，计算他们的账单，并将它们发送给票据 API。之前写这些代码的人显然很小心——不能说它们杂乱无章，但起码太缺乏灵活性。它是一个很长的函数，没有测试，只有很少的日志，而且几乎没有任何注释。这些代码是公司的一个联合创始人在 5 年前写的。从那以后，唯一一个改过这段代码的人已经不在公司了。

这有问题吗？发票发出去，公司赚到钱，好像没有任何问题。我们好像也没有必要进行重构，但我们知道即将会发生一些重大的变化，因为这个函数不能按照我们的需求进行伸缩，如果这个部分可以被简化，我们就可以走得更快。

我们在一个 sprint 中重构了这个函数，并增加了一些日志。直到那个时候，我们才发现我们实际上修复了一个什么样的 bug！会计团队的一个工作人员跑到我们的办公桌前，问我们为什么发票的数量增加了这么多。因为旧代码有一些问题，一些客户的使用情况并没有记录在发票上。据我们估计，这样造成的发票丢失每年总额超过 100 万美元。

这个故事是真实的，但偿还技术债务并不总是会产生如此戏剧性的效果。只能说我们当时很幸运。

找到技术债务的平衡点

我希望我能够就何时偿还技术债务提出明智的建议。然而，这个问题的答案是：这太复杂了，而且我们往往需要做出某种程度的权衡。你的代码可以是世界上最干净的，并且经过了最全面的测试，但用户可能不会为它掏钱。相反，你的代码也可能非常混乱，但这些代码可以取悦用户，并让他们为它掏钱，公司因此赚得盆满钵满。

我能给出的建议是，产品所有者和开发人员应该在理解技术债务上达成一致，技术债务是永远无法避免的。毕竟，就像俄罗斯方块一样，在软件开发中，你永远无法赢得这个游戏。

https://medium.com/@erichiggins/technical-debt-is-like-tetris-168f64d8b700

点个在看少个 bug