像大多数玩过它的人一样,我喜欢俄罗斯方块。我还记得第一次在朋友的Nintendo Game Boy上玩它。俄罗斯方块不仅是有史以来最好的游戏之一,它还是技术债务的绝佳模拟。技术债务的影响是我非常熟悉的 - 我每天都在处理它们。{#19bf}

我还将分享一个个人故事,讲述我和我的团队如何减少某些计费代码中的技术债务,修复每年100万美元的错误。{#b339} 当复杂性较低时,任务开始时更容易

在软件公司中,产品和项目经理(PM)与软件开发人员合作,确定下一步将编写和发送给客户的代码的优先顺序。完成俄罗斯方块行就像发布一个功能。发送复杂功能需要更多行。{#ded7} 复杂的功能非常容易,技术负担很小

通常,业务需求(新功能,新产品)将导致代码内的权衡(黑客,快捷方式),以便按时发货。或者,产品策略的变化将与之前的设计不兼容,需要额外的努力来迁移客户或支持"新"和"旧"逻辑。{#13e2} 少量技术债务是正常和可管理的

像这样的情景会在产品代码中产生技术债务 。俄罗斯方块中的埋藏间隙代表技术债务。{#43d4}

所有代码都有技术债务。这很正常。你可以继续玩俄罗斯方块,但有一些差距。{#d38c} 埋在技术债务中

太多的技术债务会阻止功能和错误修复在合理的时间内发货。{#5a04}

这不是一个可以通过添加更多开发人员或更显着地替换现有开发人员来解决的问题。它被称为技术债务,因为在某些时候,它需要被偿还。{#407f}

偿还技术债务可以保持竞争力。它让你在游戏中。{#d243} 游戏结束

与经营业务类似,俄罗斯方块玩的时间越长越难。件数变得更快,跟上变得更难。{#e79f}

与经营企业类似,您永远无法赢得俄罗斯方块。没有真正的终点线。你只能控制你输的速度。{#4865}

与经营企业类似,在俄罗斯方块中建立太多差距将导致您失败。{#d1ca}

100万美元的错误{#b729}

不久前,我的团队的任务是更新产品代码中的计费和发票逻辑,以支持新的定价计划,新的支付处理器和改进的计费工作流程。部分细节仍由产品团队决定,因此我们利用业余时间深入研究现有代码。这提高了我们对它的理解,因此我们可以准确估计我们完成即将发生的变化的能力。{#4d66}

我们研究的代码的基本目的是审核每个客户的帐户,计算他们的帐单,并将其发送到开票API。它显然是谨慎和良好的意图写的 - 它不是那么混乱,因为它不灵活。这是一个单一的功能。没有测试。原木很少。几乎没有任何文件。有一些无法解释的随机化。它是五年前由其中一位联合创始人撰写的。从那时起,唯一的变化就是来自不再在公司工作的早期员工。{#d88d}

这真的是个问题吗?发票出去了。该公司赚钱。没有迹象表明存在问题。所有这一切都可能使我们无法从重构中解脱出来,但我们知道会发生重大变化,这个功能无法满足我们的需求,如果这部分被简化,我们可以加快行动。{#0120}

我们在单个sprint中重构了该函数,并添加了一些急需的日志。就在那时我们发现了我们实际修复过的东西。来自我们会计团队的人员在我们的办公桌旁停下来询问为什么出境发票的数量意外增加了。旧代码已经默默地超时,并且一些客户的使用情况没有计入发票。奇怪的随机化?它隐藏了任何可能提醒我们没有被收费的客户的模式。{#7033}

当我们进行估算时,丢失的发票每年总计超过100万美元。{#ea12}

偿还债务并不总能带来回报{#c6d2}

虽然这个故事完全正确,但偿还技术债务并不总是会产生如此巨大的影响。我们很幸运。{#ae91} 找到适当的技术债务平衡点

我希望我可以就何时偿还技术债务提供建议。不幸的是,答案是:它很复杂,而且总是一种平衡的行为。您可以拥有世界上最干净,经过最佳测试的代码,但您可能也没有付费客户。相反,您的公司可能正在运行一些非常混乱的代码,这些代码可以让客户高兴,并且可以让钱交出来。{#a46d}

无论哪种方式,产品所有者和开发者都应该分享对技术债务的理解。他们也应该知道永远无法避免。毕竟,像俄罗斯方块一样,你永远无法赢得软件。{#a285}


特别感谢 Thomas Lubitz 鼓励这篇文章,并允许使用这个类比,这是他在玩俄罗斯方块时的闪电般的演讲。 {#7419}

查看英文原文

查看更多文章

公众号:银河系1号

联系邮箱:public@space-explore.com

(未经同意,请勿转载)