自從我上次研究三個主要JSF組件庫的質(zhì)量以來，已經(jīng)有一段時間了。 2009年12月，我開始比較RichFaces，Primefaces和ICEfaces的整體軟件質(zhì)量 。 從那時起，事情發(fā)生了變化，從現(xiàn)在開始，我想重新評估和更新它。 我在2009年使用的工具仍然有效，但是工具套件的安裝有點棘手，我只是在浪費時間來做。 由于最近對FAMIX 2.1出口商的需求，我再次查看了inFusion 。 對于GlassFish City帖子（ 第一 ， 第二 ），它起到了作用 。 但是除此之外，還有更多。 它是幫助評估系統(tǒng)質(zhì)量的工具。 它專注于體系結(jié)構(gòu)和設(shè)計質(zhì)量，并允許數(shù)百萬個LOC系統(tǒng)的質(zhì)量保證。

在我向您介紹inFusion可以為您做些什么之前（隱式地通過分析候選者，我不做廣告：-D）我必須感謝Radu Marinescu博士和Adrian Trifu博士提供了完整的功能測試，以及他們的產(chǎn)品評估許可證給我。 沒有這個，我將無法像今天一樣向您展示偉大的軟件城市或有關(guān)開源項目質(zhì)量的博客！ 請查看這篇文章下面的資源，以獲取有關(guān)inFusion及其背后原理的更多鏈接。 如果您希望我完成產(chǎn)品發(fā)布，請在評論中告訴我！

本文重點
?
PrimeFaces ， RichFaces和ICEfaces是三個最常用的JSF組件庫。 看看使用它的社區(qū)，我總是感到有一種競爭是唯一的。 這絕對是由PrimeFaces領(lǐng)導(dǎo)推動的。 您可以考慮他在做什么，是否喜歡。 在這篇文章中，我不是要責(zé)怪任何人從事政治上的正確行為，而是要通過查看交付的質(zhì)量，將其帶回到不同項目的一些更客觀的觀點。

介紹
?
在獲得結(jié)果之前，我需要向您介紹一些基礎(chǔ)知識。 如果您覺得自己已經(jīng)看過足夠多的內(nèi)容，并且下面的所有內(nèi)容都很簡單，請隨時處理單個結(jié)果。 InFusion以圍繞但不以指標(biāo)為中心的方式評估軟件質(zhì)量。 因此，它引入了一種特殊的質(zhì)量模型（QM），該模型用一些可測量的特征來表達(dá)軟件系統(tǒng)的質(zhì)量。 質(zhì)量本身可能意味著幾項不同的事情（外部，過程，內(nèi)部質(zhì)量）。 inFusion將質(zhì)量的概念定義為“內(nèi)部質(zhì)量”，即系統(tǒng)的體系結(jié)構(gòu)和設(shè)計的質(zhì)量。 inFusion QM定義了兩個分解層：“質(zhì)量屬性”層和“設(shè)計屬性”層。 較高級別的概述包含一組五個“設(shè)計屬性”，它們是基于幾個眾所周知的“設(shè)計原理”（例如DRY原理和Demeter定律）構(gòu)建的。 牢記這些原則，inFusion衡量與大多數(shù)這些原則和設(shè)計規(guī)則的偏差。 通過考慮“難聞的氣味”，可以對這些偏差進行量化。 所有這一切與正確的映射（可以在inFusion本身或下面提到的出版物中查找）一起計算出“質(zhì)量赤字指數(shù)”（QDI）。 QDI是一個向上的正向上無界值，它是對分析的系統(tǒng)的設(shè)計質(zhì)量相對于系統(tǒng)總體大小的“不良”度量。

除了這些高級措施之外，inFusion還提供可視化效果，例如在不同級別（包，繼承，類和模塊）上的耦合，封裝和設(shè)計缺陷。
我也喜歡指標(biāo)金字塔。 它以某種方式回答“我的項目與其他項目相比如何？”的問題。它會生成一個金字塔，顯示您項目的關(guān)鍵指標(biāo)，并與這些數(shù)字的行業(yè)標(biāo)準(zhǔn)范圍進行比較。它分為三個不同的類別（繼承性，大小）和溝通）。

金字塔概述

數(shù)字表示比率。 顏色表示比率符合行業(yè)標(biāo)準(zhǔn)范圍的位置（來自眾多開源項目）。 每個比例
是綠色（接近平均范圍），藍(lán)色（接近低范圍）或紅色（接近高范圍）。 生成的數(shù)字有兩個目的。 首先，它們使您可以在多個維度上將代碼庫與其他代碼庫進行比較。 其次，這些數(shù)字表示您可能要花費很多精力來改善代碼衛(wèi)生和設(shè)計的地方。 但是，您必須根據(jù)上下文理解這些數(shù)字。

PrimeFaces（QDI：30,8）

PrimeFaces上的設(shè)計缺陷

成立于2009年，擁有不斷增長的用戶基礎(chǔ)。 發(fā)展負(fù)責(zé)人是?a？atay?ivici 。 以下分析是在最新的開發(fā)主干上進行的。

系統(tǒng)中的代碼行總數(shù)為44.123（包括注釋和空格）。 涂裝質(zhì)量缺陷指數(shù)為30,8。
InFusion檢測到12個不同的設(shè)計缺陷。 影響最大的是24個數(shù)據(jù)類和23個拒絕父母遺贈類。 其次是三個神級。 有很多重復(fù)缺陷，但沒有圈依賴。

類層次結(jié)構(gòu)往往又高又寬 （即繼承樹傾向于具有許多深度級別和基類，以及許多直接派生的子類）

類傾向于包含平均數(shù)量的方法。 以相當(dāng)細(xì)粒度的程序包進行組織（即每個程序包幾個類）

方法往往很長 ， 邏輯平均復(fù)雜度 ; 從其他類別 （低耦合色散）中調(diào)用許多方法 （高耦合強度）；

PrimeFaces的度量標(biāo)準(zhǔn)金字塔

鑒于事實是，這是一個組件庫，因此可以接受NDD（直接后代的數(shù)量）和HIT（繼承樹的高度）。 復(fù)雜的繼承使理解和預(yù)測行為更加復(fù)雜。 更深的樹構(gòu)成更大的設(shè)計復(fù)雜性，因為涉及更多的方法和類，但會增強繼承方法的潛在重用。 NOM是指方法的數(shù)量。 這是一個簡單的度量標(biāo)準(zhǔn)，它根據(jù)責(zé)任而不是方法的規(guī)模來顯示類的復(fù)雜性。

RichFaces（QDI：9.1）

RichFaces上的設(shè)計缺陷

??
RichFaces于2005年底起源于Ajax4jsf。它是JBoss上廣泛使用的組件庫。
分析使用的是最新的開發(fā)路線，僅包括核心和組成部分。

系統(tǒng)中的代碼行總數(shù)為134.037（包括注釋和空格）。

RichFaces的質(zhì)量赤字指數(shù)為9.1。

類層次結(jié)構(gòu)往往較高且具有平均寬度 （即，繼承樹傾向于具有許多深度級別和基類以及幾個直接派生的子類）

類傾向于包含平均數(shù)量的方法。 并且以相當(dāng)細(xì)粒度的程序包進行組織（即每個程序包很少的類）；

方法往往：是平均長度和平均邏輯的復(fù)雜性 ; 從其他類別 （低耦合色散）中調(diào)用許多方法 （高耦合強度）；

RichFaces的度量標(biāo)準(zhǔn)金字塔

通常，RichFaces在層次結(jié)構(gòu)方面做得更好。 僅繼承樹的高度接近高范圍。 通訊類的NOM也接近較高水平。 其余的都在定義的范圍內(nèi)，這實際上導(dǎo)致了良好的QDI。

ICEfaces（QDI：16.6）

ICEfaces上的設(shè)計缺陷

自…以來就有ICEfaces，并且針對3.1.0標(biāo)簽進行了分析，其中包括核心，推入和組件。
系統(tǒng)中的代碼行總數(shù)為153.843（包括注釋和空格）。

ICEfaces的質(zhì)量赤字指數(shù)為16.6。
InFusion檢測到16種不同的設(shè)計缺陷，包括35個數(shù)據(jù)類，13個上帝類，20個SAP Breakers，其次是21個拒絕父母遺贈類和35個循環(huán)依賴項，我們在其中也有很多重復(fù)項。

類層次結(jié)構(gòu)往往很高且具有平均寬度，即繼承樹傾向于具有許多深度級別和基類，以及幾個直接派生的子類）

類傾向于包含平均數(shù)量的方法。 以相當(dāng)細(xì)粒度的程序包進行組織（即每個程序包幾個類）。

方法往往很長 ， 邏輯平均復(fù)雜度 ; 從其他幾個類別 （低耦合色散）中調(diào)用許多方法 （高耦合強度）。

ICEfaces的度量標(biāo)準(zhǔn)金字塔

不出所料，我們還發(fā)現(xiàn)了接近高的繼承樹高度。 除此之外，只需要擔(dān)心方法的數(shù)量。

解釋
?
這種分析與我?guī)啄昵八龅姆治霾煌?我跳過了所有顯而易見的內(nèi)容（例如，checkstyle，findbugs），因為每個人都在這里使用不同的方法，對我而言，這通常不是系統(tǒng)質(zhì)量的可比基礎(chǔ)。

在我們得出結(jié)論之前，讓我首先表達(dá)一下，該結(jié)果并不表示您應(yīng)該使用或不使用任何候選人。

系統(tǒng)設(shè)計質(zhì)量不會影響使用它們生成的代碼的質(zhì)量。 同樣，它也不應(yīng)該成為候選人是否穩(wěn)定或沒有漏洞的任何指標(biāo)。 它僅關(guān)注開發(fā)產(chǎn)品的開發(fā)人員可能面臨的問題。 從長遠(yuǎn)來看，這也可能會對您作為用戶產(chǎn)生影響。 由于設(shè)計問題昂貴，頻繁且不可避免。 因此，在代碼庫中存在許多質(zhì)量缺陷可能會影響團隊隨時間推移能夠提供的新功能的數(shù)量，或者修復(fù)錯誤的時間會大大增加。 最后，與一個小團隊一起，這可能會導(dǎo)致產(chǎn)品結(jié)束。

就繼承而言，所有三個候選人都面臨相同的問題。 這樣做的原因是，它們都是為客戶提供良好功能的框架。 結(jié)合候選對象的大小，PrimeFaces在進行分析時似乎存在最大的設(shè)計缺陷。 在質(zhì)量方面，RichFaces領(lǐng)先于其他兩個。 這是我期望從RedHat社區(qū)驅(qū)動的項目中看到的。 另一個指標(biāo)是，工作中的軟件社區(qū)至關(guān)重要，技能高超！ ICEfaces是唯一具有循環(huán)依賴項和大量重復(fù)代碼的項目。 因此，他們可能最終不得不修復(fù)相同的錯誤幾次。

我在這里沒有任何要付出的代價，但是想向RichFaces團隊致以祝賀，感謝他們提供高質(zhì)量的產(chǎn)品！ 保持良好的工作！

這是您的RichFaces-City（核心和組件）。 綠色區(qū)域是舊的org.ajax4jsf。*平房:)

富人城

資源：
灌輸產(chǎn)品頁面
實踐中的面向?qū)ο笾笜?biāo) （Springer，2006年） iPlasma：面向?qū)ο笤O(shè)計質(zhì)量評估的集成平臺 （PDF） 實用設(shè)計質(zhì)量評估 （幻燈片分享演示）

參考： JSF組件庫–質(zhì)量不只是零缺陷。 來自我們的JCG合作伙伴 Markus Eisele在Java的企業(yè)軟件開發(fā)博客中。

翻譯自: https://www.javacodegeeks.com/2012/08/jsf-component-libraries-quality-is-more.html

總結(jié)

以上是生活随笔為你收集整理的JSF组件库–质量不只是零缺陷的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。