围绕技术债务的五个大神话

在软件公司中，人们经常谈论技术债务，通常将其归咎于发生的不良情况，例如

• “在解决技术问题之前，我们无法编写新功能。”
• “开发人员落后于进度，因为他们正在与技术债务作斗争。”
• “我们最好的工程师之所以辞职，是因为我们负债累累。”

即使经常提及技术债务，也很少以每个人都能理解的方式对其进行解释。 错误的观念和错误的信息经常导致对话。 达到临界点时，技术债务可能会很大，可能会使产品陷于瘫痪甚至整个公司。 因此，对于每个人来说，更好地了解它是什么以及如何对其进行管理很重要。

什么是科技债务？

技术债务是许多类型的代码问题的总称，其最终结果是使一段代码难以使用—开发人员难以阅读，理解和进行更改，而又不会产生不可预测的结果和不良副作用。

以下是一些技术债务类型，按严重程度分组：

严重程度低

• 过时的3rdparty库
• 样板过多或重复的代码
• 构建/测试时间慢

中等严重性

• 功能重复
• 错误处理不足
• 日志不足或过多
• 片状测试
• 由于缺少自动化，必须手动执行重复任务
• 合并之前草草编写和/或未进行同行审查的代码
• 由于代码/需求而导致的结构退化的代码会随时间变化，有时称为“位腐烂”

高度严重

• 广泛使用的库/组件的本地版本
• 难以理解的模糊代码
• 出于预期目的过于复杂和脆弱的代码

严重程度

• 测试覆盖率不足

随着技术债务的累积，开发人员的生产力下降。 组织必须超越围绕技术债务的神话，以便人们可以采取协调一致的行动来控制它。

科技债务神话＃1：无定形

太多的时候，术语“ 高科技债”时，表明是一些独大，不好的东西，这是不可避免的增长非晶云，一定要吞下整个代码库在不久的将来。 用这种方式表征技术债务会导致无所作为和绝望。

实际上， “技术债务”包含许多离散的问题-与错误类似，但对最终用户不可见，并且主要影响开发人员的生产力。 像错误一样，技术债务问题可以逐项列出，确定大小，优先级并逐步解决。

并非所有的技术债务都是平等产生的-频繁修改的主线代码中的问题比很少接触的代码中的问题更具影响力。

通过在电子表格或问题跟踪器中记录问题来量化技术债务。 记录频率，影响，修复成本以及其他重要的优先级因素。 将这些问题作为一个团队进行排名，注意不要忽视影响到每个人的频繁发生的“剪纸”问题，这总计会浪费大量时间。

⭐根据每个项目对团队的影响程度来确定特定技术债务问题的清单。

科技债务神话2：原因单一

科技公司的人们对科技债务的来源有强烈的看法。 产品经理可能会说，技术欠债来自懒惰或不称职的开发人员编写糟糕的代码。 开发人员可能会说，匆匆忙忙的项目（首先是产品上市时间）导致编写高质量代码的时间不足。 等等。

实际上，存在技术债务的三个主要原因：

1.故意的技术债务是由团队捷径提供原型或在较短的期限内造成的。 工程流程的跳过步骤（例如重构，自动测试覆盖，同行评审，错误处理和日志记录）可在短期内节省时间，但会增加技术负担。 与财务贷款类似，团队将以未来的“利息”支付（以较低的生产率形式）为代价获得短期利益，直至偿还债务。

2.当由于缺乏经验，能力不足或缺乏动力而对代码进行不良的设计时，就会发生无意的 技术债务 。 在功能强大的团队中，这些事情将通过对代码和设计的同行评审来发现。 但是如果团队因审查期限太短而忽略了审查，那么技术债务可能会被忽略。 意外的技术债务的另一个来源是针对误解的要求编写代码。

3.随着时间的流逝而产生的技术债务发生在对代码片段的增量增强和错误修复导致结构的逐步丧失时； 有时称为“腐烂”。 它只能通过重构来防止，这需要花费额外的时间。 另外，随着客户使用方式的改变，旧的要求或功能可能会过时，并且如果不删除或重构其代码，则将成为技术债务。

技术债务有多种原因，因此团队坦诚坦诚，承担责任并避免指责至关重要。 无意识的技术债务是最隐蔽的，因为它通常是可以避免的，并且不会产生任何有益的副作用。

⭐在设计和编码阶段，请有经验的开发人员进行同行评审和指导，以杜绝意外的技术债务。

技术债务神话三：永远不要故意创建它

一些工程师说，技术债务非常昂贵，绝不应该故意造成。 这是一个错误的陈述，因为技术债务在正确使用时是一种有价值的工具，类似于公司借钱进行时间紧迫的投资。

在三种情况下，有意的技术债务是合理的：

1.构建原型或演示。 该团队正在提供概念证明或原型，以获取新产品或功能的动手反馈。 或交互式演示以帮助关闭主要客户，合作伙伴或融资回合。 正确的高速，低成本方法是偷工减料，并创建稍后将抛出的代码。

2.上市时间至关重要。 由于团队无法控制的原因，需要加快新产品或功能的开发。 偷工减料可以节省宝贵的时间。 在截止日期结束后不久，将在不久的将来改进代码，而不是将其丢弃。

3.需求可能会改变。 构建新产品或功能需要猜测客户真正想要的东西。 如果保证需求有变化，那么偷工减料和编写短命的代码可以减少返工的成本。

故意增加技术债务可能是“滑坡”-团队应谨慎行事！

团队应该讨论增加技术债务的理由，并决定将来是否要丢弃或改进代码。 清楚地记录决策，并与所有人进行沟通，确保团队中的每个人都对战略保持一致。 由于过去的经验，有些人可能会有负面的情绪反应。 团队需要明确的界限。 定期检查规则，以使每个人保持一致。制定时间表以预算时间以尽快解决技术债务。避免严重的技术债务-晦涩的代码，过于复杂的代码和不足的测试覆盖范围是如此有毒，以至于这些除非扔掉代码，否则捷径永远都不值得。定期更新技术债务清单（无论是在电子表格中还是在问题跟踪器中）。 确认解决技术债务的时间表提供了足够的时间来解决这些问题。

仔细创建新的技术债务：使团队按照规则进行调整，量化并记录其影响，并承诺制定解决方案，以备将来使用。

技术债务神话4：只会伤害工程师

技术债务经常被视为开发人员的士气问题。 这种观点严重低估了技术债务对整个公司的影响。

技术债务以间接但深刻的方式影响着每个人 ：

• 通过阻碍开发人员快速交付高质量工作的能力， 开发人员会感到沮丧和不满。
• 产品经理 ，通过降低功能速度，增加错误并向发布计划中注入不可预测性，从而损害了利益相关者的信誉。
• 客户支持 ，通过增加质量问题和客户投诉，从而产生更多的电话和更多的案件。
• 技术操作 ，通过增加生产问题和安全漏洞的发生率，同时降低解决它们的速度，从而降低他们对系统的信心。
• 通过强迫客户报告系统中的更多错误和问题，并使他们接受延迟的产品发布和计划承诺，从而使客户受益。
• 执行团队 ，通过增加工程成本，同时降低路线图速度和客户满意度。

开发团队只是技术债务的“煤矿中的金丝雀”-如果他们不满意，那么除非采取任何措施，否则将来每个人都有可能不满意。

⭐对所有利益相关者进行技术债务影响方面的教育。 具体说明高优先级问题领域和解决问题的行动计划。

科技债务神话5：只有完全重写才能解决此问题

被忽略时，技术债务会迅速累积-加剧了速度，质量和士气的拖累。 当其影响变得显而易见时，情况似乎很可怕。 由于缺少特定技术债务项目的清单，该组织将其视为庞大的无定形云。 不久，开发人员就抛出了“完全重写”一词，描述了解决这种情况的唯一方法。

这是危险的领域，因为即使得出的结论没有根据，它也可能活出自己的生命，成为自我实现的预言：

认为``完全重写''是唯一解决方案的开发人员从宿命论的角度认为当前的代码库已无济于事，这可能导致采用编码捷径使情况变得更糟。与此同时，利益相关者不愿承受巨额价格和风险完全重写。 重写通常会遇到问题，花费的时间比预期的要长得多，并且最终会匆匆忙忙-导致全新的技术债务！

在极少数情况下，有必要进行完全重写； 但更详细的增量修复计划通常是最合适的，一次重写几个模块或组件。 团队必须采取严格的方法，确定最高优先级的项目并首先解决它们。 自动化的测试覆盖是必不可少的，因为清除后会立即发现任何副作用或破损。

⭐避免说“完全重写”，而是使用技术债务清单来确定每个季度要修复的组件/模块。

为了有效地管理技术债务，公司需要摆脱神话和误解，这些误解和误解阻碍了对特定问题及其处理方式的有意义的讨论。

您可以通过教育人员来解决自己公司中的技术债务。 消除神话-伟大的第一步是创建最坏问题的清单，并制定解决方案。

From: https://hackernoon.com/five-big-myths-surrounding-technical-debt-v53j32fd