技术债务:究竟让你付出了多大代价?

标签: 程序员 管理 技术债务 | 发表时间:2012-09-13 10:23 | 作者:
出处:http://blog.jobbole.com

技术债务背后的 隐含的意思是,走捷径(有意的技术债务)或者犯错(无意的技术债务)都会有开销,而且不处理这些捷径或者错误的话,开销会随着时间而增加。

如果我们有一个财务债务,我们知道我们今天需要还掉多少钱,我们也可以计算出我们将来需要付多少利息。而技术债务却是模糊不清的,我们不知道我们已经欠了多少债了 – 你可能已经欠了许多无意的技术债务了 – 你也可能不知情的状况下欠了许多债。我们没办法具体测量出我们已经花了多少了 – 我们已经付了多少利息了,如果我们今天不注意的话,我们将来也不会知道我们总共花了多少了。

一些人试图将技术债务用具体的 金融术语来表述。例如,根据CAST的 软件报告,“对于应用程序,一行代码平均要花$3.61”。由于某种原因,java的程序平均花销要高些: 每行$5.42。这些数据来自于他们的客户代码的统计分析。

Sonar,一个管理代码质量的开源项目,也试着对一个代码库的技术成本进行了计算。他们也用了统计分析的方法,对自动测试用例的代码覆盖率,代码覆盖性,重复率,不遵循代码惯例的代码以及注释的密度等进行了分析。

这种方法来急速技术债务很有意思,但我们不能认为这些能作为真正的数据来帮我们做出业务决策。尽管这些数字是精确的,但它们仅仅是主观的猜测。他们假设技术账单可以靠分析代码的结构来计算。但是计算技术债务并没有那么简单。

但是这个账单太模糊了,不能用来评估具体的价格。你觉得哪个类型的开销对你的损害最大,你如何知道何时你花了太多了?让我们来看看不同的技术账单,采用模糊的方法来计算你花了多少。

The true cost of technical debt 2

 

$$$ 在架构或是平台技术方面犯了一个基础的错误 – 你发现的时候已经来不及了,用户已经在使用系统了;或者是数据库或消息构造不能扩展,可靠性低;或者是由于核心的依赖问题,你没办法按照需要扩展架构;或者是你对系统如何工作或是用户如何使用系统进行了一些不正确的预测。现在没有选择了,只能重新开始或者重写系统的很大部分,能让系统能继续运作,通常你没有足够的时间来正确重写。

$$-$$$ 容易出错的代码 – 80%的错误出现在20%的代码中。 Capers Jones说过所有的大系统中,有很少的一部分函数是错误的集中处,代码很难理解,要修改它们是很危险的而且代价昂贵的,因为它们一开始就写得很烂,或者是因为一些短视的错误修正的积累,使得代码随着时间而腐烂。没有重写这些代码是 程序员犯的最昂贵的错误。

$-$$ 系统测试不易 – 因为你没有好的自动测试用例,或者当你改变代码的时候,测试用例变得支离破碎。测试的开销占更改代码带来的开销的一半以上 – 当你写了更多的代码,当系统增加了更多的接口和功能的时候,测试的开销会随之增加。

$-$$ 不注意打包,发布和部署。太过依赖人手检测,很容易在代码上线的时候造成错误。就像测试一样,发布和部署带来的开销不会消失,会逐渐的增加。

$-$$ 代码很神秘的工作,而没有人知道为什么 – 通常涉及到关键性能或关键安全的底层代码是由已经离开公司很久的一个奇才所写的。可能是很漂亮的代码,但团队里没有人能理解它。它就是个定时炸弹,某一天,某个人可能会试着更改它,或修改它。

$-$$ 向前向后的兼容性。这是必须的,短期的债务。但当你需要维护这些兼容版本的时间越长,代价会越大。

$-$$ 库和中间件过期 – 你可能没有来得及打补丁和升级了。尽管现在的代码还很稳定,但你可能遭受没打补丁的安全性危险。这个过程越久,你拉下的补丁越多,危险越大 – 如果你不再作技术支持了,可能某一天又会有人找到你。

$-$$ 重复的,复制粘贴的代码。这是最令人讨厌的技术债务之一。几乎每一个都会写它们。但是到底有多糟糕?这个开销取决于开发者写了多少重复的代码,他们多长时间要更改它们一次,在不同的复制部分有多少细小的不同,你能否很轻易的找到重复的代码并追踪它们。如果写重复代码的程序员还在团队里,并且能很好的追踪代码,这就不会有太大的开销。

$-$$ 大家都知道的,很明显的错误,并且没有被修复的。这个开销取决于你有多少错误和警告,它们到底有多么的糟糕。如果它们是这种的问题的话,它们应该已经被修复了。如果一个错误没有造成问题的话,它还是错误吗?

$-$$ 低效的设计或构建,过度消耗硬件,使用过多的内存,网络带宽或cpu。硬件是很便宜的,但当你要进行扩展的时候还是要花掉很多的。

$ 使用编程习惯和模式不一致 – 程序员不理解已经存在的模式,或是不喜欢它们,而引进新的模式,或者仅仅是想改变它们。这样做会很糟糕,对程序员来说会很挫败。但让程序就这么存活下去的开销往往要比全部清理干净的开销要小。

$ 没有错误处理和异常处理,或者方法不对。在上线阶段会让你很受伤,但通常开销不会很大,至少你让大部分都正常运行。

$0.01 硬编码,神秘的数字,代码不遵循规范,混乱的命名,缺失的注释,不整洁的代码。这确实很糟糕,但这些都很容易经过 重构的工作清理干净。

$0.01 文档过期 – 这经常被认作是技术债务。但老实讲,大部分程序员都不读文档。如果没有人使用文档,那么就放弃它们。如果人们在使用它,为什么它们会过期呢?

$0.00 应该使用语言自带的功能,库,框架来写的代码却用手重写了。当某人意识到的时候是很失望的,但如果这些代码没有太多的错误的时候,这是个沉没成本,而不是会随时间增长的成本。

 

不同的债务有不同的开销。找出你的开销主要在什么地方,已经如何处理它们,不是一件容易的事情。

 

原文: swreflections.blogspot.hk   编译: 伯乐在线 – 唐小娟

【如需转载,请标注并保留原文链接、译文链接和译者等信息,谢谢合作!】

 

相关文章

相关 [技术债务] 推荐:

技术债务偿还计划

- - 博客园_知识库
  许多团队都受技术债务困扰,不过,很少有团队能真正地设计一个计划从中挣脱出来. 为了更好的理解如何才能摆脱债务,我们首先要正确地理解什么是技术债务.   技术债务是由团队为了短期的项目利益故意做了欠佳的技术决策而招致的. 例如,为了使一个产品更快的投放市场,团队可能不会像面对一段棘手的代码那样,编写深入的自动化测试.

【外刊IT评论网】技术债务(母鸡的遭遇)

- - 外刊IT评论
[caption id="attachment_3749" align="alignright" width="300" caption="本文的作者 Andrea Dallera"] [/caption]. 技术债务,是指匆忙的实现一个功能,却对现有的程序库造成了破坏(在实现的过程中污染了代码库的设计),这对于一些项目经理/客户来说就像是天书奇谈.

技术债务:究竟让你付出了多大代价?

- - 博客 - 伯乐在线
技术债务背后的 隐含的意思是,走捷径(有意的技术债务)或者犯错(无意的技术债务)都会有开销,而且不处理这些捷径或者错误的话,开销会随着时间而增加. 如果我们有一个财务债务,我们知道我们今天需要还掉多少钱,我们也可以计算出我们将来需要付多少利息. 而技术债务却是模糊不清的,我们不知道我们已经欠了多少债了 – 你可能已经欠了许多无意的技术债务了 – 你也可能不知情的状况下欠了许多债.