译文 | 一文看懂技术债开发

很多人搞不清楚技术债务、缺陷和非功能性需求之间的区别：
缺陷不能成为技术债务，因为技术债务并不意味着不满足功能或技术要求。
技术债务与糟糕的设计、糟糕的编码、不合适的设计模式、设计原则等有关，缺陷则与产品不适合、使用性能不佳等有关。
不满足非功能性需求=缺陷，而技术债务与之不同~
什么是技术债务？技术债务是沃德·坎宁安 (Ward Cunningham) 创造的一个比喻：
技术债务类似于金融债务，软件开发就像是“贷款”，技术债务是它的“利息”，“利息”是需要未来额外的时间偿还的。
以下举例会更方便大家理解：
01
2007 年“我”从事保险产品的工作，团队使用的核心产品是用 AS400 编写的 WINS。
当时，“我”正在使用 asp.net 开发一个门户网站，由于后端是AS400，所以由另外一个团队编写中间件，原本应该编写中间件的团队负责开发，而我们本应该使用这些服务来使用asp.net 编写前端。
开局很好，但随着时间的推移，我们落后于计划。
每次我们需要更改时都会联系中间件团队进行更改，由于变化的需求太多，留给他们的反应时间也越来越短。
眼瞅着中间件团队的压力一天比一天大，前端团队开始试用绕过中间件团队，直接指向后端的流程管理方法，期望能够减少修复缺陷带来的时间损耗。
我们修复了缺陷，按时交付，所有此类更改的日志都被保留下来，以便中间件团队可以在日后更好的修复它们。不幸的是，“日后”从未来到—不断有新的变化出现，技术债务也越积越多。
02
同一个产品，生成策略的业务规则却又很多，XML被用来驱动这些规则，我们使用的是一个规则引擎。有一种方法用于生成策略，它与规则引擎相连，且该方法最初只有一个参数。
随着开发的进行，原本的团队成员离开，新人加入，他们都在代码中添加了更多行，但出于对已经工作的功能产生破坏的担心，他们不对现有代码进行任何更改，也无法找到更好的工具来解决这一问题。
其结果是可怕的，18 个月后，同一个方法有超过十个重载方法和远超过 10万行的代码……
功能虽完美，代码却是一场灾难——没有人试图重构代码来做简化，新开发人员需要 2 到 3 周的时间才能理解那里写的所有内容。
这里想做一点假设：若团队足够稳定、指导方针更优越、团队追求技术的专注和极致性，那这一切不会发生……
03
团队在 2009 年使用 WPF、WCF 和 SQL Server 开发了一个 EMR 应用程序，在WPF 很新、可用的经验丰富的开发人员却不多的情况下，自然而然的，团队在学习开发它上耗费了太多的时间。
尽管团队内对 MVVM 设计模式依旧不是很自信，但业务却希望尽快地发布它。于是，在对MVVM没有太多了解的前提条件下，团队内开始构建它了。虽然结果是好的，但人们编写了不容易理解的代码，并添加了许多将代码变的复杂的额外代码。
以上三个例子生动的向我们诠释了什么是技术债务不是缺陷，以及它们产生的原因：

业务压力：企业关心功能而不是代码质量
并行开发：一个团队试图通过安排更多人来满足最后期限
缺乏技术技能和知识：在学习可接受的实践（例如 TDD、重构和紧急设计等）方面投入不足
缺乏文档：许多人认为敏捷意味着没有文档或不了解文档的价值
缺乏所有权：将开发外包
糟糕的设计技能：聘请经验较少的低成本工程师等

这里又出现一个问题：
什么是非功能性需求？非功能性需求是需求，非技术债务。
【译文 | 一文看懂技术债】如果页面需要更多时间来打开而产品经理对此有所抱怨，这表示产品经理在拒绝完善该功能的需求，而非技术债务。
同样，如果系统无法处理负载或错误消息不明确，则存在功能缺失，而非技术债务。
以下这些都是功能性需求：