凌云时刻
技术负债就像俄罗斯方块，这是一场永远无法通关的游戏，只能控制你死的速度有多慢。
很多人都喜欢玩俄罗斯方块，我也非常喜欢。至今我还记得第一次与小伙伴一起在任天堂的游戏机上玩俄罗斯方块。我认为，俄罗斯方块不仅是有史以来最好玩的游戏之一，而且它与技术负债还有异曲同工之处。我非常熟悉技术负债，几乎每天都要与技术负债打交道。
我希望通过本文，分享一个减少技术负债的故事。在这个故事中，我和我的团队不仅减少了代码中的负债，而且还修复了每年100万美元的一个bug。
在软件公司，产品经理和项目经理需要与软件开发人员一起商量编写代码的优先顺序，然后交付给客户。交付一项功能就好比消掉一行俄罗斯方块，交付一项颇为复杂的功能就好像消掉好多行。
为了满足业务需求（新功能、新产品），按时交付功能，我们常常迫不得已需要在代码上权衡利弊。有时，产品策略的变化导致以前的设计出现不兼容的现象，我们需要付出更多努力来迁移客户，或者同时支持新旧两种逻辑。
这类的情况会导致产品代码中出现技术负债，就好像俄罗斯方块中间出现了一个空隙。所有代码都有技术负债，这都很正常，就好像你在玩俄罗斯方块的时候，也会出现一些空隙。
然而，技术负债过多，就会妨碍我们在合理的时间内交付功能和错误修复。
这不是什么大问题，我们可以添加更多人手或请高手来帮忙。我们之所以称之为技术负债，是因为到一定的时间，你必须偿还这些债务。
偿还技术负债可以保持竞争力，就像让你的俄罗斯方块游戏继续。
与经营公司一样，俄罗斯方块玩的时间越长，难度就越大。方块的掉落速度会加快，让你措手不及。
与经营公司一样，俄罗斯方块是一款永远无法通关的游戏，这个游戏没有终点，你只能控制自己死的速度有多慢。
与经营公司一样，屏幕中间的空隙太多，就会输掉游戏。
一百万美元的Bug
不久前，我们团队接到了一项任务：更新产品代码中付款和发票的逻辑，目的是为了支持新的定价计划、新的付款处理并改进账单工作流程。在等待产品团队确定一些细节期间，我们利用业余时间深入研究了现有代码。提前理解代码，可以让我们更准确地预估完成这些更改所需的技术力。
我们研究代码的基本目的是查看每个客户的账号，计算他们的账单，然后将这些账单发送到发票API。显然，这部分代码经过了精心设计，而且代码本身编写得也很漂亮，虽然不那么灵活，但并不是太混乱。这是一个巨大的函数，没有测试，日志也很少，几乎没有任何文档，还有一些无法解释的随机因素。这是一位联合创始人于五年前编写的代码。自该函数编写完成以来，中间只有过一次变化，但当时的开发人员已经不在公司了。
这段代码会有问题吗？发票就是从这里发出去的，而且公司也一直在赚钱，没有任何迹象表明有任何问题。这么看来，我们不应该重构这段代码，但是我们知道重大的变更即将来临，这个函数无法满足我们的需求，如果能够简化这部分代码，我们就可以更快地完成这项变更。
于是，我们利用一个sprint中重构了该函数，并添加了一些急需的日志。就在这个时候，我们才发现我们在不知不觉间解决了一个大问题。有一天，一位会计部的同事问我们，为什么输出的发票上的金额突然增加了？旧代码可能会超时但不会报告任何错误，因此部分用户的费用并没有体现在发票上。是因为那些随机因素吗？导致我们收不到某些客户未付费的提醒？
根据我们的估计，每年丢失发票的总金额超过了100万美元。
偿还技术负债未必能还清债务
尽管这是一个真实的故事，但偿还技术债务并不一定总是有如此显著的效果。我们只是走运罢了。
我非常希望能够就何时偿还技术负债给出一些建议，然而不幸的是，我只能说，技术负债非常复杂，你只能尽力平衡。即便你拥有世界上最整洁、测试最充分的代码，但也会遇到没有付费的客户。而另一方面，即便有些公司的代码非常凌乱，但客户很满意，而且公司也赚到了钱。
无论在何种情况下，产品经理和开发人员都应该对技术负债有统一的认识。大家应该明白，技术负债永远无法避免，就像俄罗斯方块一样，在软件开发这场游戏中，你永远无法通关。
原文链接：https://medium.com/s/story/technical-debt-is-like-tetris-168f64d8b700
END
长按扫描二维码关注凌云时刻
每日收获前沿技术与科技洞见
投稿及合作请联系邮箱:lingyunshike@163.com
