多くの開発者は、CSSコードベースを維持する方法について書いていますが、コードベースの品質(zhì)を測定する方法について書く人はほとんどいません。もちろん、StylelintやCSSLINTなどの優(yōu)れたコードチェックツールがありますが、マイクロレベルでのエラーのみを防ぐことができます。間違ったカラー表記を使用し、Autoprefixerが既に使用されているときにベンダープレフィックスを追加し、一貫性のない方法でセレクターを書き込みます...など。

私たちは常に、CSSの書き込み方法を改善する方法を探しています：OOCSS、BEM、SMACSS、ITCSS、実用的な最初、その他。しかし、他の開発コミュニティは、単純なコードチェックツールからSonarqubeやPHP Mess Detectorなどのツールに進(jìn)化したようですが、CSSコミュニティには淺いLintルールよりも詳細(xì)なチェックツールがまだありません。これを行うために、CSSの品質(zhì)をチェックして実施するためのツールのセットであるProject Wallaceを作成しました。

プロジェクトウォレスとは何ですか？

Projectの中心にあるWallaceは、コマンドラインインターフェイス、コードインスペクター、アナライザー、レポーターなどのツールのセットです。

これらのツールの簡単な概要を次に示します。

コマンドラインインターフェイス

これにより、コマンドラインでCSS分析を?qū)g行し、提供するCSSの統(tǒng)計(jì)を取得できます。

Constyble Code Checker

これは、CSS専用に設(shè)計(jì)されたコードチェッカーです。ウォレスによって生成された分析結(jié)果に基づいて、超えてはならないしきい値を設(shè)定できます。たとえば、単一のCSSルールには10を超えるセレクターを含めるべきではないか、平均セレクターの複雑さが3を超えてはなりません。

アナライザ

その名前が示すように抽出CSS：WebページからすべてのCSSを抽出して、分析のためにProjectWallace.comに送信できるようにします。

レポーター

抽出CSSのすべての分析結(jié)果はProjectWallace.comに送信され、ダッシュボードにはすべてのデータのレポートが含まれています。 CSSの統(tǒng)計(jì)に似ていますが、より多くのメトリックを追跡し、時(shí)間の経過とともにストアの結(jié)果を追跡し、ダッシュボードに表示します。また、2つの時(shí)點(diǎn)と他の多くの機(jī)能の違いも示しています。

CSSの複雑さを分析します

CSSの複雑さに関する記事はあまりありませんが、ハリー?ロバーツ（CSSwizardry）が書いた1つは感銘を受けました。ポイントは、各CSSセレクターが基本的にIFステートメントの束であるということです。これは、コンピューターサイエンスコースを受講するときに手動で計(jì)算しなければならなかった方法のループの複雑さを思い出させます。ハリーの記事は、CSSセレクターの複雑さを計(jì)算するモジュールを書くことができるため、私にとって非常に理にかなっています - もちろん、それは複雑さの観點(diǎn)からはまったく異なる質(zhì)問であるため、特異性と混同しないことです。

基本的に、CSSの複雑さは多くの形で來ることがありますが、コードベースをレビューするときに私が最も注意を払うことのいくつかを以下に示します。

CSSセレクターループの複雑さ

セレクターの各部分は、ブラウザが別のIFステートメントを?qū)g行する必要があることを意味します。より長いセレクターは、より短いセレクターよりも複雑です。デバッグは困難であり、ブラウザの解析はより遅く、カバーするのが難しいです。

 <code>.my-selector {} /* 1 個(gè)標(biāo)識符*/ .my #super [complex^="selector"] > with ~ many :identifiers {} /* 6 個(gè)標(biāo)識符*/</code>

ルールセットあたりの宣言の數(shù)（結(jié)束）

多くの宣言を含むルールセットは、少數(shù)の宣言を含むルールセットよりも複雑です。 TailwindやTachyonsなどの機(jī)能的なCSSフレームワークの人気は、CSS自體の相対的な「シンプルさ」に起因する可能性があります。

 <code>/* 1 條規(guī)則，1 個(gè)聲明=> 內(nèi)聚性= 1 */ .text-center { text-align: center; } /* 1 條規(guī)則，8 個(gè)聲明=> 內(nèi)聚性= (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>

ソースコード行の數(shù)

コードが多いほど、複雑さが増えます。コードの各行は維持されるため、レポートに含まれています。

ルールごとの選択者の平均數(shù)

通常、ルールには1つのセレクターが含まれますが、時(shí)にはそれ以上が含まれます。これにより、CSSの一部を削除することが困難になり、より複雑になります。

これらのメトリックはすべて、Project Wallaceがツールセットで使用するCSS複雑さコードチェッカーであるConstybleを使用してコードチェックできます。メトリックのベースラインを定義した後、Constybleをインストールして構(gòu)成ファイルを設(shè)定するだけです。 Constyble ReadMeから直接抽出した構(gòu)成ファイルの例を次に示します。

 <code>{ // 不要超過4095 個(gè)選擇器，否則IE9 將刪除任何后續(xù)規(guī)則"selectors.total": 4095, // 我們不需要ID 選擇器"selectors.id.total": 0, // 如果出現(xiàn)除這些顏色之外的任何其他顏色，則報(bào)告錯(cuò)誤！ "values.colors.unique": ["#fff", "#000"] }</code>

最良の部分は、Constybleが最終的なCSSで実行されることです。そのため、SASS、Less、PostCSS、または使用するその他のプリプロセッサからのすべての前処理作業(yè)の後にのみ操作を?qū)g行します。これにより、セレクターの総數(shù)または平均セレクターの複雑さをスマートチェックすることができます。どのコードインスペクターと同様に、ビルドステップの一部として使用でき、問題が発生した場合、ビルドは失敗します。

Project Wallaceを使用することの収穫

Project Wallaceをしばらく使用した後、複雑さを追跡するのに最適であることがわかりました。主にこの目的に使用されていますが、CSSの検査官が検査されないコードをチェックしているため、CSSのコード検査官が見つからない可能性のある微妙なエラーを見つける良い方法でもあります。ここに私が見つけたいくつかの興味深いことがあります：

• スプリント中にサイトの一貫性のない色を修正する必要があるユーザーストーリーの數(shù)を數(shù)えるのを停止しました。數(shù)年前からプロジェクトがあり、人々は會社に出入りしています。これは、ウェブサイト上のすべてのブランド色を間違えたことの秘密です。幸いなことに、私たちは、クライアントのブランドが新しいプロジェクトで非常に正確であることを証明することができたため、ConstybleとProject Wallaceを?qū)g裝して利害関係者の認(rèn)識を得ました。 Constybleは、スタイルガイドにない色を追加することを防ぎます。
• 私は、以前の雇用主が働いているプロジェクトにProject Wallace Webhooksをインストールしました。プロジェクトに新しいCSSを追加するたびに、CSSをProjectWallace.comに送信し、プロジェクトのダッシュボードにすぐに表示されます。これにより、特定のセレクターまたはメディアクエリがCSSに追加されたときに簡単に見つけることができます。
• 今年初めにCSS-Tricksの再設(shè)計(jì)は、複雑さとファイルサイズが大幅に低下することを意味しました。再設(shè)計(jì)は素晴らしく、分析できます。舞臺裏の狀況を詳しく見て、著者がどのようにCSSを変えたかを把握する機(jī)會が與えられます。どのセクションがサイトで機(jī)能しないか、どの新しいセクションが適用されないかを知ることで、CSSがどれだけ速く成長しているかを知ることができます。
• オランダに拠點(diǎn)を置く大規(guī)模な國際企業(yè)は、かつてCSSファイルに4095を超えるセレクターを持っていました。彼らは積極的に新興市場を開発していることを知っており、Internet Explorer 8をサポートする必要があります。IE9は4095セレクターの後にすべてのCSSを読み取るのを停止するため、CSSのほとんどは古いIEブラウザーには適用されません。私は彼らにメールを送信し、彼らは問題を確認(rèn)し、CSSを2つのファイルに分割することですぐにそれを修正しました。
• GitLabは現(xiàn)在、70を超えるユニークなフォントサイズを使用しています。彼らのタイポグラフィは複雑であると確信していますが、これは少し野心的すぎるようです。たぶんそれは一部のサードパーティのCSSのためですが、判斷するのは難しいです。
• 他の開発者からプロジェクトを継承するとき、私はCSS分析結(jié)果をレビューして、プロジェクトの困難を理解します。彼らは大量にそれを使用していますか！重要ですか？平均ルールセットサイズは理解しやすいですか、それともルールあたり20以上の宣言を追加しますか？平均セレクターの長さはどれくらいで、カバーするのは難しいですか？ .complex-selector-override \ [class \] [class] ... [class]に頼らないのはいいことです。
• ズームアウトが効果的であるかどうかを確認(rèn)する巧妙なトリックは、コードのライン番號インジケーターが1以下でないかどうかを確認(rèn)することです。CSSの縮小は、すべてのCSSが1行に配置されるため、コードの行の數(shù)は1に等しい必要があります。
• 私の他のプロジェクトで常に起こったことは、縮小しなかったことでした。 Project Wallaceの違いが、#aaaaの代わりに#aaaaaのように多くの色が突然書かれていることを示すまで、私は知りません。これ自體は悪いことではありませんが、同時(shí)に非常に多くの色で起こり、何かが間違っていたに違いありません。簡単な調(diào)査で、私が縮小することを間違えたことが示されました。
• Stackoverflowには、白い色を書くための4つのユニークな方法があります。これは必ずしも悪いことではありませんが、CSSの模倣プログラムが設(shè)計(jì)システムで破損または矛盾していることの兆候である可能性があります。
• Facebook.comは、CSSに650以上のユニークな色を持っています。壊れた設(shè)計(jì)システムも可能性のように聞こえ始めています。
• 私の以前の雇用主からのプロジェクトは、入力[type =チェックボックス]を示しています。綿密な検査の後、このセレクターは別の入力にネストされた入力を見つけることがわかりました。これはHTMLでは不可能であり、CSSでコンマを忘れてしまったに違いないと思います。これについて警告するコードチェッカーはありません。
• CSSの前処理者に巣を作るのはクールですが、@media（max-width：670px）や（max-width：670px）のような間違ったものを引き起こす可能性があります。

プロジェクトウォレスにとって、これは氷山の一角にすぎません。 CSSの分析を開始すると、學(xué)習(xí)して発見することがさらにあります。自分の統(tǒng)計(jì)だけでなく、他の人がしていることも見てください。

Constyble構(gòu)成を、経験の少ない開発者との會話のトピックとして使用して、複雑なCSSブロックに基づいて構(gòu)築できない理由を説明しました。他の開発者と議論することで、特定のCSS作成方法を回避または宣伝する必要がある理由は、知識を転送するのに役立ちます。また、足を地面に保つのにも役立ちます。助けたいだけのPHP開発者に説明しなければならないことで、私が何年もやったことは、なぜ私が自分のやり方で物事をしているのかを考え直しました。

私の目標(biāo)は、CSSで正しいか間違っているかを誰かに伝えることではなく、あなたとあなたの同僚に役立つものを確認(rèn)できるようにツールを作成することです。 Project Wallaceは、私たちが書いているCSSを理解するのに役立つためにここにいます。

以上がCSSの品質(zhì)と複雑さを監(jiān)視するスタックを探しての詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。