译文 | 一文看懂技术债

很多人搞不清楚技术债务、缺陷和非功能性需求之间的区别：

缺陷不能成为技术债务，因为技术债务并不意味着不满足功能或技术要求。

技术债务与糟糕的设计、糟糕的编码、不合适的设计模式、设计原则等有关，缺陷则与产品不适合、使用性能不佳等有关。

不满足非功能性需求=缺陷，而技术债务与之不同~

什么是技术债务？

技术债务是沃德·坎宁安 (Ward Cunningham) 创造的一个比喻：

技术债务类似于金融债务，软件开发就像是“贷款”，技术债务是它的“利息”，“利息”是需要未来额外的时间偿还的。

以下举例会更方便大家理解：

2007 年“我”从事保险产品的工作，团队使用的核心产品是用 AS400 编写的 WINS。

当时，“我”正在使用 asp.net 开发一个门户网站，由于后端是AS400，所以由另外一个团队编写中间件，原本应该编写中间件的团队负责开发，而我们本应该使用这些服务来使用asp.net 编写前端。

开局很好，但随着时间的推移，我们落后于计划。

每次我们需要更改时都会联系中间件团队进行更改，由于变化的需求太多，留给他们的反应时间也越来越短。

眼瞅着中间件团队的压力一天比一天大，前端团队开始试用绕过中间件团队，直接指向后端的流程管理方法，期望能够减少修复缺陷带来的时间损耗。

我们修复了缺陷，按时交付，所有此类更改的日志都被保留下来，以便中间件团队可以在日后更好的修复它们。不幸的是，“日后”从未来到—不断有新的变化出现，技术债务也越积越多。

同一个产品，生成策略的业务规则却又很多，XML被用来驱动这些规则，我们使用的是一个规则引擎。有一种方法用于生成策略，它与规则引擎相连，且该方法最初只有一个参数。

随着开发的进行，原本的团队成员离开，新人加入，他们都在代码中添加了更多行，但出于对已经工作的功能产生破坏的担心，他们不对现有代码进行任何更改，也无法找到更好的工具来解决这一问题。

其结果是可怕的，18 个月后，同一个方法有超过十个重载方法和远超过 10万行的代码……

功能虽完美，代码却是一场灾难——没有人试图重构代码来做简化，新开发人员需要 2 到 3 周的时间才能理解那里写的所有内容。

这里想做一点假设：若团队足够稳定、指导方针更优越、团队追求技术的专注和极致性，那这一切不会发生……

团队在 2009 年使用 WPF、WCF 和 SQL Server 开发了一个 EMR 应用程序，在WPF 很新、可用的经验丰富的开发人员却不多的情况下，自然而然的，团队在学习开发它上耗费了太多的时间。

尽管团队内对 MVVM 设计模式依旧不是很自信，但业务却希望尽快地发布它。于是，在对MVVM没有太多了解的前提条件下，团队内开始构建它了。虽然结果是好的，但人们编写了不容易理解的代码，并添加了许多将代码变的复杂的额外代码。

以上三个例子生动的向我们诠释了什么是技术债务不是缺陷，以及它们产生的原因：

这里又出现一个问题：

非功能性需求是需求，非技术债务。

如果页面需要更多时间来打开而产品经理对此有所抱怨，这表示产品经理在拒绝完善该功能的需求，而非技术债务。

同样，如果系统无法处理负载或错误消息不明确，则存在功能缺失，而非技术债务。

以下这些都是功能性需求：

LigaAI 新一代智能研发协作平台让 AI 为您的研发团队提供个性化、智能化的项目协作体验，化繁就简，帮助开发者专注、高效的创作！
本文作者：Naveen Kumar Singh