不可能赢。 您只决定输多快


下一步是什么？

许多人也喜欢俄罗斯方块。 我记得第一次在Nintendo Game Boy上扮演我的朋友。 也许那首歌也停留在你的头上。 俄罗斯方块不仅是有史以来最好的游戏之一，而且还是技术债务的一个很好的类比。 它提供了对技术债务及其影响的一般理解。

我将根据您的个人经历向您介绍一个故事，我的团队如何通过某种计费代码减少其技术债务，并同时以每年一百万美元的价格纠正错误 。


首先，任务比较简单，难度较低

在软件公司中，产品/项目经理与开发人员一起确定将在下一个版本中编写并发送给客户的代码。 在俄罗斯方块中完成一行就像释放一个函数。


复杂的功能是完全可行的，技术债务几乎没有增加。

发布复杂的功能需要完成几行 。

通常，业务需求（新功能，新产品）会导致代码妥协（黑客，变通办法），以免过期。 或者产品策略的更改与以前的设计不兼容，需要付出更多的努力来迁移客户或同时支持“新”和“旧”逻辑。


小额技术债务是正常且易于管理的。

这种情况会在代码中产生技术负担。 俄罗斯方块中的隐藏通行证是一项技术职责。

任何法规都有技术责任。 这很正常。 您可以继续玩一些通行证。


陷入技术债务

过多的技术债务无法在合理的时间内发布新功能或修复错误。

通过添加新的开发人员或更不能替代现有的开发人员来解决此问题。 这称为技术债务 ：在某些时候必须偿还。

还清技术债务使您更具竞争力。 它使您始终参与游戏。


游戏结束

像业务管理一样，在Tetris中，复杂度会随着时间而增加。 形状移动得更快，更难以跟上。

与商业一样，在这里赢也不可能。 没有真正的终点线。 唯一的问题是您将失去多久。

像企业一样，俄罗斯方块的太多空白会导致亏损。

百万美元的错误

不久前，我的团队被指示要更新产品代码中的帐单/发票逻辑，以支持新的定价计划，新的付款处理程序，并改善整个帐单流程。 某些细节仍在澄清中，因此我们这次利用这些机会深入研究现有代码，以对即将发生的更改进行更准确的估计。

此代码的主要任务是遍历所有客户的帐户，计算每个客户的帐户，然后将信息发送到API以进行开票。 该系统在编写时非常谨慎和善意-并不是那么草率，而是僵硬。 整体功能。 没有测试。 日志很少。 几乎没有文档。 有一些莫名其妙的随机化。 一位创始人在五年多以前就编写了该系统。 此后唯一的变化是公司已经缺席的第一批员工之一。

根本有问题吗？ 发票已开票。 该公司赚了钱。 没有任何问题的迹象。 所有这些都不利于重构，但是我们知道即将发生重大变化：无法根据我们的需求扩展此功能，如果简化这一部分，将更容易进行。

在一次冲刺中，我们重新设计了功能并添加了一些急需的日志。 到那时，我们发现实际上已经对其进行了修复。 一位会计师在我们的办公桌前停下来，问为什么发票的出人意料地增加了。 旧代码悄悄地在计时器上消失了-某些客户端没有得到处理。 奇怪的随机化？ 她隐藏了任何可以清楚表明未向某些客户发出发票的模型。 进行评估时，我们计算出的缺失发票每年超过100万美元。

付款并非总能付清

尽管这个故事是完全正确的，但还清技术债务并不总是具有如此戏剧性的效果。 我们很幸运。


找到适当的技术债务平衡

当您需要还清技术债务时，我想提供明智的建议。 不幸的是，答案是这很困难-而且总会失去平衡 。 您可能拥有世界上最干净，测试最充分的代码，但没有客户。 反之亦然，您的公司可以使用肮脏的代码工作，但是这会使客户感到满意，并且资金流动像河水。

我只能说，产品所有者和开发人员都必须了解技术债务的本质，并且不能永远避免这种债务。 最后，就像在《俄罗斯方块》中一样，您永远赢不了。