代码质量检测结果可视化页面_用PhpMetrics可视化代码质量-CSDN博客

代码质量检测结果可视化页面

We had been looking into code quality checking tools for a while here on SitePoint – most recently in a series on Jenkins, but none of those could do what a project I’ve only recently found out about can.

我们在SitePoint上已经有一段时间研究代码质量检查工具了-最近是在有关Jenkins的系列文章中，但是这些工具都无法完成我最近才发现的项目。

PhpMetrics uses D3 and some sophisticated analysis algorithms to scan your application’s code and output intricate reports about it.

PhpMetrics使用D3和一些复杂的分析算法来扫描应用程序的代码并输出有关它的复杂报告。

安装和使用PhpMetrics (Installing and Using PhpMetrics)

It’s a bit hard to talk about it without seeing a proper example, so let’s install and run it, then explain every part.

如果不看适当的例子就很难谈论它，因此让我们安装并运行它，然后解释每个部分。

环境 (Environment)

To test it, we’ll need an isolated environment. As usual, we’ll be using our trusty Homestead Improved Vagrant box, making sure all readers have the same environment to test on.

要测试它，我们需要一个隔离的环境。像往常一样，我们将使用值得信赖的Homestead改进的 Vagrant框，确保所有读者都具有相同的测试环境。

安装PhpMetrics (Installing PhpMetrics)

Like with any modern PHP project, installing is very simple. We’ll install it globally, making it available to all projects on the machine.

像任何现代PHP项目一样，安装非常简单。我们将在全球范围内安装它，使其可用于计算机上的所有项目。

sudo composer global require 'halleck45/phpmetrics'

获取代码 (Fetching the Code)

We’ll test PhpMetrics on two code-heavy projects: Laravel and Symfony, in framework, not project form. That means we won’t be using the create-project command from Composer, but the bare source of each framework.

我们将在框架而不是项目形式的两个代码繁重的项目(Laravel和Symfony)上测试PhpMetrics。这意味着我们将不会使用Composer的create-project命令，而是使用每个框架的原始资源。

git clone https://github.com/symfony/symfony symframe
git clone https://github.com/laravel/framework lframe

We do this to avoid any and all dependency testing, and to stay away from non-framework related code.

我们这样做是为了避免所有依赖测试，并避免与非框架相关的代码。

在代码繁重的项目上使用PhpMetrics (Using PhpMetrics on a Code-Heavy Project)

Now that we’ve got the projects downloaded, let’s run PhpMetrics on them.

现在我们已经下载了项目，让我们在它们上运行PhpMetrics。

mkdir Laravel
mkdir Laravel/public
phpmetrics --report-html=/Laravel/public/report_symfony.html symframe
phpmetrics --report-html=/Laravel/public/report_laravel.html lframe

Never mind the fact that we’re using “Laravel” folders here for the reports, they’re just Homestead’s defaults and we can just reuse them for our small example to reduce the configuration steps. This lets us easily access the reports at the following URLs:

不用管我们在这里使用“ Laravel”文件夹作为报告的事实，它们只是Homestead的默认值，我们可以在我们的小示例中重复使用它们以减少配置步骤。这使我们可以轻松地通过以下URL访问报告：

homestead.app:8000/report_symfony.html
homestead.app:8000/report_laravel.html

Here’s what Laravel’s report gets us:

这是Laravel的报告为我们提供的：

and here’s what we get by analyzing Symfony:

这是我们通过分析Symfony得到的：

分析 (Analysis)

PhpMetrics offers a plethora of metrics. Let’s demystify those circles and graphs and find out what we’re looking at!

PhpMetrics提供了大量的指标。让我们揭开那些圆和图的神秘面纱，找出我们在看什么！

颜色编码 (Color coding)

As per the how to read the report guide, we can immediately notice Symfony is a bit heavy on the orange-red side, while the grass is greener on Laravel’s side. One important thing to notice, however, is how many more files Symfony contains as opposed to Laravel – you can see this clearly by comparing the density of circles.

根据如何阅读报告指南，我们可以立即注意到Symfony在橘红色的一侧有点沉重，而草在Laravel的一侧更绿。但是，需要注意的重要一件事是，与Laravel相比，Symfony包含了多少文件–您可以通过比较圆的密度来清楚地看到这一点。

PhpMetrics was built with color blind people in mind, so the “color blind” checkbox changes the colors in the circles from green, yellow, orange to stripes at different angles:

PhpMetrics是在考虑色盲人群的情况下构建的，因此“色盲”复选框会将圈子中的颜色从绿色，黄色，橙色更改为不同角度的条纹：

The color coding is the first aspect you can look at, and the first place to look for hints at problems.

颜色编码是您可以查看的第一个方面，也是寻找问题提示的第一位。

圈复杂度和可维护性指数 (Cyclomatic Complexity and Maintainability Index)

The circles, when looked at carefully, represent the CC and MI, and, as the documentations says, large red circles will probably be very hard to maintain.

如果仔细观察，这些圆圈代表CC和MI，并且如文档所述，大的红色圆圈可能很难维护。

Both are easily Googleable, but let me spare you the wiki skimming and explain them in layman terms.

两者都可以轻松地通过Google进行搜索，但是让我为您省去了Wiki浏览的麻烦，并以通俗易懂的方式对其进行了说明。

Cyclomatic Complexity essentially measures the number of paths to take through a script’s logic. The more paths can be taken, the more complex a file is. A good way to avoid high CC is to make sure your code is as modular and atomic as possible, which becomes second nature when you’re following SOLID principles.

圈复杂度本质上衡量了脚本逻辑所采用的路径数量。可以采用的路径越多，文件越复杂。避免高CC的一个好方法是确保您的代码尽可能模块化和原子化，这在您遵循SOLID原理时成为第二性。

Like Wikipedia says, the Maintainability Index is calculated with certain formulae from lines-of-code measures, McCabe measures and Halstead complexity measures. Lines-of-code measures are self-explanatory – literally counting the number of lines of code. McCabe measures, much as it sounds like a USA political promise, is actually just another name for Cyclomatic Complexity. Halstead complexity is a set of formulae which try to look at the syntax of the file’s code and deduce attributes such as difficulty, code vocabulary, effort, etc. If you’re interested in the specific formulae, check the Wikipedia article out.

就像Wikipedia所说的那样，可维护性指数是根据代码行测度， McCabe测度和Halstead复杂度测度的某些公式计算得出的。代码行量度是不言自明的-字面上计算代码行数。听起来像是美国的政治承诺，麦凯布的措施实际上只是“圈复杂性”的另一个名称。 Halstead复杂性是一组公式，这些公式试图查看文件代码的语法并推论出诸如难度，代码词汇量，工作量等属性。如果您对特定的公式感兴趣，请查阅Wikipedia文章。

Taking all these into effect, the circles are sized and color coded, indicating the sum of all standard metrics for code complexity and maintainability.

考虑到所有这些因素后，将对圆圈进行大小调整和颜色编码，以指示所有标准度量标准的总和，以体现代码的复杂性和可维护性。

桌子 (Tables)

If you’d like to see all the data in a more tabular form, you can check the “Explore” tab in the report file:

如果您想以表格形式查看所有数据，可以检查报告文件中的“浏览”标签：

This table will include all the above and more – from lines of code to number of classes and more – both per folder and file. This incredibly detailed report is what you should refer to when looking for highly precise information about your code all in one place.

该表将包括上述所有内容以及更多内容-从代码行到类数，以及更多-每个文件夹和文件。当在一个地方查找有关代码的高度精确的信息时，应该参考这份难以置信的详细报告。

自定义图表 (Custom Chart)

The middle area in the report’s overview screen contains the custom chart.

报告概述屏幕的中间区域包含自定义图表。

In the example above, we’re comparing the ratio of CC (mentioned above) and Lcom (lack of cohesion in methods) for each file, but you just as easily switch out the X or Y axis value for something else. For example, here’s a comparison of Difficulty per Lines of Code – you can notice that Laravel’s trend is somewhat proportional – with more LoC, more Difficulty is assumed, while Symfony tends to be all over the place with certain files.

在上面的示例中，我们正在比较每个文件的CC(如上所述)和Lcom( 方法中缺乏内聚性 )的比率，但是您可以轻松地将X或Y轴值切换为其他文件。例如，下面是每行代码难度的比较-您会注意到Laravel的趋势是成比例的–随着LoC的增加，假设难度更大，而Symfony往往遍布某些文件。

For example, the Symfony file BinaryNode.php has a very high difficulty for its 150 lines of code, while Response.php in its whopping 1275 lines of code has a very low difficulty score. Explore the files that produce curious results, and see what you can find out from these insights.

例如，Symfony文件BinaryNode.php的150行代码的难度很高，而Response.php高达1275行的代码的难度得分却非常低。浏览产生奇怪结果的文件，并查看从这些见解中可以找到的内容。

抽象性/不稳定性 (Abstractness / Instability)

This chart is very well explained here, but in a nutshell, the average diagonal line is called the balance line, or, the Main Sequence. The goal is to have your classes as close to the line as possible, because this means they’re balanced between being abstract and concrete enough. I do encourage you to read the content at the link above – it’s an easy read and should clear things up.

这个图表是很好的解释在这里，但简而言之，平均对角线被称为平衡线，或主序。目的是使您的类尽可能接近行，因为这意味着它们在足够抽象和具体之间保持平衡。我鼓励您阅读上面的链接中的内容-内容易于阅读，应该清除。

For some reason, I couldn’t get A/I to work on my local environment properly with Laravel and Symfony.

由于某些原因，我无法让Laravel和Symfony在我的本地环境中正常工作。

评价 (Evaluation)

Evaluation is a web chart which takes the average of various attributes of your entire project, compares these numbers to the standard of other projects the tool has learned so far, and then superimposes your values over those. This is purely cosmetic and carries no real value, as the disclaimer on the Evaluation page says.

评估是一个网络图表，该图表将整个项目的各种属性取平均值，然后将这些数字与该工具迄今已学习的其他项目的标准进行比较，然后将您的价值叠加到这些价值上。如“评估”页面上的免责声明所述，这纯粹是化妆品，没有任何实际价值。

While the tool believes both frameworks are equally maintainable, its not such a shocking conclusion here that Laravel is more new-developers friendly and far more simplistic in algorithms, not to mention less voluminous.

尽管该工具认为这两个框架都可以保持相同的可维护性，但在这里得出的结论并不令人震惊，即Laravel对新开发人员更友好，算法也更简单，更不用说体积庞大了。

关系图 (Relations Map)

The relations map is more useful for smaller projects – it lets you see the relations between classes. If a class extends or implements another, the relations map will show it. Due to the brutal number of classes in both of these projects and their connections, the map is less than useful here – in fact, it doesn’t even load for Symfony for me. But if you go ahead and try it out on a test project with a smaller number of classes, you’re bound to see the benefits.

关系图对较小的项目更有用–它使您可以查看类之间的关系。如果一个类扩展或实现了另一个，则关系图将显示它。由于这两个项目及其连接中的类都很残酷，因此该地图在这里用处不大–实际上，它对我来说甚至都不给Symfony加载。但是，如果您继续尝试在具有较少类的测试项目中进行尝试，那么您一定会看到好处。

分区 (Repartition)

Finally, the repartition screen sums up all the data in a format much simpler than the Explore tab, listing out some totals only:

最后，重新分区屏幕以比“浏览”选项卡简单得多的格式汇总所有数据，仅列出一些总计：

Symfony:

Symfony：

Laravel:

Laravel：

比较结果 (Comparison Results)

So, what’s to be concluded from these results? Without looking into it too much, we can easily conclude that:

那么，从这些结果中可以得出什么结论呢？无需过多研究，我们可以轻松得出以下结论：

Laravel is more friendly to new developers, simpler in algorithms and less bloated in file size.
Laravel对新开发人员更友好，算法更简单，文件大小也不那么肿。
Laravel is drastically more lightweight. Symfony has at least three times more anything than Laravel – methods, classes, files, lines of code… it’s three times more massive.
Laravel非常轻巧。 Symfony的至少三倍以上Laravel 什么 -方法，类，文件，代码行......这是三次更加庞大。
Symfony is more relatively complex (middle column on the Repartition screen)
Symfony 比较复杂(“分区”屏幕上的中间列)
Laravel is much more stable in complexity across files – they have the same ratio of difficulty and lines of code, while Symfony can vary wildly.
Laravel在文件间的复杂性方面要稳定得多-它们具有相同的难度比和代码行比率，而Symfony可以相差很大。
Symfony could use some work in making some of the more complex files more atomic – the big red circles are taking over its circle graph.
Symfony可以使用一些工作来使一些更复杂的文件更具原子性-大红色圆圈正在取代其圆圈图。

See what else you can learn by playing with the charts and data yourself, then let us know!

自己玩图表和数据，看看还能学到什么，然后告诉我们！

结论 (Conclusion)

PhpMetrics is another in a long line of code quality analyzers, but one with a twist. Rather than looking at the typical code standard issues we’ve come to expect, it looks at a whole set of new attributes and explains your code to you in beautiful math, as soon as you learn its language. To find out what each attribute means, consult the chart.

PhpMetrics是一长串的代码质量分析器中的另一种，但是却有所不同。在学习语言之后，它不会查看我们期望的典型代码标准问题，而是查看一整套新属性，并以漂亮的数学向您解释代码。要找出每个属性的含义，请参考图表。

Will you be using PhpMetrics to scan your projects? Would you install it into your IDE? Is it something you might see as a permanent addition to your CI process? Let us know your thoughts in the comments!

您将使用PhpMetrics扫描您的项目吗？您可以将其安装到IDE中吗？您可能会认为这是对CI流程的永久补充吗？在评论中让我们知道您的想法！