jvm救助空间_太大而无法生存：没有技术债务的救助

jvm救助空间

技术债务和金融债务之间的唯一区别是，承担金融债务时通常更提前知道成本。 这两种类型的债务都是有目的地明智地使用的工具和管理债务的计划，如果鲁used地使用债务或由于方向错误或沟通不当而造成债务损失，这两种债务都会造成毁灭性的损失。

可接受债务与不必要债务

最初的标题是“必要债务与不必要债务”。 不过，经过进一步的思考，我意识到产生债务的唯一良好原因是时间驱动。 如果取消时间作为一个因素，则没有合理的债务需求。 因此，这就成为一个问题，即时间何时足够重要，足以使债务可以接受。 我能想到的唯一情况是在紧急情况下时间普遍可以接受。

除紧急情况外，评估因时间原因是否可以接受债务已成为一项价值主张。 在我们的个人生活中，通常认为第一个汽车和房屋是接受债务的一个很好的理由，因为两者的成本都很高，随着时间的流逝，它们可能会变得更昂贵，因此为他们存钱变得越来越难。一段合理的时间。

同样，构建内部自定义应用程序，而不是等待以最小限度的审阅代码来招致技术债务的商业现成（COTS）解决方案，并且不可避免的维护成本对于实现业务价值至关重要的功能来说是值得的。 曾经在软件供应商工作过，我可以诚实地说，如果至少作为补丁1尚未普遍提供（GA），则仍应将其视为COTS解决方案不可用。

通常不应作为承担债务的可接受原因的另一个常见时间驱动因素是急躁。 用房屋净值贷款购买最新的电视是一个糟糕的财务决定，而在没有经过全面评估和适当培训的情况下实施新解决方案是一种赌博，通常会导致更高的维护成本或潜在的系统故障。

古老的格言“忍耐是一种美德”不仅是正确的，而且还大大低估了忍耐的价值。

在债务发生之前停止债务

技术债务在许多公司中越来越引起关注的原因是，就像金融债务一样，技术债务呈指数增长趋势。 并且出于同样的原因。 在前面提到的三种债务驱动因素（紧急情况，长期价值，短期内的不耐烦）中，最常见的原因是最不需要的：不耐烦。 由不良习惯引起的问题会不断增长，直到该习惯被具有更积极作用的行动所取代。

在这里不必太过心理，不耐烦是由于要么非常想获得报酬，要么就想摆脱损失。 出于某种奇怪的原因，前进的动力似乎并没有在相同的背景下重复，而远不止于前进的动力。 在技​​术中，逃避的动力是如此普遍，以至于与逃避所导致的不耐烦有关的三个关键情绪都有一个缩写：FUD（恐惧，不确定性，怀疑）。 就IT决策而言，所有这三个本质上都是冗余的，或者至少是一个顺序。 由不确定性和/或怀疑引起的恐惧。 当决定围绕承担技术债务时，担心的是如果功能被延迟或减少，则企业主或客户会感到沮丧，不确定性和怀疑是要么不问这些利益相关者，要么只问一半问题的结果。

问一个利益相关者“功能X是否不在发行版中，这是一个问题吗？” 答案通常会与“您是希望我们在以后的版本中包含功能X还是在我们有时间以可维护的方式将其推出之前将其推入而冒着某些将来的功能延迟的风险？” 我的经验是，大多数时候都不会问这个问题，只是假设如果用户现在没有访问只有3％的新选项的使用权 ，世界将会终结。 根据我的经验，当向利益相关者解释可靠性和稳定性与即时性之间的权衡时，他们通常会选择延迟。 我知道许多人认为企业没有看到长期影响，而且我认为在许多情况下，这不是因为他们故意忽略它们，而是因为应该告诉他们何时以及为什么要谨慎的人们都害怕说些什么。将被视为“负面”。

总而言之，减少技术债务积累的最佳方法是与利益相关者进行公开，诚实的沟通，以了解决策何时涉及技术债务，债务的后果以及避免承担债务的选择。 然后，如果决定仍然以正确的方式选择现在的权利，请立即要求购买计划，时间表和预算以减少技术债务。 同样，我的经验是，当向企业提出确保功能可靠性的请求时，他们经常会回答“是”。

摆脱不可避免或无法接受的债务

承担一些技术债务是不可避免的。 这就是为什么我在上一节中通常 ， 最频繁 ，更频繁地使用修饰符，而不是总是 ， 肯定和每次都更不舒服但还不准确的原因 。 即使在理论上完美的过程中，企业始终选择无债务选择，并且从未发生紧急情况，仍然会由于缺乏信息或使用不完善的供应商版本而做出导致债务的选择。

如果债务是在不知情的情况下产生的，一旦发现债务，请务必将其记录在案，进行沟通并为债务的纠正计划。 与在没有卖方更改大得多费用的情况下不可避免地承担债务而故意承担债务的情况下的差异，请在每个项目中监视该项目，并在有合理的选择纠正此债务时进行处理。 我曾经不得不构建有点笨拙的东西，因为供应商应用程序显然错过了特定功能实现方式的含义。 我们在缺陷跟踪器中创建了一个缺陷，每个发行版中都对其进行了审查。 18个月后，供应商发现并纠正了错误，我们在下一版本中用更好的方法替换了变通方法。 对于大型企业而言，最好在发现此类问题后向供应商提出支持案例，但当时我没有这样做，因为我管理此应用程序的公司太小而无法引起供应商的关注和功能没有得到广泛使用。

翻译自: https://www.infoworld.com/article/3305791/too-big-to-survive-there-is-no-bailout-for-technical-debt.html

jvm救助空间