技术债务
我们是怎么来到这里的？
技术债务永远是那些“其他人”的错。 几年前在这里的那些白痴开发者。 白痴。 如果他们的持续存在依赖于生活，那么显然无法为他们摆脱生活游戏编码。
我不想告诉你，但是： 我们就是其他人 。 我们今天做出的决定明天将显得愚蠢。 然后，我们将以不同的视角获得更多信息。 我们将了解产品和技术将如何发展。 我们不知道今天，所以我们的许多决定都会被证明是错误的。
从哪儿开始
班级就像畅销小说–有些班级比其他班级更受欢迎/负担更多。 一类，一个包，一个模块–将比其他类差得多。 将会有一些类，包等……比所有其他类都差得多。
这是怎么发生的？ 好吧，一堂课最终要承担一点技术债务。 下次我要更换班级时，我懒得解决债务问题，所以我只好一起学习一些东西，以完成新功能。 然后，在下一个回合中，债务累累了-只有那个家伙太忙了才能解决它，所以他增加了一些笨拙并留下了。 在不知不觉中，这一类已经成为纯技术债务的一万行怪兽。
就像破窗理论一样 -如果代码已经很烂，那么使其变得更烂就容易得多。 如果代码是干净的，那么添加黑客是一个很大的步骤。 技术债务越来越少地聚集在已经充满债务的地区。 我怀疑代码中的技术债务遵循幂律法 -大多数班级都有一点债务，但有些班级确实很烂，特别是一个恶魔般的班级：
从哪儿开始？ 抵制诱惑，轻松更改相对干净的班级-从最严重的罪犯开始。 这将是最难修复的，可能会花费很长时间–但是通过修复最繁重的废话代码，您将获得最好的回报。 如果您能解决最严重的违法者，您的债务将不得不寻找其他藏身之处。
80/20规则
有一种陈词滥调，即80％的软件成本是维护成本，只有20％是初始构建成本。
假设一个团队每月有1200个小时花在有用的工作上。 对于这1200个小时的有用工作，根据80/20规则，我们将在维护软件的整个生命周期内花费四倍的时间。 尽管本月我们完成了1200小时的功能工作，但我们仍致力于在代码的生命周期内进行4800小时的维护。
这意味着下个月，我们必须花费4800小时的维护时间中的少部分时间，其余时间用于有用的功能添加工作。 但是，添加新功能会使我们承担更多的维护工作。 在接下来的一个月中，我们要维护的代码几乎增加了一倍，因此花了几乎两倍的时间来维护它，而花更少的时间来产生增值功能。 我们每个月花越来越多的时间来处理以前存在的废话，而添加新功能的时间越来越少。
这听起来很熟悉吗？ 这就是技术债务的感觉。 几年后，步伐下降了。 您将花费一半的时间进行重构和修复以前存在的垃圾。 “只要我们能摆脱这种技术债务” ，您就哭了。
什么是技术债务？
我们都可以指出我们看到的卑鄙的，背负沉重代码的示例。 但是技术债务的影响是什么？ 技术债务仅仅是无法快速更改现有系统的能力。 这就是技术债务业务的成本–应该Swift改变，这要花费不可预期的长时间。
消除技术债务后我们该怎么办？ 我们概括并找到更多抽象的解决方案。 我们澄清和简化。 我们消除了重复和不必要的复杂性。
减少技术债务的净效果是减少库存。
也许代码量（我们的清单）非常适合系统中的技术债务量。 如果我遇到一百万行代码并需要进行更改，则可能需要一段时间。 但是，如果我只遇到1000行代码，那么更改将更快。 但是，如果我遇到零行代码，那么成本为零–我可以做我想做的任何事情。 更改系统的成本大致与系统的大小成正比。 大型，复杂的系统进行更改所需的时间比小型，独立的系统要长。
所有代码都是一种责任–您拥有的代码越多，债务就越大。 当我们偿还技术债务时，我们真的只是在减少库存吗？ 技术债务实际上是我们持有的所有存货的利息支付吗？
有什么选择？
大爆炸
一种选择是缩减工具并修复债务。 不一定要扔掉所有东西并重写，而是花一些时间清理混乱。 处理技术债务的大爆炸方法。 企业同意这样的计划是非常不寻常的–一年没有新功能吗？ 真？ 如果一年没有任何新功能，那么所有这些产品经理将整天做什么？
根据80/20规则，任何一段代码的生命周期成本都是创建成本的四倍。 如果花费了三个月的时间，那么将需要一年的时间来还本付息。 所以，等等，我们要花一年的时间才能偿还三个月的技术债务？ 认真吗 我们的状况会略有好转-但我们仍将陷入债务沉重的泥潭，并且我们将失去一年的功能。 没门！
专职团队
即使您尝试进行大爆炸，它最终也变成了专门的团队方法。 作为妥协，您可以让一个专门的团队来解决债务问题，同时其他所有人都在努力开发新功能。 一个团队正在消除债务； 而另一个团队正在重新添加它。 债务清除的速度比债务增加的速度有什么机会？ 究竟。 零。
这是有道理的-您需要一个团队来消除债务，而团队要增加一些新功能只是为了保持稳定，而债务是团队增加四倍的。
童子军
您可以采取一种策略，尝试少而少地消除技术债务-童子军方法。 在每一项开发任务上，尝试消除工作地点附近的债务。 如果没有测试，请添加一些。 如果测试不佳，请改进它们。 如果代码分解不好，请对其进行重构。 童子军的规则–离开营地，让他们保持清洁。
通常，这更容易销售，对生产力的影响也很小：与您开发的新系统相比，对您已了解并已在使用的系统的一部分进行更改要便宜得多。 但是随着时间的流逝，您可以大大减慢债务的增长速度。 该系统不可避免地仍然会增长，不可避免地债务会增加。 但是，如果您可以最大程度地减少维护成本，则可以使代码尽可能小巧，灵活。
专业精神
如果我们可以减少代码的维护成本，甚至可以减少一点，我们就可以在代码的生命周期中节省一笔巨款。 如果我们可以将倍数减少到初始成本的三倍，那么我们的1200小时工作仅需要3600小时维护，那么我们已经节省了足够的开发能力来构建相同大小的另一个功能！ 免费！ 嘿，产品经理，如果我们能做得更好，就不再需要了，您将获得免费的功能。 谁不想要免费功能？
如果我们可以创建精心制作的 ， DRY ， SOLID代码，并且具有良好的测试覆盖率，那么我们就有很大的机会将终身维护成本降到最低。 这是我们提高生产率，避免陷入技术债务泥潭并使代码库对不断变化的需求做出响应的最佳方法。 这是我们保持生产力和敏捷性的唯一途径。
坦白说，其他任何事情都不专业。 如果您故意让您的公司花过多的钱来维护您的糟糕代码，那么，他们到底是在为您付出什么呢？
参考：通过Actively Lazy博客 处理 JCG合作伙伴的 技术债务 。
翻译自: https://www.javacodegeeks.com/2011/11/dealing-with-technical-debt.html
技术债务
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
