和大多数玩过俄罗斯方块的人一样,我也很喜欢这个游戏。我仍然记得第一次在任天堂游戏机上玩这个游戏时的情景。游戏的背景音乐仍然时常萦绕在我的耳边。俄罗斯方块不仅是有史以来最好玩的游戏之一,我们还可以拿它与技术债务作类比。
我将分享我和我的团队如何通过修改代码来减少技术债务,并修复了一个价值 100 万美元 / 年的 bug。
刚开始的时候任务都很简单,因为没有什么复杂性
在软件公司里,产品经理或项目经理与软件开发人员合作,根据客户优先级来开发和交付代码。我们把消除一行俄罗斯方块比作发布一个新功能。
技术债务还没那么多时,即使稍微复杂一点的任务也能轻松应对
交付一个复杂的功能等于要消除更多的行。
通常,为了按时交付,我们需要在业务需求(新特性、新产品)和代码(hack、捷径)之间做出权衡。要么修改产品策略,导致与以前的设计不兼容,需要额外的工作来迁移客户,要么同时支持新旧两套逻辑。
少量的技术债务是正常可控的
于是,技术债务出现了。俄罗斯方块中出现的空格就代表了技术债务。
所有的代码都会有技术债务,这是很正常的。在玩俄罗斯方块的时候,或多或少都会出现几个空格。
淹没在技术债务中
过多的技术债务导致新功能和 bug 修复无法在合理的时间内发布。
这个问题无法通过增加或替换开发人员来解决。在某种程度上,它之所以被称为技术债务,是因为我们需要偿还它。
偿还技术债务可以让你保持竞争力,让你的游戏可以继续。
游戏结束
就像经营一家企业一样,玩俄罗斯方块的时间越长,难度就越大。方块移动的速度越来越快,很难跟上它们的速度。
就像经营一家企业一样,你永远也无法在俄罗斯方块这个游戏中胜出。因为它没有真正的终点,你只能控制输掉游戏的速度。
就像经营一家企业一样,在俄罗斯方块游戏出现的空格会让你输掉游戏。
百万美元 bug
不久前,我和我的团队接到一个任务,负责更新产品代码中的账单和发票逻辑,以支持新的定价计划、新的支付处理器和改进的账单工作流。产品团队还在讨论某些细节,于是我们利用这段时间深入研究了现在的代码。在对代码有了更好的了解之后,我们就能够对即将到来的变更做出更准确的估计。
那些代码的基本功能是遍历每个客户的帐户,计算他们的账单,并将它们发送给票据 API。之前写这些代码的人显然很小心——不能说它们杂乱无章,但起码太缺乏灵活性。它是一个很长的函数,没有测试,只有很少的日志,而且几乎没有任何注释。这些代码是公司的一个联合创始人在 5 年前写的。从那以后,唯一一个改过这段代码的人已经不在公司了。
这有问题吗?发票发出去,公司赚到钱,好像没有任何问题。我们好像也没有必要进行重构,但我们知道即将会发生一些重大的变化,因为这个函数不能按照我们的需求进行伸缩,如果这个部分可以被简化,我们就可以走得更快。
我们在一个 sprint 中重构了这个函数,并增加了一些日志。直到那个时候,我们才发现我们实际上修复了一个什么样的 bug!会计团队的一个工作人员跑到我们的办公桌前,问我们为什么发票的数量增加了这么多。因为旧代码有一些问题,一些客户的使用情况并没有记录在发票上。据我们估计,这样造成的发票丢失每年总额超过 100 万美元。
偿还债务并不总能带来回报
这个故事是真实的,但偿还技术债务并不总是会产生如此戏剧性的效果。只能说我们当时很幸运。
找到技术债务的平衡点
我希望我能够就何时偿还技术债务提出明智的建议。然而,这个问题的答案是:这太复杂了,而且我们往往需要做出某种程度的权衡。你的代码可以是世界上最干净的,并且经过了最全面的测试,但用户可能不会为它掏钱。相反,你的代码也可能非常混乱,但这些代码可以取悦用户,并让他们为它掏钱,公司因此赚得盆满钵满。
我能给出的建议是,产品所有者和开发人员应该在理解技术债务上达成一致,技术债务是永远无法避免的。毕竟,就像俄罗斯方块一样,在软件开发中,你永远无法赢得这个游戏。
英文原文:https://medium.com/@erichiggins/technical-debt-is-like-tetris-168f64d8b700
评论 1 条评论