尋找可以監視CSS質量和復雜性的堆棧

許多開發者撰寫關於如何維護CSS 代碼庫的文章，但很少有人寫到他們如何衡量代碼庫的質量。當然，我們有優秀的代碼檢查工具，如StyleLint 和CSSLint，但它們只能在微觀層面防止錯誤。使用錯誤的顏色表示法、在已經使用Autoprefixer 的情況下添加供應商前綴、以不一致的方式編寫選擇器……諸如此類。

我們一直在尋找改進CSS 編寫方式的方法：OOCSS、BEM、SMACSS、ITCSS、實用優先等等。但其他開發社區似乎已經從單純的代碼檢查工具發展到像SonarQube 和PHP Mess Detector 這樣的工具，而CSS 社區仍然缺乏比淺層lint 規則更深入的檢查工具。為此，我創建了Project Wallace，一套用於檢查和強制執行CSS 質量的工具。

Project Wallace 是什麼？

Project Wallace 的核心是一組工具，包括命令行界面、代碼檢查器、分析器和報告器。

以下是這些工具的簡要概述。

命令行界面

這允許您在命令行上運行CSS 分析，並獲取您提供給它的任何CSS 的統計信息。

Constyble 代碼檢查器

這是一個專門為CSS 設計的代碼檢查器。基於Wallace 生成的分析結果，您可以設置不應超過的閾值。例如，單個CSS 規則不應包含超過10 個選擇器，或者平均選擇器複雜度不應高於3。

分析器

Extract-CSS 正如其名：從網頁中提取所有CSS，以便我們可以將其發送到projectwallace.com 進行分析。

報告器

Extract CSS 的所有分析結果都發送到projectwallace.com，儀表板包含所有數據的報告。它類似於CSS Stats，但它跟踪更多指標，並隨時間推移存儲結果並在儀表板中顯示它們。它還顯示了兩個時間點之間的差異，以及許多其他功能。

分析CSS 複雜度

關於CSS 複雜度的文章不多，但Harry Roberts (csswizardry) 寫的那一篇讓我印象深刻。其要點是每個CSS 選擇器基本上是一堆if 語句，這讓我想起了上計算機科學課程時，我必須手動計算方法的循環複雜度。 Harry 的文章對我來說非常有意義，因為它可以編寫一個模塊來計算CSS 選擇器的複雜度——當然，不要與特異性混淆，因為在復雜度方面，這是一個完全不同的問題。

基本上，CSS 中的複雜性可以以多種形式出現，但以下是我在審核代碼庫時最關注的幾種：

CSS 選擇器的循環複雜度

選擇器的每個部分都意味著瀏覽器需要執行另一個if 語句。較長的選擇器比較短的選擇器更複雜。它們更難調試，瀏覽器解析速度更慢，也更難覆蓋。

 <code>.my-selector {} /* 1 个标识符*/ .my #super [complex^="selector"] > with ~ many :identifiers {} /* 6 个标识符*/</code>

每條規則集的聲明數（內聚性）

包含許多聲明的規則集比包含少量聲明的規則集更複雜。 Tailwind 和Tachyons 等函數式CSS 框架的流行，可能歸因於CSS 本身的相對“簡單性”。

 <code>/* 1 条规则，1 个声明=> 内聚性= 1 */ .text-center { text-align: center; } /* 1 条规则，8 个声明=> 内聚性= (1 / 8) = 0.125 */ .button { background-color: blue; color: white; padding: 1em; border: 1px solid; display: inline-block; font-size: normal; font-weight: bold; text-decoration: none; }</code>

源代碼行數

代碼越多，複雜度越高。每一行編寫的代碼都需要維護，因此包含在報告中。

每條規則的平均選擇器數

一條規則通常包含1 個選擇器，但有時會更多。這使得很難刪除CSS 的某些部分，從而使其更複雜。

所有這些指標都可以使用Constyble 進行代碼檢查，Constyble 是Project Wallace 在其工具集中使用的CSS 複雜度代碼檢查器。在為指標定義基線後，只需安裝Constyble 並設置配置文件即可。以下是我直接從Constyble 自述文件中提取的配置文件示例：

 <code>{ // 不要超过4095 个选择器，否则IE9 将删除任何后续规则"selectors.total": 4095, // 我们不需要ID 选择器"selectors.id.total": 0, // 如果出现除这些颜色之外的任何其他颜色，则报告错误！ "values.colors.unique": ["#fff", "#000"] }</code>

最棒的是，Constyble 在您的最終CSS 上運行，因此它只在您來自Sass、Less、PostCSS 或您使用的任何其他預處理器的所有預處理工作之後才執行其操作。這樣，我們可以對選擇器的總數或平均選擇器複雜度進行智能檢查——就像任何代碼檢查器一樣，您可以將其作為構建步驟的一部分，如果出現任何問題，您的構建將失敗。

使用Project Wallace 的收穫

在使用Project Wallace 一段時間後，我發現它非常適合跟踪複雜度。雖然它主要用於此目的，但它也是一種查找CSS 中代碼檢查器可能找不到的細微錯誤的好方法，因為它們正在檢查預處理的代碼。以下是我發現的一些有趣的事情：

• 我已經停止計算衝刺中需要修復網站上顏色不一致的用戶故事數量。已經有幾年的項目，以及人員進出公司：這是一個讓網站上每個品牌顏色都出錯的秘訣。幸運的是，我們實施了Constyble 和Project Wallace 以獲得利益相關者的認可，因為我們能夠證明客戶的品牌在新項目中非常準確。 Constyble 阻止我們添加不在樣式指南中的顏色。
• 我已經在我的前雇主工作的項目中安裝了Project Wallace webhooks。任何時候向項目添加新的CSS，它都會將CSS 發送到projectwallace.com，並且會在項目的儀表板中立即顯示。這使得很容易發現何時向CSS 添加了特定的選擇器或媒體查詢。
• 今年早些時候的CSS-Tricks 重設計意味著複雜性和文件大小的大幅下降。重設計非常棒，可以進行分析。它使您有機會仔細查看幕後情況，並弄清楚作者如何更改了他們的CSS。了解哪些部分不適用於站點以及哪些新部分適用，可能會讓您了解CSS 的發展速度。
• 一家位於荷蘭的大型國際公司曾經在一個CSS 文件中擁有超過4095 個選擇器。我知道他們正在積極發展新興市場，並且他們必須支持Internet Explorer 8 。 IE9 在4095 個選擇器後停止讀取所有CSS，因此他們的大部分CSS 並未在舊版IE 瀏覽器中應用。我給他們發了一封電子郵件，他們驗證了這個問題並立即通過將CSS 分成兩個文件來修復它。
• GitLab 目前使用超過70 種獨特的字體大小。我很確定他們的排版系統很複雜，但這似乎有點過於雄心勃勃。也許是因為一些第三方CSS，但這很難判斷。
• 在繼承其他開發人員的項目時，我會查看CSS 分析結果，以便了解項目的難點。他們是否大量使用了!important？平均規則集大小是否易於理解，或者他們是否在每個規則集中添加了20 多個聲明？平均選擇器長度是多少，它們是否難以覆蓋？不必訴諸.complex-selector-override\[class\][class][class]...[class] 將是很好的。
• 檢查縮小是否有效的巧妙技巧是讓Constyble 檢查代碼行數指標是否不大於1。 CSS 縮小意味著所有CSS 都放在一行上，因此代碼行數應等於1！
• 我的另一個項目中一直發生的事情是縮小失敗了。我不知道，直到Project Wallace 的差異顯示給我許多顏色突然像#aaaaaa 而不是#aaa 一樣被編寫出來。這本身並不是一件壞事，但它同時發生在如此多的顏色上，以至於肯定有什麼地方出了問題。快速調查顯示我在縮小中犯了一個錯誤。
• StackOverflow 有四種獨特的編寫白色顏色方式。這不一定是壞事，但這可能是CSS 縮小程序損壞或設計系統不一致的跡象。
• Facebook.com 在他們的CSS 中有超過650 種獨特的顏色。損壞的設計系統也開始聽起來像是一種可能性。
• 我前雇主的一個項目顯示input[type=checkbox]:checked .label input[type=radio] label:focus:after 是最複雜的選擇器。仔細檢查後，我們發現此選擇器定位嵌套在另一個輸入中的輸入。這在HTML 中是不可能的，我們認為我們一定忘記了CSS 中的逗號。沒有代碼檢查器警告我們這一點。
• CSS 預處理器中的嵌套很酷，但可能會導致錯誤的事情，例如@media (max-width: 670px) 和(max-width: 670px)，正如我在Syntax.fm 中發現的那樣。

對於Project Wallace 來說，這只是冰山一角。一旦您開始分析您的CSS，還有更多的東西需要學習和發現。不要只查看您自己的統計數據，還要查看其他人正在做什麼。

我已經將我的Constyble 配置用作與經驗較少的開發人員進行對話的談資，以解釋為什麼他們在復雜的CSS 塊上構建失敗。與其他開發人員討論為什麼我們要避免或推廣某些CSS 編寫方式有助於知識轉移。它也幫助我腳踏實地。不得不向只想幫忙的PHP 開發人員解釋我已經做了多年的事情，讓我重新思考為什麼我要按照自己的方式做事。

我的目標不是告訴任何人CSS 中什麼正確或什麼錯誤，而是創建工具，以便您可以驗證什麼對您和您的同事有效。 Project Wallace 在這裡幫助我們理解我們編寫的CSS。

以上是尋找可以監視CSS質量和復雜性的堆棧的詳細內容。更多資訊請關注PHP中文網其他相關文章！