写点什么

译文 | 一文看懂技术债

作者:LigaAI
  • 2022 年 3 月 02 日
  • 本文字数:1541 字

    阅读完需:约 5 分钟

译文 | 一文看懂技术债

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

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

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

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

什么是技术债务?


技术债务是沃德·坎宁安 (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

用户头像

LigaAI

关注

新一代智能研发管理平台 2021.02.23 加入

AI赋能工作场景,想要做最懂开发者的智能研发管理平台~

评论

发布
暂无评论
译文 | 一文看懂技术债_场景应用_LigaAI_InfoQ写作平台