自从我上次研究三个主要JSF组件库的质量以来，已经有一段时间了。 2009年12月，我开始比较RichFaces，Primefaces和ICEfaces的整体软件质量 。 从那时起，事情发生了变化，从现在开始，我想重新评估和更新它。 我在2009年使用的工具仍然有效，但是工具套件的安装有点棘手，我只是在浪费时间来做。 由于最近对FAMIX 2.1出口商的需求，我再次查看了inFusion 。 对于GlassFish City帖子（ 第一 ， 第二 ），它起到了作用 。 但是除此之外，还有更多。 它是帮助评估系统质量的工具。 它专注于体系结构和设计质量，并允许数百万个LOC系统的质量保证。

在我向您介绍inFusion可以为您做些什么之前（隐式地通过分析候选者，我不做广告：-D）我必须感谢Radu Marinescu博士和Adrian Trifu博士提供了完整的功能测试，以及他们的产品评估许可证给我。 没有这个，我将无法像今天一样向您展示伟大的软件城市或有关开源项目质量的博客！ 请查看这篇文章下面的资源，以获取有关inFusion及其背后原理的更多链接。 如果您希望我完成产品发布，请在评论中告诉我！

本文重点
 
PrimeFaces ， RichFaces和ICEfaces是三个最常用的JSF组件库。 看看使用它的社区，我总是感到有一种竞争是唯一的。 这绝对是由PrimeFaces领导推动的。 您可以考虑他在做什么，是否喜欢。 在这篇文章中，我不是要责怪任何人从事政治上的正确行为，而是要通过查看交付的质量，将其带回到不同项目的一些更客观的观点。

介绍
 
在获得结果之前，我需要向您介绍一些基础知识。 如果您觉得自己已经看过足够多的内容，并且下面的所有内容都很简单，请随时处理单个结果。 InFusion以围绕但不以指标为中心的方式评估软件质量。 因此，它引入了一种特殊的质量模型（QM），该模型用一些可测量的特征来表达软件系统的质量。 质量本身可能意味着几项不同的事情（外部，过程，内部质量）。 inFusion将质量的概念定义为“内部质量”，即系统的体系结构和设计的质量。 inFusion QM定义了两个分解层：“质量属性”层和“设计属性”层。 较高级别的概述包含一组五个“设计属性”，它们是基于几个众所周知的“设计原理”（例如DRY原理和Demeter定律）构建的。 牢记这些原则，inFusion衡量与大多数这些原则和设计规则的偏差。 通过考虑“难闻的气味”，可以对这些偏差进行量化。 所有这一切与正确的映射（可以在inFusion本身或下面提到的出版物中查找）一起计算出“质量赤字指数”（QDI）。 QDI是一个向上的正向上无界值，它是对分析的系统的设计质量相对于系统总体大小的“不良”度量。

除了这些高级措施之外，inFusion还提供可视化效果，例如在不同级别（包，继承，类和模块）上的耦合，封装和设计缺陷。
我也喜欢指标金字塔。 它以某种方式回答“我的项目与其他项目相比如何？”的问题。它会生成一个金字塔，显示您项目的关键指标，并与这些数字的行业标准范围进行比较。它分为三个不同的类别（继承性，大小）和沟通）。

金字塔概述

数字表示比率。 颜色表示比率符合行业标准范围的位置（来自众多开源项目）。 每个比例
是绿色（接近平均范围），蓝色（接近低范围）或红色（接近高范围）。 生成的数字有两个目的。 首先，它们使您可以在多个维度上将代码库与其他代码库进行比较。 其次，这些数字表示您可能要花费很多精力来改善代码卫生和设计的地方。 但是，您必须根据上下文理解这些数字。

PrimeFaces（QDI：30,8）

PrimeFaces上的设计缺陷

成立于2009年，拥有不断增长的用户基础。 发展负责人是Ça？atayÇivici 。 以下分析是在最新的开发主干上进行的。

系统中的代码行总数为44.123（包括注释和空格）。 涂装质量缺陷指数为30,8。
InFusion检测到12个不同的设计缺陷。 影响最大的是24个数据类和23个拒绝父母遗赠类。 其次是三个神级。 有很多重复缺陷，但没有圈依赖。

类层次结构往往又高又宽 （即继承树倾向于具有许多深度级别和基类，以及许多直接派生的子类）

类倾向于包含平均数量的方法。 以相当细粒度的程序包进行组织（即每个程序包几个类）

方法往往很长 ， 逻辑平均复杂度 ; 从其他类别 （低耦合色散）中调用许多方法 （高耦合强度）；

PrimeFaces的度量标准金字塔

鉴于事实是，这是一个组件库，因此可以接受NDD（直接后代的数量）和HIT（继承树的高度）。 复杂的继承使理解和预测行为更加复杂。 更深的树构成更大的设计复杂性，因为涉及更多的方法和类，但会增强继承方法的潜在重用。 NOM是指方法的数量。 这是一个简单的度量标准，它根据责任而不是方法的规模来显示类的复杂性。

RichFaces（QDI：9.1）

RichFaces上的设计缺陷

  
RichFaces于2005年底起源于Ajax4jsf。它是JBoss上广泛使用的组件库。
分析使用的是最新的开发路线，仅包括核心和组成部分。

系统中的代码行总数为134.037（包括注释和空格）。

RichFaces的质量赤字指数为9.1。

类层次结构往往较高且具有平均宽度 （即，继承树倾向于具有许多深度级别和基类以及几个直接派生的子类）

类倾向于包含平均数量的方法。 并且以相当细粒度的程序包进行组织（即每个程序包很少的类）；

方法往往：是平均长度和平均逻辑的复杂性 ; 从其他类别 （低耦合色散）中调用许多方法 （高耦合强度）；

RichFaces的度量标准金字塔

通常，RichFaces在层次结构方面做得更好。 仅继承树的高度接近高范围。 通讯类的NOM也接近较高水平。 其余的都在定义的范围内，这实际上导致了良好的QDI。

ICEfaces（QDI：16.6）

ICEfaces上的设计缺陷

自…以来就有ICEfaces，并且针对3.1.0标签进行了分析，其中包括核心，推入和组件。
系统中的代码行总数为153.843（包括注释和空格）。

ICEfaces的质量赤字指数为16.6。
InFusion检测到16种不同的设计缺陷，包括35个数据类，13个上帝类，20个SAP Breakers，其次是21个拒绝父母遗赠类和35个循环依赖项，我们在其中也有很多重复项。

类层次结构往往很高且具有平均宽度，即继承树倾向于具有许多深度级别和基类，以及几个直接派生的子类）

类倾向于包含平均数量的方法。 以相当细粒度的程序包进行组织（即每个程序包几个类）。

方法往往很长 ， 逻辑平均复杂度 ; 从其他几个类别 （低耦合色散）中调用许多方法 （高耦合强度）。

ICEfaces的度量标准金字塔

不出所料，我们还发现了接近高的继承树高度。 除此之外，只需要担心方法的数量。

解释
 
这种分析与我几年前所做的分析不同。 我跳过了所有显而易见的内容（例如，checkstyle，findbugs），因为每个人都在这里使用不同的方法，对我而言，这通常不是系统质量的可比基础。

在我们得出结论之前，让我首先表达一下，该结果并不表示您应该使用或不使用任何候选人。

系统设计质量不会影响使用它们生成的代码的质量。 同样，它也不应该成为候选人是否稳定或没有漏洞的任何指标。 它仅关注开发产品的开发人员可能面临的问题。 从长远来看，这也可能会对您作为用户产生影响。 由于设计问题昂贵，频繁且不可避免。 因此，在代码库中存在许多质量缺陷可能会影响团队随时间推移能够提供的新功能的数量，或者修复错误的时间会大大增加。 最后，与一个小团队一起，这可能会导致产品结束。

就继承而言，所有三个候选人都面临相同的问题。 这样做的原因是，它们都是为客户提供良好功能的框架。 结合候选对象的大小，PrimeFaces在进行分析时似乎存在最大的设计缺陷。 在质量方面，RichFaces领先于其他两个。 这是我期望从RedHat社区驱动的项目中看到的。 另一个指标是，工作中的软件社区至关重要，技能高超！ ICEfaces是唯一具有循环依赖项和大量重复代码的项目。 因此，他们可能最终不得不修复相同的错误几次。

我在这里没有任何要付出的代价，但是想向RichFaces团队致以祝贺，感谢他们提供高质量的产品！ 保持良好的工作！

这是您的RichFaces-City（核心和组件）。 绿色区域是旧的org.ajax4jsf。*平房:)

富人城

资源：
灌输产品页面
实践中的面向对象指标 （Springer，2006年） iPlasma：面向对象设计质量评估的集成平台 （PDF） 实用设计质量评估 （幻灯片分享演示）

参考： JSF组件库–质量不只是零缺陷。 来自我们的JCG合作伙伴 Markus Eisele在Java的企业软件开发博客中。