技术债务管理以及Firefox/Chromium的债务评价
来源:互联网 发布:如何查询我的淘宝账号 编辑:程序博客网 时间:2024/05/01 19:55
现在的软件开发是在遍地敏捷,人人讲唯快不破的时代,哪有人有时间思考代码质量,设计的质量? 哪个又不是从一堆代码中杀出血路来实现另一个功能?一个产品都存活不了几年,何必考虑什么可维护性?
我们追求进度的时候,总是要牺牲些东西,或是破坏了一些东西等着后面补。这就是技术债! 管理不好,债台高筑,即使不破产,也是要拆东墙,补西墙的玩平衡。现实是残酷的,但不影响我们抬头看看这个世界。
技术债务
技术债务(Technical Debt)这个词,我最早是从InfoQ关于Uber的一个访谈中了解到的,正好也在思考持续重构的问题,发现它是推动持续重构的有效工具。所以花了点时间做些学习,在这里做个分享,主要来自这篇文章的学习,有时间的直接看原文就好了:
Technical Debt in Firefox and Chromium
关于技术债务,并不是新名词,就不考据它的历史了。其实很多团队都有类似的工具,比如:问题记录,优化点,TODO List等等。但是通常是比较松散,大杂烩式的,不系统。
我总结之前没有管理好有两点:
- 范围太大
在一篇IEEE 2012一期的文章(Technical Debt:From metaphor to Theory and Practice)里也强调了一个重要的观点,Technical Debt不要同需求和Bug搞在一起, 应当聚焦在对未来有负作用的设计和实现,通常都是无法直接感知的。比如性能优化到多少多少,这不是技术债务。回想以前做的优化点,太过于聚焦于功能,更像为了未来开发工作安排的参考。 - 缺少到位的管理
如果一件事只是追求锦上添花,它自然就会被排到低优先级。然后,太天真了,其实没有然后了。
对策就不说了,这是一个管理问题,见仁见智。如果没有意识,或者正如开头说的,如果觉得没有必要的话,确实不需要做什么,因为大家都差不多。
如果想要做,我们如何定义和评估技术债务呢? 向领先者学习!FireFox和Chromium都算是比较大的开源项目了,分别是280万行和470万行的规模。看看他们的总结就是很好的学习了。核心是以量化的方式评价和管理代码,工具是基于SciTools Understand。(其实以发现&记录的方式也很好,这里只是作为参考的方式。)
技术债务的量化 (即代码质量的评价)
主要来自How maintainable is the Firefox codebase?。要优化,就要先定义问题和评价的标准。
以下代码质量评价的维度:
- LOC (代码行数)
代表了代码的规模。可以用这个:cloc
代码量越大,系统的复杂越高,但是相对的Bug率反而越低。评估的对象没有说明,显然是针对设计良好的系统。如果架构设计良好,并且大家都遵守,这样新增的功能都会集中以组件的形式实现,并不会改变接口,这是Bug没有扩散的原因。 - 圈复杂度
不多说了,不知道的看这里:圈复杂度评价及工具。如果要严谨的定义,以软件工程类书中的定义为准。 - 一阶密度 (First-Order Density)
用于评估文件间的直接依赖程度,因为是直接依赖,所以是一阶,里面只有A和B的关系。对应的工具是DSM, Design Structure Matrix。Github上可以找到一个工具,我没有试过。 - 变更成本 (Propagation Cost)
评估随意的改一个文件,平均会影响到多少文件。它可以反应直接依赖的一阶关系,也可以随着间接依赖层次上升的高阶关系。
这也是一个衡量架构设计的重要指标。欢迎推荐相关的工具。 - 核心代码大小 (Core size)
所以核心代码,是从依赖关系上定义的。如果文件间有着环形依赖形式的高度依赖就是所谓的核心代码。很多研究已经证明,这类的代码量越小,Bug就越少。
工具
代码静态分析工具
LOC, 圈复杂度,以及依赖关系这些都容易通过一个静态分析工具来获得。
比如两者的代码量变化:
两者的圈复杂度:网络化处理 (Network Multiplication)
通过网络化处理,可以得出变更成本,一阶密度,核心代码大小的数据。
下图为Firefox&Chromium变更成本的比较:
下图则是Core size的对比:- DSM工具。
DSM其实很简单。就是描述系统中各个元素的有无关系。横轴和纵轴都是系统各个元素,如果i,j有关联,则矩阵中(i,j)就是为true,或者作个标记。
下图就是作者提供的一张Firefox 16的DSM:
左侧为直接依赖,右侧为间接依赖。
更详细的内容,参考:Technical Debt in Firefox and Chromium
数据可以在这里体验:http://www.almossawi.com/firefox/
完整的文档在Github上:Tools
其大致的处理流程如下图:
总结
技术债务的定义只是参考,更重要的还是意识和执行。有了基本概念和意愿,执行的工具就很灵活,完全一个技术管理的行为。
关注微信公众号交流:
转载请注明出处: http://blog.csdn.net/horkychen
- 技术债务管理以及Firefox/Chromium的债务评价
- 技术债务
- 技术债务(母鸡的遭遇)
- 技术债务真正的代价
- 技术债务真正的代价
- .技术债务真正的代价
- 技术债务(母鸡的遭遇)
- 技术债务(母鸡的遭遇)
- 老码农看到的技术债务
- 从经理的角度看技术债务
- 如何解释技术债务(母鸡的遭遇)
- 从经理的角度看技术债务
- 技术债务可能是这样来的
- 技术债务可能是这样来的
- 全栈看到的技术债务
- 技术债务与程序员的信用
- 技术债务与程序员的信用
- 解析技术债务
- C++的反思
- redhat 6.4 安装ftp
- C#代码读写XML
- 机器学习也能成为“妇女之友”
- java中set\map自定义去重依据(重载Bean类的hashcode和equals)
- 技术债务管理以及Firefox/Chromium的债务评价
- Delphi7 中使用FastMM
- linux ubuntu 下 html 访问外部文件夹 的方法
- 每天学一点2
- Android webView 缓存 Cache + HTML5离线功能 解决
- {Java}一个有关类属性初始化的有趣儿情况
- 《编程导论(Java)·3.3.2 按值传递语义》
- 把你的代码卸载到GPU(用GPU编程):如何开始
- 数组、容器类(List\Set\Map)等的toString方法