BSkyBのシニアUI開発者であるHarryRoberts氏によると、開発者は、shame.cssと呼ばれる概念を使用して、プロジェクト内のクイックフィックス「ハック」CSSをサイロ化する必要があります。
Robertsはブログ投稿で、これにより開発者がCSS全体にハッキングが散らばっているのを見るのを止め、そのようなことはデフォルトで受け入れられると考える可能性があると説明しました。
さらに、この記事では、そのようなアプローチが適切に文書化され、反復する手段が付随している場合、ハッキングが使用されたプロジェクトで（何らかの理由で）よりクリーンなCSSに向けてより迅速に進むことができると述べています。
.netは、CSSのハッキングと、正しく使用された場合にshame.cssがもたらす可能性のある利点についてRoberts（HB）に話しました。
.net：業界の一部の人々は、サイトを機能させるための（願わくば）短期間のハッキングの必要性について非現実的である傾向があると思いますか？
HR： ビッグタイム。年間数百万ポンドを稼ぐサイトや製品で作業している場合、バグ、破損、癖がある場合は、できるだけ早く修正する必要があります。あなたの製品所有者はあなたのCSSが完璧であるかどうかを気にしません—彼らはサイトが稼働していて機能的であり、その収入を上回っていることを気にします。良いコード です 重要であり、ハッキングは理想からはほど遠いですが、ハッキングを常に防ぐことができ、短期的/迅速な修正は必要ありません。
.net：それで、あなたはそれらがビジネスの中でただ必要な悪であると言うでしょうか？
HR： クライアントが首を絞めているとき、またはライブサイトで機能が壊れているときは、適切な利害関係者を満足させていることを確認する必要があります。 2分で表面的に修正できたものの完璧な修正を書くのに1時間費やすとしたら、間違った人、つまり自分自身を幸せに保つことができると思います。
私自身の仕事では、ハッキングの「必要性」はプロジェクトのサイズにかなり比例して増加することがわかりましたが、それについての良い点は、後でそれらのハッキングの修正に専念するプロジェクト時間が増える可能性があることです。
.net：shame.cssの出番です。その概念で、CSSハックを具体的にどのように考えますか？
HR： より多くの時間を与えられれば、もっとうまくできたはずの何か。文脈から外れた例を考えるのは難しいですが、何かがハックであるときはよく知っていると思います。同僚に説明するのが恥ずかしいことを書いた？それはおそらくハックです！
したがって、shame.cssは、あなたがより良くできたかもしれないことのファイルを作成することであり、あなたがそれらを再訪する時間があるときにあなたはより良くすることができます。これは、実際には自作のやることリストです。時間があるときに考えるために片側に置いたハックのファイルです。
.net：あなたの記事では、ハッキングの文書化について言及していますが、開発者は、ハッキングだけでなく、CSSを文書化する必要があるという議論はありませんか？
HR： はい！すべての開発者がもっとやるべきことが1つあるとすれば、それはコメントを書くことです。コードだけではすぐにはわからないことはコメントする必要があります。コードを文書化して、帰宅途中にバスにぶつかった場合に、同僚が翌日引き継ぐことができるようにします。
.net：shame.cssの統合に関して、あなたは何を提案しますか？
HR： プリプロセッサを使用している場合、 @インポート インクルード 恥。[scss | less | etc] 理想的には、最後にファイルします。 （これは常に特異性とソース順序の問題につながる可能性があるため、マイレージは異なる場合があります。）
プリプロセッサを使用していないが、適切なビルドプロセスがある場合は、展開する前にすべてのCSSを連結して縮小する必要があります。そのため、shame.cssはその最後にボルトで固定できます。
プリプロセッサを使用していない場合 そして ビルドプロセスがない場合は、1つはおそらく修正する必要があり、2つは、スタイルシートの最後にあるハックセクションがおそらく最善の策です。 Shame.cssは一般公開を目的としていないため、マークアップのリンク要素によって呼び出される個別のスタイルシートを作成しないでください。連結および縮小されたスタイルシートを1つだけ提供する必要があります。
.net：コンセプトとしてのshame.cssが実際に普及した場合、それがデザインプロセスとWebサイト全般をどのように変える可能性があると思いますか？
HR： Shame.cssは、それを実装する開発者と同じくらい役に立ちます。それはすべてうまく、ハックを分離して文書化するのに適していますが、ハックを修正したり再訪したりしない場合は、以前と同じボートに乗っているだけです。
私にとって、shame.cssは、開発におけるより広範なシフトを示しています。 CSSに限定する必要はありません。コンセプトは、単に「ハッキングを認識し、文書化し、要点を述べる」ことです。あなたはその考えをすべてに適用することができます。
shame.cssに関連する実際の作業は、直属のチーム（開発者）を参加させ、ビジネス/ PM /スクラムマスター/ BA /製品の所有者（など）に、製品に含まれるものが少なくなる場合があるという事実を認識させることです。 -理想的ではないコードですが、このコードはビジネス要件を満たすために存在します。
ハッキングを分離して文書化していることを伝え、開発時間を整理するために割り当てます。コードベースを定量化できれば、コードベースを整理するためのビジネスケースを作成する方が簡単です。プロジェクトマネージャーに「機能Xに進む前に、片付けなければならないことがいくつかあります」と言っただけでは、必ずしもうまくいくとは限りません。あなたのPMに物事のリストを持って行き、片付けに費やすために半日のスプリント時間を取得してみてください。
shame.cssの背後にある考え方は、ハックをより透過的で、定量化可能で、分離することです。その情報をどうするかはあなた次第です！
