InfoQ

新闻

解析技术债务

作者 Vikas Hazrati 译者 张龙 发布于 2009年10月27日 上午5时43分

社区
Agile
主题
敏捷技术,
质量交付

术语”技术债务“是由Ward Cunningham首次提出,指的是开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案,但从长远来看,这种方案会带来更消极的影响,亦即开发团队所欠的债务。敏捷专家们就技术债务到底是什么以及如何对其进行分类给出了自己的看法。

Martin Fowler认为下面的定义最能表现技术债务的含义:

技术债务类似于金融债务,它也会产生利息,这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多努力的后果。我们可以选择继续支付利息,也可以通过重构之前鲁莽的设计来将本金一次付清。虽然一次性付清本金需要代价,但却可以降低未来的利息。

Steve McConnell将技术债务分为两类

  • 无意的——由于经验的缺乏导致初级开发者编写了质量低劣的代码。
  • 有意的——团队根据当前而非未来进行设计选型,这种方式可能很快就能解决当前的问题,但却很拙劣。

Bob大叔补充到,有时人们将坏味道也看作是技术债务,但这是错误的,他说:

坏味道并非技术债务。坏味道就是坏味道。技术债务的评价标准是真实的项目约束,这些约束是风险和好处并存的。坏味道的产生永远都不是理性的结果,而是由懒惰和外行导致的,未来也没有机会偿还了。坏味道总是意味着损失。

Bob大叔说技术债务让人们时刻牢记保持代码的整洁,就好像一个人在背负巨大的抵押债务时需要时刻保持警醒一样。他又说一旦团队决定采纳技术债务,那就意味着保持代码的整洁将变得空前的重要。如果不这样,情况很快就会变得糟糕不堪,偿还这些债务的代价也变得越来越大。

Martin Fowler认为坏味道也是技术债务,只不过是另一种形式的技术债务而已。他觉得坏味道是一种不计后果(reckless)的债务,相对于根据精确计算而得来的谨慎的(prudent)债务而言,坏味道会让问题变得更加严重。他又加上了故意(deliberate)以及无意(inadvertent)从而将技术债务划分为四个象限。

Martin通过如下示例将技术债务划分为4个象限

  1. 不计后果,故意的——团队没有时间做设计,仅仅给出了一个匆忙做出的方案,缺乏对质量的预见。
  2. 谨慎,故意的——尽管有很多已知的缺陷,但团队必须现在交付产品,同时对此造成的后果心中有数。
  3. 不计后果,无意的——团队压根就不知道基本的设计原则,更不用说引入的坏味道了。
  4. 谨慎,无意的——那些拥有优秀设计师的团队很容易遇到这种情况。他们交付的方案具有商业价值,但在完成方案后才明白什么才是最好的方案。

综上所述,实际的项目中将不可避免地存在技术债务问题,这是无法杜绝的,但问题的关键在于千万不能引入不计后果的债务,因为它会持续不断地产生坏味道,也很难对付。

查看英文原文:Dissecting Technical Debt

重点是Martin对Technical Debt的概念澄清 发表人 Ming Jin 发表于 2009年11月3日 上午6时51分
  1. 返回顶部

    重点是Martin对Technical Debt的概念澄清

    2009年11月3日 上午6时51分 发表人 Ming Jin

    Technical Debt is a metaphor, so the real question is whether or not the debt metaphor is helpful about thinking about how to deal with design problems, and how to communicate that thinking. A particular benefit of the debt metaphor is that it's very handy for communicating to non-technical people.
    由此可见,是否技术债务在很大程度上并不是由开发团队决定的,而是开发团队和客户在沟通的过程中达成的共识。此外,无论与否,都是缘木求鱼而已

深度内容

模块化Java:声明式模块化

本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。

Ian Robinson和Jim Webber谈论基于Web的整合

本采访是在伦敦举行的QCon2009上记录的,Ian Robinson和Jim Webber探讨了如何将Web作为整合平台以及REST在理论上和实践中的好处。

项目管理修炼之道(精选版)

项目管理对于项目成败至关重要,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。书中从应对实际风险的角度出发,讲述了从项目启动、项目规划到项目结束的整个管理流程,展示了作者的思考过程。本迷你书从原书中精选出5个章节。

那是鸟,还是飞机?不,那是超人!

在这个演讲中,Fred将会揭示敏捷的一些外在因素,并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看,Fred认为:工具、管理体系都不能让你变得敏捷。敏捷的成功,植根于士气高涨、充分授权的工作者身上,他们能够以不同以往的方式思考问题。

访谈和书摘:Eben Hewitt的新书《Java SOA Cookbook》

Java SOA Cookbook

Eben Hewitt的新书《Java SOA Cookbook》从Java实现的角度讨论了面向服务架构。Eben在书中讨论了SOA基础、工具、最佳实践和SOA治理等主题。

Mark Richard的《Java消息服务》第二版

Mark Richards的新书《Java消息服务》第二版覆盖了JMS的许多主题, 包括发布和订阅模式以及点对点模式,消息过滤和事务等。InfoQ与Mark谈论了跟他的新作。

模块化Java:动态模块化

本文是“模块化Java”系列文章的第三篇,讨论动态模块化,内容涉及如何解析bundle类、bundle如何变化、以及bundle之间如何通信。

让测试也敏捷起来

对于测试组织来说,敏捷方法带来的快速迭代却让测试本身变得困难起来:缺乏“足够详细的文档”,缺乏“仔细设计用例的时间”等等。在本演讲中,段念将与大家探讨如何在敏捷过程中进行测试。