译文 | 一文看懂技术债
很多人搞不清楚技术债务、缺陷和非功能性需求之间的区别:
缺陷不能成为技术债务,因为技术债务并不意味着不满足功能或技术要求。
技术债务与糟糕的设计、糟糕的编码、不合适的设计模式、设计原则等有关,缺陷则与产品不适合、使用性能不佳等有关。
不满足非功能性需求=缺陷,而技术债务与之不同~
什么是技术债务?
技术债务是沃德·坎宁安 (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
评论