技术债务管理以及Firefox/Chromium的债务评价

刺骨的言语ヽ痛彻心扉 2022-08-02 00:29 147阅读 0赞

现在的软件开发是在遍地敏捷，人人讲唯快不破的时代，哪有人有时间思考代码质量，设计的质量？ 哪个又不是从一堆代码中杀出血路来实现另一个功能？一个产品都存活不了几年，何必考虑什么可维护性？

我们追求进度的时候，总是要牺牲些东西，或是破坏了一些东西等着后面补。这就是技术债！ 管理不好，债台高筑，即使不破产，也是要拆东墙，补西墙的玩平衡。现实是残酷的，但不影响我们抬头看看这个世界。

## 技术债务 ##

技术债务(Technical Debt)这个词，我最早是从InfoQ关于Uber的一个访谈中了解到的，正好也在思考持续重构的问题，发现它是推动持续重构的有效工具。所以花了点时间做些学习，在这里做个分享，主要来自这篇文章的学习，有时间的直接看原文就好了:  
[Technical Debt in Firefox and Chromium][]

关于技术债务，并不是新名词，就不考据它的历史了。其实很多团队都有类似的工具，比如:问题记录，优化点，TODO List等等。但是通常是比较松散，大杂烩式的，不系统。

我总结之前没有管理好有两点:

1.  范围太大  
    在一篇IEEE 2012一期的文章(Technical Debt:From metaphor to Theory and Practice)里也强调了一个重要的观点，Technical Debt不要同需求和Bug搞在一起, 应当聚焦在对未来有负作用的设计和实现，通常都是无法直接感知的。比如性能优化到多少多少，这不是技术债务。回想以前做的优化点，太过于聚焦于功能，更像为了未来开发工作安排的参考。
2.  缺少到位的管理  
    如果一件事只是追求锦上添花，它自然就会被排到低优先级。然后，太天真了，其实没有然后了。

对策就不说了，这是一个管理问题，见仁见智。如果没有意识，或者正如开头说的，如果觉得没有必要的话，确实不需要做什么，因为大家都差不多。

如果想要做，我们如何定义和评估技术债务呢？ 向领先者学习！FireFox和Chromium都算是比较大的开源项目了，分别是280万行和470万行的规模。看看他们的总结就是很好的学习了。核心是以量化的方式评价和管理代码，工具是基于[SciTools Understand][]。(其实以发现&记录的方式也很好，这里只是作为参考的方式。)

## 技术债务的量化 (即代码质量的评价) ##

主要来自[How maintainable is the Firefox codebase?][How maintainable is the Firefox codebase]。要优化，就要先定义问题和评价的标准。  
以下代码质量评价的维度：

1.  LOC (代码行数)  
    代表了代码的规模。可以用这个:[cloc][]  
    代码量越大，系统的复杂越高，但是相对的Bug率反而越低。评估的对象没有说明，显然是针对设计良好的系统。如果架构设计良好，并且大家都遵守，这样新增的功能都会集中以组件的形式实现，并不会改变接口，这是Bug没有扩散的原因。
2.  圈复杂度  
    不多说了，不知道的看这里:[圈复杂度评价及工具][Link 1]。如果要严谨的定义，以软件工程类书中的定义为准。
3.  一阶密度 (First-Order Density)  
    用于评估文件间的直接依赖程度，因为是直接依赖，所以是一阶，里面只有A和B的关系。对应的工具是DSM, Design Structure Matrix。Github上可以找到一个工具，我没有试过。
4.  变更成本 (Propagation Cost)  
    评估随意的改一个文件，平均会影响到多少文件。它可以反应直接依赖的一阶关系，也可以随着间接依赖层次上升的高阶关系。  
    这也是一个衡量架构设计的重要指标。欢迎推荐相关的工具。
5.  核心代码大小 (Core size)  
    所以核心代码，是从依赖关系上定义的。如果文件间有着环形依赖形式的高度依赖就是所谓的核心代码。很多研究已经证明，这类的代码量越小，Bug就越少。

## 工具 ##

1.  代码静态分析工具  
    LOC, 圈复杂度，以及依赖关系这些都容易通过一个静态分析工具来获得。  
    比如两者的代码量变化:  
    ![loc][]  
    两者的圈复杂度:  
    ![mccabe][]
2.  网络化处理 (Network Multiplication)  
    通过网络化处理，可以得出变更成本，一阶密度，核心代码大小的数据。  
    下图为Firefox&Chromium变更成本的比较:  
    ![progation cost][]  
    下图则是Core size的对比:  
    ![core size][]
3.  DSM工具。  
    DSM其实很简单。就是描述系统中各个元素的有无关系。横轴和纵轴都是系统各个元素，如果i,j有关联，则矩阵中(i,j)就是为true，或者作个标记。  
    下图就是作者提供的一张Firefox 16的DSM:  
    ![Firefox16 DSM][]  
    左侧为直接依赖，右侧为间接依赖。

更详细的内容，参考:[Technical Debt in Firefox and Chromium][]  
数据可以在这里体验:[http://www.almossawi.com/firefox/][http_www.almossawi.com_firefox]  
完整的文档在Github上:[Tools][]  
其大致的处理流程如下图:  
![processing][]

## 总结 ##

技术债务的定义只是参考，更重要的还是意识和执行。有了基本概念和意愿，执行的工具就很灵活，完全一个技术管理的行为。

关注微信公众号交流:  
![20150705201941850][]

转载请注明出处: [http://blog.csdn.net/horkychen][http_blog.csdn.net_horkychen]

[Technical Debt in Firefox and Chromium]: http://almossawi.com/firefox/prose-part-two/
[SciTools Understand]: https://scitools.com/
[How maintainable is the Firefox codebase]: http://almossawi.com/firefox/prose/
[cloc]: http://cloc.sourceforge.net/
[Link 1]: http://blog.csdn.net/horkychen/article/details/6996847
[loc]: /images/20220731/7391139642e84604b9a3faddb5713e4a.png
[mccabe]: /images/20220731/db172d447f5d464f992e8e52e80d58d6.png
[progation cost]: /images/20220731/403314d59e164b84ab6cf2bb680a46ae.png
[core size]: /images/20220731/e441219b00674efb903cfe4567c9786d.png
[Firefox16 DSM]: /images/20220731/028df4e000cb4722a8cc6136f79845c0.png
[http_www.almossawi.com_firefox]: http://www.almossawi.com/firefox/
[Tools]: https://github.com/almossawi/Firefox-Codebase-Evolution/
[processing]: /images/20220731/b29d3442758849d080e1e512f653d7a8.png
[20150705201941850]: /images/20220731/6b475656dc3c48c0aec4872d257017bc.png
[http_blog.csdn.net_horkychen]: http://blog.csdn.net/horkychen