【限时免费】岁尾最强一次云计算大年夜会,看传统、社区、互联网企业若何碰撞?
We can never see past the choices we don’t understand. – Oracle (The Matrix)
副标题是:“一个应用 code-maat, git, Python, D3.js 进行代码质量衡量的 case study“。

大年夜概是在2017年6月份吧,我当时在工作中作为一些小项目标负责人,收到了同事的一份报表,重要内容是经由过程 jsinspect ,检测出了有几个项目代码反复率比较高,提示我是否有些项目须要优化或部分重构一下。我当时第一次萌生了作为周期性项目,代码的质量是应当作为一个指标跟着迭代被量化,大年夜而指导后续项目迭代的,固然当时我据说过 sonar。随后我工作中介入了一个中间化代码质量评估系同一期的设计和开辟(主如果针对 javascript 代码的规范和质量检测与持续集成进行耦合),然则当时这个体系没有解决如许一个问题,即可以或许告诉我代率攀里具体哪部分存在更高优先级被重构的须要。半年以前了,如今我测验测验答复一下这个问题,并举一个与编程说话无关的一个通用可行的例子,经由过程这个例子揭示一个事实:
“代码的汗青,是代码将来的预言“
如不雅把项目代码比方成城市,那么体系中保护成本高的复杂部分就比如埋伏在城市中的罪犯,我们对于罪犯的搜查,显然不克不及对城市进行地毯式的搜刮,而是应当找到之前有过犯法记录的一些街区,划分重点区域进行排查,我们把这些区域,称为 hotspot,代码中也是,这些 hotspot 里,躲藏着具有最高优先级的须要调剂,优化与被重构的对象。

CodeCity 生成的“代码城市”,每个街区是一个 package,每个 class 是一个建筑,建筑的高度是 class 中办法的数量(这个对象是 OOP 说话专用的,比如 java,我们后续不谈论它)
我们的目标就是确认一个项目中的 hotspot 存在在哪儿。起首,我们不把代码复杂度作为确认 hotspot 的独一维度,代码复杂度很有效,然则单一把复杂度作为 hotspot 衡量的指标,会存在一些问题,最重要的问题就是一段复杂的代码,只有当我们真的须要存眷并修改它的时刻,它才是问题地点,如不雅没有人须要浏览或修改┞封段复杂的代码,它具体的复杂度是多是少又有什么关系呢?即便有人认为这种代码是准时炸弹,然则一个具有必定范围的体系中存在复杂模块是很正常的工作,一次性把这些复杂模块都作为 hotspot 标注出来并不合理,我们对 hotspot 进行调剂和优化也存在风险,以合适的策略却竽暌古化真正须要优化的部分是很重要的。
选择维度
在反竽暌功代码行数的 react_lines.csv 中,我们能看到一个新的维度:

我们应用代码更改的频率,作为消费开辟人员和时光的第一个维度。以 React 为例,我们看下它在 15.0.0(2016 年 4 月 9 日 release)和 16.0.0(2017 年 9 月 27 日 release)之间,都做了哪些修改。为了包管时光的一致性,我们先把项目时光切到 2017 年 9 月 27 日:
- git checkout `git rev-list -n 1 --before="2017-09-27" master`
我们来试着应用一下 code-maat,先看一下 React 在两个版本之间的一些汇总数据
接下来我们看一下大年夜 2016 年 4 月 9 日到 2017 年 9 月 27 日之间构造化的 git 日记:
git 提交日记
在我们本身重定向的 git 的日记文件 react_evo.log 中,我们应用 code-maat 去获代替码更改频率的数据,code-maat 应用 Clojure 编写,用于发掘和分析版本控制软件中的项目代码更改数据,我们把他 clone 下来,经由过程 leiningen 去编译它的 jar 包履行,或者你也可以把它放在体系路径中做成一个体系敕令,我本身也制造了一个 code-maat 的 Docker 镜像,地址是 code-maat。
汇总情况
可以看到两个版本之间提交次数,涉及文件的情况和开辟者人数的信息。我们再来看一下代码更改的频率,并生成一个 csv 文件:
- java -jar ../../code-maat/target/code-maat-1.1-SNAPSHOT-standalone.jar -l react_evo.log -c git -a revisions > react_freqs.csv

文件的修改次数排序
有了这些数据,就缩小了候选 hotspot 典范围,我们接下来,再增长别的一个断定模块范围的维度,即代码行数,代码行数这个维度简单粗暴,并且有两个好处,其一是可以或许查找便利快速;别的就是对于不合编程说话,它是中立的指标。我们应用 cloc 作为经由过程代码行数对项目进行分析的对象,它应用 Perl 编写(谁说 Perl 逝世了?),并且可以或许获得针对编程说话,文件,空格,注释和代码本身的很直不雅的输出,我们在 React 项目中来测验测验一下:
推荐阅读
【限时免费】岁尾最强一次云计算大年夜会,看传统、社区、互联网企业若何碰撞? 出力于“查”,筛选锁定疑点信息。面对改头换面、花样翻新的“四风”问题,发挥自身优势>>>详细阅读
本文标题:代码质量 – 代码的历史是代码未来的预言
地址:http://www.17bianji.com/lsqh/40179.html
1/2 1