很多人搞不清楚技术债权、缺点和非功能性需要之间的区别：
缺点不能成为技术债权，因为 技术债权并不意味着不满足性能或技术要求。
技术债权与蹩脚的设计、蹩脚的编码、不适合的设计模式、设计准则等无关，缺点则与产品不适宜、使用性能不佳等无关。
不满足非功能性需要 = 缺点，而技术债权与之不同~
什么是技术债权？
技术债权是沃德·坎宁安 (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、重构和紧急设计等）方面投入有余
- 不足文档：许多人认为麻利意味着没有文档或不理解文档的价值
- 不足所有权：将开发外包
- 蹩脚的设计技能：延聘教训较少的低成本工程师等
这里又呈现一个问题：
什么是非功能性需要？
非功能性需要是需要，非技术债权。
如果页面须要更多工夫来关上而产品经理对此有所埋怨，这示意产品经理在回绝欠缺该性能的需要，而非技术债权。
同样，如果零碎无奈解决负载或谬误音讯不明确，则存在性能缺失，而非技术债权。
以下这些都是功能性需要：
- 数据安全
- 治理用户会话并爱护它
- 拣货时段和非拣货时段的服务器负载治理
- 页面加载工夫
- 服务器响应工夫
- 正确的日志治理
- 政府合规等
LigaAI 新一代智能研发合作平台 让 AI 为您的研发团队提供个性化、智能化的我的项目合作体验，化繁就简，帮忙开发者专一、高效的创作！
本文作者：Naveen Kumar Singh