首页 资讯频道 互联频道 智能频道 网络 数据频道 安全频道 服务器频道 存储频道

自上而下的代码分析 如何快速识别项目水平?

2020-09-22 11:09:38 来源 : phodal公众号

软件开发是一个非常有意思的复制 + 粘贴活动。开发业务代码的时候,大部分人都不会不加思索地添加代码。毕竟,聪明的产品经理/项目经理们,天才式地想出了用代码行数的方式来计算 KPI,又或者是通过提交次数来进行考核 —— 虽然小步提交是个好东西,但是吧,大部分人不经过练习还是掌握不会的。

好了,回到正题。

自上而下的代码分析

最近,刚好因为项目的关系,需要分析某一系统的代码行数。通过一系列的复制 + 粘贴和 Excel 操作,我大致有了一套 DIY 的自动化分析方案:自上而下的代码分析。当然了,这肯定不是我先发明的,在某处一定有论文和代码、工具。只是我依据自己的想法和需求,完善了一下现有的方案。要知道,已经有大量地代码分析工具了。

其实总体的思路非常简单:项目行数 -> 包行数 -> 修改历史 -> 引用分析。

具体来说,就是:

通过代码行数(LOC)统计工具,统计总体的代码情况。

结合代码行数(LOC)统计工具,统计各个包的代码情况

获取 Git 提交历史,统计出经常修改的包或者是类。

构建语法树、制品(如 jar)分析,统计出引用次数最多的包。

唯一麻烦的地方就是做一些自动化。所以,这些功能就被我完善到 Coca 里了。

好了,让我们来看个示例。这里以开源项目 intelli-community (即 IDEA 的社区版)为例。

项目级代码行数

市面上已经有大量的行数统计工具,大家可以自行寻找。这里我用的是 Coca ,集成了三方用 Go 实现的 CLOC 统计功能。

首先呢,我们要实现的是分析整个项目的行数情况 coca cloc . :

LanguageFilesLinesBlanksCommentsCodeComplexity

───────────────────────────────────────────────────────────────────────────────

Java6655451723016880545126303971617603221

Python10017424614316293487635810922329

Kotlin6383602814891303566047802451292

PlainText4105635689579906298900

Groovy339715481723296123641191574683

XML25494940741005630084810100

HTML23296333129883623567200

SVG2124210782387209680

JSON115534679535203464430

Shell535829511387346423811

Markdown42596601434082260

PropertiesFile3844206925451348381760

YAML38432642025530070

XMLSchema3451966491796301786860

JavaScript1693056915625151238563895

...

───────────────────────────────────────────────────────────────────────────────

Total10190883899848988936294976861594703260

───────────────────────────────────────────────────────────────────────────────

EstimatedCosttoDevelop$288,297,976

EstimatedScheduleEffort132.017220months

EstimatedPeopleRequired258.681675

嗯,从规模上来看,这真的是一个超级大的项目,接近 700 万行的规模。所以,我第一次看到的时候,也不知道从哪里下手,于是我便想着是不是从包(目录)结构能解决这个问题。

PS:Coca 当前只支持单体分析,考虑有多模块和微服务系统的存在,我会在未来必要的时候,添加对应的实现。

按目录分析

简单来说就是,我们可以按目录执行 cloc,然后汇总结构即可。

所以,进一步地我们就可以执行 coca cloc . --by-directory,得到一个 CSV 数据,根据自己的需要进行编辑:

package summary Java Python Kotlin Plain Text
platform 1800542 1460686 106 244586 4669
java 1479891 1059828 0 35224 267792
plugins 1765695 983860 70301 151816 150158
android 1865010 769437 52 325659 101848
python 664760 240080 287641 24626 17855
xml 866926 108794 0 207 174471
jps 66671 63437 0 1498 729

还可以绘制成图表。

除此,我还提供了一个 --top-file --top-size 10 的参数,以了解行数最多的几个文件。

|LENGTH|COMPLEXITY|LOCATION|

|--------|------------|-----------------------------------|

|1642|236|ConstraintLayoutHandler.java|

|1492|375|ConstraintComponentUtilities.java|

|1189|166|CommonActions.java|

|1184|325|ConstraintWidget.java|

|1169|129|SingleWidgetView.java|

|1115|213|ScoutArrange.java|

|1097|281|ScoutWidget.java|

|1081|224|3d/Rasterize.java|

|1016|159|LayoutlibSceneManager.java|

|1014|220|TimeLinePanel.java|

接着,只需要层层下推,我们就可以分析出哪个是系统最复杂的一部分。如下图中的复杂点,依次是:platforms、java、plugins、android。

变更频次

紧接着,我们就可以通过获取 Git 提交历史来知道,对应文件的修改变化。这里,我依旧使用的是 coca git -t。它源自于对于 git log --all --date=short --pretty="format:[%h] %aN %ad %s" --numstat --reverse --summary 命令的分析结果,有兴趣的读者可以参考 Coca 的源码,自行编写不同版本地对应实现。

可怕的是,我在 intellij-community 执行了 coca git -t 之后,生成了一个 241M 的文件,回去 GitHub 看了一眼:累计 290,459 次提交。

在我第一次没意识到应该记录下 log 之后,我又重新执行了一遍。最终,拿到了结果:

|ENTITYNAME|REVSCOUNT|AUTHORCOUNT|

|-------------------------------------------------------------------------------------------------------------|-----------|-------------|

|platform/util/resources/misc/registry.properties|2473|224|

|platform/platform-impl/src/com/intellij/openapi/editor/impl/EditorImpl.java|1211|149|

|platform/platform-api/resources/messages/IdeBundle.properties|1209|181|

|platform/platform-resources/src/META-INF/LangExtensions.xml|1206|192|

|plugins/InspectionGadgets/InspectionGadgetsAnalysis/resources/messages/InspectionGadgetsBundle.properties|1113|159|

|platform/platform-resources-en/src/messages/ActionsBundle.properties|1004|161|

|platform/platform-resources/src/META-INF/PlatformExtensions.xml|937|162|

|platform/util//src/com/intellij/util/ui/UIUtil.java|779|120|

|platform/platform-impl/src/com/intellij/openapi/application/impl/ApplicationImpl.java|763|133|

|platform/platform-resources/src/META-INF/LangExtensionPoints.xml|762|150|

|platform/lang-impl/src/com/intellij/util/indexing/FileBasedIndexImpl.java|684|126|

|java/java-analysis-impl/src/com/intellij/codeInsight/daemon/impl/analysis/HighlightUtil.java|675|117|

|platform/platform-resources/src/idea/PlatformActions.xml|671|139|

然后,看一眼 registry.properties 是一个有 1800+ 行的配置文件,EditorImpl.java 是一个有 5000+ 行的 Java 代码,UIUtil.java 也有 3600+ 行……。嗯,效果是不是也相当理想,再看看 UIUtil.java 这一个名字,一看就非常适合重构。

高引用

最后,可能会进入慢的一步,分析代码,生成 AST。考虑到 IDEA Community 的这个代码量。我就不重复演示了,以 GitHub 的示例为例 coca count:

+------------+--------------------------------------------------------------------------+

|REFSCOUNT|METHOD|

+------------+--------------------------------------------------------------------------+

|2|com.phodal.pholedge.book.BookRepository.byId|

|2|com.phodal.pholedge.book.model.Book.toRepresentation|

|2|com.phodal.pholedge.book.BookRepository.save|

|2|com.phodal.coca.analysis.JavaCallApp.parse|

|2|com.phodal.pholedge.book.BookRepository.save|

|2|com.phodal.coca.analysis.JavaCallApp.parse|

|1|com.phodal.pholedge.book.model.Book.save|

最后,我们又回到了这个模型上。

高引用与高修改

考虑到 AST 的慢的程度,我已经有一个更好的实现方式。

结论

分析代码是一件很有意思的事情。一番操作下来,能学习到非常有意思的东西。

关键词:
相关文章

最近更新