CSSの品質と複雑さを監視するスタックを探して

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

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

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

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

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

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

これにより、コマンドラインでCSS分析を実行し、提供するCSSの統計を取得できます。

Constyble Code Checker

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

アナライザ

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

レポーター

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

CSSの複雑さを分析します

CSSの複雑さに関する記事はあまりありませんが、ハリー・ロバーツ（CSSwizardry）が書いた1つは感銘を受けました。ポイントは、各CSSセレクターが基本的にIFステートメントの束であるということです。これは、コンピューターサイエンスコースを受講するときに手動で計算しなければならなかった方法のループの複雑さを思い出させます。ハリーの記事は、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の一部を削除することが困難になり、より複雑になります。

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

 <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の検査官が検査されないコードをチェックしているため、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を2つのファイルに分割することですぐにそれを修正しました。
• GitLabは現在、70を超えるユニークなフォントサイズを使用しています。彼らのタイポグラフィは複雑であると確信していますが、これは少し野心的すぎるようです。たぶんそれは一部のサードパーティのCSSのためですが、判断するのは難しいです。
• 他の開発者からプロジェクトを継承するとき、私はCSS分析結果をレビューして、プロジェクトの困難を理解します。彼らは大量にそれを使用していますか！重要ですか？平均ルールセットサイズは理解しやすいですか、それともルールあたり20以上の宣言を追加しますか？平均セレクターの長さはどれくらいで、カバーするのは難しいですか？ .complex-selector-override \ [class \] [class] ... [class]に頼らないのはいいことです。
• ズームアウトが効果的であるかどうかを確認する巧妙なトリックは、コードのライン番号インジケーターが1以下でないかどうかを確認することです。CSSの縮小は、すべてのCSSが1行に配置されるため、コードの行の数は1に等しい必要があります。
• 私の他のプロジェクトで常に起こったことは、縮小しなかったことでした。 Project Wallaceの違いが、#aaaaの代わりに#aaaaaのように多くの色が突然書かれていることを示すまで、私は知りません。これ自体は悪いことではありませんが、同時に非常に多くの色で起こり、何かが間違っていたに違いありません。簡単な調査で、私が縮小することを間違えたことが示されました。
• Stackoverflowには、白い色を書くための4つのユニークな方法があります。これは必ずしも悪いことではありませんが、CSSの模倣プログラムが設計システムで破損または矛盾していることの兆候である可能性があります。
• Facebook.comは、CSSに650以上のユニークな色を持っています。壊れた設計システムも可能性のように聞こえ始めています。
• 私の以前の雇用主からのプロジェクトは、入力[type =チェックボックス]を示しています。綿密な検査の後、このセレクターは別の入力にネストされた入力を見つけることがわかりました。これはHTMLでは不可能であり、CSSでコンマを忘れてしまったに違いないと思います。これについて警告するコードチェッカーはありません。
• CSSの前処理者に巣を作るのはクールですが、@media（max-width：670px）や（max-width：670px）のような間違ったものを引き起こす可能性があります。

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

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

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

以上がCSSの品質と複雑さを監視するスタックを探しての詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。