不重视 TDD 与 Code Review 的代价

局长
 局长
发布于 2016年12月21日
收藏 38

近些年来,越来越多的人开始向我咨询测试驱动开发(TDD)的好处。所谓 TDD,就是在将代码进行部署之前,利用各种自动化测试来确保代码能够正常工作。在进行测试的时候,你需要寻找测试失败的地方,然后不断修改,必要的时候还需要对代码进行重写。实践证明,TDD 是软件开发过程中必不可少的一环。而且它还能够帮助企业和员工节省大量的时间。

近些年来,越来越多的人开始向我咨询测试驱动开发(TDD)的好处。所谓 TDD,就是在将代码进行部署之前,利用各种自动化测试来确保代码能够正常工作。在进行测试的时候,你需要寻找测试失败的地方,然后不断修改,必要的时候还需要对代码进行重写。

实践证明,TDD 是软件开发过程中必不可少的一环。而且它还能够帮助企业和员工节省大量的时间。

你需要知道的是,TDD 能帮你减少 40-80% 的代码错误修复时间。要知道,生产代码中的 bug 越多,你所需要付出的维护成本就越高。

BM System Sciences Institute 的研究显示,在生产阶段修复代码的时间,是在设计阶段修复代码时间的 100 倍以上,是部署阶段修复代码时间的 15 倍以上。

利用这组数据,我们来看看如果不使用 TDD,我们需要多花多少时间成本。如果没有 TDD,你的项目在部署阶段就需要花费 1000 个小时的时间,其中还没有包括维护时间成本: 

也就是说,TDD 能够帮你省下 623 个小时的时间,假如你的工程团队有 4 个人,这意味着能帮你省下 1 一个月的开发时间。美国开发者的平均年薪为 9.5 万美元,再算上这些人的福利,TDD 能帮你省下 3.7 万美元。

当然,这只是粗略的计算,TDD 能帮你省下多少成本,还应取决于很多其他因素。

但是 TDD 的重要程度依然可见一斑,它的确能够帮你节省下大量的时间和经济成本。

Code Review 的作用

和 TDD 一样,Code Review 也有着类似的作用。事实上,一些研究显示,Code Review 甚至比 TDD 更能帮你节省成本。1988 年的一项研究显示,一小时的 Code Review,能帮你在后期节省 33 个小时的代码维护时间。

这个数字看上去很惊人吧?但是我个人认为,在寻找 bug 方面,Code Review 并没有自动化工具好用。那么 Code Review 究竟有什么用处呢?

知识分享。在引入 Code Review 之后,你的团队会自动开始在彼此之间分享各自的知识、经验和工作方式。这样一来团队中的每个人都会开始更快的成长,初期工程师不断的向高级工程师进行学习,同时团队也开始不断成长。对于企业来说,拥有一个优秀的工程团队,是企业最重要的资产之一。

开发者最怕打扰

修复 bug 需要我们付出什么样的成本?在生产阶段修复代码,实际上其成本要远高于在开发阶段修复bug,而且会让开发者非常头疼。

在生产阶段发现 bug 之后,开发者必须要放下手头的工作,去解决这个 bug。换句话说,开发者本来正沉浸于一项工作当中,但是不得不跳出当下的情境 ,进入 bug 修复情境 。在修复了 bug 之后,再跳回到之前的情境中。

切换一次情境大约需要 20 分钟的时间。而且更糟的是,在发现了一个 bug 之后,很多时候意味着开发者此前做的工作都会受到这个 bug 的影响,他们很多的工作都需要推到重来。Microsoft Research 的研究显示,在受到打扰之后,开发者需要花费预期中双倍的时间来完成这个任务,而且出错的几率也会加倍。

让开发者去处理多任务,这绝对不是一个好主意。要想提高他们的工作效率,那就应该让他们专注于一件事情。

总结

如果有人对你说他们没有时间或是预算使用 TDD 和 Code Review 的时候,你不妨给他讲讲 TDD 和 Code Review 能帮他省下多少时间和经济成本。

原    文:The Outrageous Cost of Skipping TDD & Code Reviews
译    文:SDK.cn
作    者:鲁行云(编译)

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:不重视 TDD 与 Code Review 的代价
加载中

精彩评论

文星
文星
测试驱动开发(TDD)的好处被过于夸大,反倒Code Review 更应该被大力推广。
丁富贵
业务随时变,谁愿意写一堆马上就会报废的测试代码
excepiton
excepiton
理由:没时间

最新评论(17

SVD
SVD
还是多多进行code review吧
文星
文星

引用来自“文星”的评论

测试驱动开发(TDD)的好处被过于夸大,反倒Code Review 更应该被大力推广。

引用来自“VincentTone”的评论

TDD的效果其实还好,CR的效果也被夸大,这些东西都是和工作态度挂钩的,想的太简单。
工作态度固然重要,但是有效的Code Review更能保证软件的质量,特别是对于并发高,性能要求高等的软件来说,CR的效果远远大于TDD的效果。TDD也许在传统的软件开发与设计过程中会比较重要,前提还是要有足够的开发时间,测试代码同样是代码,如果测试代码质量不够好,一样达不到好的效果,反倒过于浪费时间来编写测试代码。
VincentTone
VincentTone

引用来自“文星”的评论

测试驱动开发(TDD)的好处被过于夸大,反倒Code Review 更应该被大力推广。
TDD的效果其实还好,CR的效果也被夸大,这些东西都是和工作态度挂钩的,想的太简单。
JuStajOkEsUn
JuStajOkEsUn

引用来自“丁富贵”的评论

业务随时变,谁愿意写一堆马上就会报废的测试代码

引用来自“Yamazaki”的评论

业务变化莫测是中国互联网行业通病,又尤其是初创型互联网企业!
算不上病吧,毕竟任何公司都是靠业务吃饭的,写代码只不过是为了实现业务而已.业务变了就是变了,不去拥抱变化只能等死
q
quleap
TDD就算了吧,反人类的。Test要有,但不应强制先写test。
Yamazaki
Yamazaki

引用来自“丁富贵”的评论

业务随时变,谁愿意写一堆马上就会报废的测试代码
业务变化莫测是中国互联网行业通病,又尤其是初创型互联网企业!
西南茂
西南茂
TDD 不是测试驱动开发么 。所谓 TDD,就是在将代码进行部署之前,利用各种自动化测试来确保代码能够正常工作。在进行测试的时候,你需要寻找测试失败的地方,然后不断修改,必要的时候还需要对代码进行重写。 感觉描述的有问题
丁富贵
业务随时变,谁愿意写一堆马上就会报废的测试代码
朱__朱
朱__朱
纯业务性的东西,还是BDD更方便,底层的东西不做TDD风险很高。CodeReview相当重要,我每次提交都会专门把变更反复看很多遍。
脆霉公园
脆霉公园

引用来自“克松”的评论

目前的现状是很多普通公司的技术管理层技术都没有及时跟新,也不是特别重视技术理念,更不愿意去尝试新技术,即使招了相关技术人员也很难发挥价值。觉得国内还是缺少技术氛围
赶着做项目啊
返回顶部
顶部