Auf der Suche nach einem Stack, der die Qualität und Komplexität von CSS überwacht

Viele Entwickler schreiben darüber, wie man eine CSS-Codebasis pflegt, aber nicht viele von ihnen schreiben darüber, wie sie die Qualität dieser Codebasis *messen*. Sicher, wir haben exzellente Linter wie StyleLint und CSSLint, aber sie helfen nur dabei, Fehler auf einer Mikroebene zu verhindern. Die Verwendung einer falschen Farbnnotation, das Hinzufügen eines Vendor-Präfixes, wenn Sie bereits Autoprefixer verwenden, das Schreiben eines Selektors auf inkonsistente Weise... solche Dinge.

Wir suchen ständig nach Wegen, die Art und Weise, wie wir CSS schreiben, zu verbessern: OOCSS, BEM, SMACSS, ITCSS, Utility-First und mehr. Aber während andere Entwicklungsgemeinschaften scheinbar von reinen Lintern zu Werkzeugen wie SonarQube und PHP Mess Detector fortgeschritten sind, mangelt es der CSS-Community immer noch an Werkzeugen für tiefere Inspektionen als nur oberflächliche Linter-Regeln. Aus diesem Grund habe ich Project Wallace entwickelt, eine Suite von Werkzeugen zur Inspektion und Durchsetzung der CSS-Qualität.

Was ist Project Wallace?

Im Kern ist Project Wallace eine Gruppe von Werkzeugen, die eine Kommandozeilenschnittstelle, einen Linter, Analysen und Berichterstattung umfassen.

Hier ist eine kurze Übersicht über diese Werkzeuge.

Kommandozeilenschnittstelle

Dies ermöglicht es Ihnen, CSS-Analysen auf der Kommandozeile auszuführen und Statistiken für jedes CSS zu erhalten, das Sie ihm zuführen.

Constyble Linter

Dies ist ein Linter, der speziell für CSS entwickelt wurde. Basierend auf den von Wallace generierten Analysen können Sie Schwellenwerte festlegen, die nicht überschritten werden dürfen. Zum Beispiel sollte eine einzelne CSS-Regel nicht mehr als 10 Selektoren enthalten, oder die durchschnittliche Selektorkomplexität sollte nicht höher als drei sein.

Analyse

Extract-CSS tut genau das, was der Name sagt: Es extrahiert das gesamte CSS von einer Webseite, damit wir es zur Analyse an projectwallace.com senden können.

Berichterstattung

Alle Analysen von Extract CSS werden an projectwallace.com gesendet, wo ein Dashboard alle Berichte dieser Daten enthält. Es ist ähnlich wie CSS Stats, aber es verfolgt mehr Metriken und speichert die Ergebnisse im Laufe der Zeit und zeigt sie in einem Dashboard an. Es zeigt auch die Unterschiede zwischen zwei Zeitpunkten und viele, viele weitere Funktionen.

Analyse der CSS-Komplexität

Es gibt nicht viele Artikel über CSS-Komplexität, aber der, den Harry Roberts (csswizardry) geschrieben hat, ist mir im Gedächtnis geblieben. Im Wesentlichen ist jeder CSS-Selektor im Grunde eine Reihe von If-Anweisungen, was mich an meine Informatik-Kurse erinnerte, in denen ich manuell die zyklomatische Komplexität für Methoden berechnen musste. Harrys Artikel ergab für mich absolut Sinn, in dem Sinne, dass wir ein Modul schreiben können, das die Komplexität eines CSS-Selektors berechnet – natürlich nicht zu verwechseln mit der Spezifität, denn das ist eine ganz andere Problematik, wenn es um Komplexität geht.

Grundsätzlich kann Komplexität in CSS viele Formen annehmen, aber hier sind die, auf die ich bei der Überprüfung einer Codebasis am meisten achte.

Die zyklomatische Komplexität von CSS-Selektoren

Jeder Teil eines Selektors bedeutet eine weitere If-Anweisung für den Browser. Längere Selektoren sind komplexer als kürzere. Sie sind schwieriger zu debuggen, langsamer vom Browser zu parsen und schwerer zu überschreiben.

.my-selector {} /* 1 identifier */
.my #super [complex^="selector"] > with ~ many :identifiers {} /* 6 identifiers */

Deklarationen pro Regelblock (Kohäsion)

Ein Regelblock mit vielen Deklarationen ist komplexer als ein Regelblock mit wenigen Deklarationen. Die Popularität von funktionalen CSS-Frameworks wie Tailwind und Tachyons ist wahrscheinlich auf die relative „Einfachheit“ des CSS selbst zurückzuführen.

/* 1 rule, 1 declaration => cohesion = 1 */
.text-center {
  text-align: center;
}

/* 1 rule, 8 declarations => cohesion = (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;
}

Die Anzahl der Quellcodezeilen

Mehr Code bedeutet mehr Komplexität. Jede geschriebene Codezeile muss gepflegt werden und ist somit in der Berichterstattung enthalten.

Durchschnittliche Selektoren pro Regel

Eine Regel enthält normalerweise 1 Selektor, aber manchmal sind es mehr. Das macht es schwierig, bestimmte Teile des CSS zu löschen, was es komplexer macht.

---

All diese Metriken können mit Constyble, dem CSS-Komplexitäts-Linter, den Project Wallace in seinem Stack verwendet, gelintet werden. Nachdem Sie eine Basislinie für Ihre Metriken definiert haben, ist es eine Frage der Installation von Constyble und der Einrichtung einer Konfigurationsdatei. Hier ist ein Beispiel für eine Konfigurationsdatei, die ich direkt aus der Readme-Datei von Constyble übernommen habe.

{
  // Do not exceed 4095 selectors, otherwise IE9 will drop any subsequent rules
  "selectors.total": 4095,
  // We don't want ID selectors
  "selectors.id.total": 0,
  // If any other color than these appears, report an error!
  "values.colors.unique": ["#fff", "#000"]
}

Das Coole ist, dass Constyble mit Ihrem endgültigen CSS arbeitet, sodass es seine Arbeit erst erledigt, nachdem Ihre gesamte vorverarbeitete Arbeit von Sass, Less, PostCSS oder was auch immer Sie verwenden, abgeschlossen ist. Auf diese Weise können wir intelligente Prüfungen für die Gesamtmenge der Selektoren oder die durchschnittliche Selektorkomplexität durchführen – und wie bei jedem Linter können Sie dies als Teil eines Build-Schritts integrieren, bei dem Ihr Build fehlschlägt, wenn es Probleme gibt.

Erkenntnisse aus der Nutzung von Project Wallace

Nachdem ich Project Wallace nun schon eine Weile nutze, habe ich festgestellt, dass es hervorragend zur Verfolgung der Komplexität geeignet ist. Aber obwohl es hauptsächlich dafür entwickelt wurde, ist es auch eine großartige Möglichkeit, subtile Fehler in Ihrem CSS zu finden, die Linter möglicherweise nicht finden, da sie vorverarbeiteten Code prüfen. Hier sind ein paar interessante Dinge, die ich gefunden habe.

• Ich habe aufgehört, die Anzahl der User Stories in unseren Sprints zu zählen, in denen wir inkonsistente Farben auf einer Website beheben mussten. Projekte, die mehrere Jahre alt sind und in denen Leute das Unternehmen betreten und verlassen: Das ist ein Rezept dafür, dass auf einer Website jede einzelne Markenfarbe falsch gesetzt wird. Glücklicherweise haben wir Constyble und Project Wallace implementiert, um das Einverständnis der Stakeholder zu gewinnen, da wir beweisen konnten, dass das Branding für unseren Kunden bei neueren Projekten einwandfrei war. Constyble hindert uns daran, Farben hinzuzufügen, die nicht im Styleguide enthalten sind.
  

  

• Ich habe Project Wallace Webhooks für alle Projekte installiert, an denen ich bei einem meiner früheren Arbeitgeber gearbeitet habe. Jedes Mal, wenn neues CSS zu einem Projekt hinzugefügt wird, sendet es das CSS an projectwallace.com und es ist sofort im Dashboard der Projekte sichtbar. Das macht es ziemlich einfach, festzustellen, wann ein bestimmter Selektor oder eine Media-Query zum CSS hinzugefügt wurde.
  

  

• Der CSS-Tricks-Relaunch Anfang dieses Jahres bedeutete einen massiven Rückgang der Komplexität und Dateigröße. Relaunches sind fantastisch zu analysieren. Sie geben Ihnen die Möglichkeit, einen kleinen Blick hinter die Kulissen zu werfen und herauszufinden, was und wie die Autoren ihr CSS geändert haben. Zu sehen, welche Teile für die Website nicht funktioniert haben und welche neuen Teile funktionieren, kann Ihnen ein oder zwei Dinge darüber lehren, wie schnell sich CSS weiterentwickelt.
• Ein großes internationales Unternehmen mit Sitz in den Niederlanden hatte einst mehr als 4.095 Selektoren in einer einzigen CSS-Datei. Ich wusste, dass sie aggressiv in aufstrebenden Märkten wuchsen und Internet Explorer 8+ unterstützen mussten. IE9 hört auf, alles CSS nach 4.095 Selektoren zu lesen, sodass ein Großteil ihres CSS in alten IE-Browsern nicht angewendet wurde. Ich habe ihnen eine E-Mail geschickt, sie haben das Problem bestätigt und es sofort durch das Aufteilen des CSS in zwei Dateien behoben.
• GitLab verwendet derzeit mehr als 70 einzigartige Schriftgrößen. Ich bin mir ziemlich sicher, dass ihr Typografie-System komplex ist, aber das scheint ein wenig ehrgeizig. Vielleicht liegt es an einem Drittanbieter-CSS, aber das ist schwer zu sagen.
  

  

• Wenn ich ein Projekt von anderen Entwicklern übernehme, schaue ich mir die CSS-Analysen an, um ein Gefühl für die schwierigen Teile des Projekts zu bekommen. Haben sie viel !important verwendet? Ist die durchschnittliche Regelblockgröße verständlich, oder haben sie jeweils 20+ Deklarationen hineingeworfen? Wie lang ist die durchschnittliche Selektorlänge, werden sie schwer zu überschreiben sein? Es wäre schön, nicht auf .complex-selector-override\[class\][class][class]...[class] zurückgreifen zu müssen.
• Ein netter Trick, um zu überprüfen, ob Ihre Minifizierung funktioniert, ist, Constyble überprüfen zu lassen, ob die Metrik "Lines of Code" nicht größer als 1 ist. CSS-Minifizierung bedeutet, dass das gesamte CSS in eine einzige Zeile geschrieben wird, daher sollte die Anzahl der Zeilen 1 betragen!
• Eine Sache, die in einem anderen meiner Projekte immer wieder vorkam, war, dass die Minifizierung fehlschlug. Ich hatte keine Ahnung, bis ein Project Wallace-Diff mir zeigte, wie eine Reihe von Farben plötzlich wie #aaaaaa statt #aaa geschrieben wurden. Das ist nicht unbedingt schlecht, aber es passierte für so viele Farben gleichzeitig, dass etwas aus der Reihe tanzen musste. Eine schnelle Untersuchung zeigte mir, dass ich einen Fehler bei der Minifizierung gemacht hatte.
• StackOverflow hat vier einzigartige Arten, die Farbe Weiß zu schreiben. Das ist nicht unbedingt schlecht, aber es kann ein Hinweis auf einen fehlerhaften CSS-Minifier oder Inkonsistenzen im Designsystem sein.
• Facebook.com hat mehr als 650 einzigartige Farben in seinem CSS. Ein fehlerhaftes Designsystem beginnt auch für sie wahrscheinlich zu werden.
• Ein Projekt für einen meiner ehemaligen Arbeitgeber zeigte input[type=checkbox]:checked+.label input[type=radio]+label:focus:after als den komplexesten Selektor. Nach sorgfältiger Prüfung sahen wir, dass dieser Selektor ein in ein anderes Input verschachteltes Input anspricht. Das ist in HTML nicht möglich, und wir stellten fest, dass wir wahrscheinlich ein Komma in unserem CSS vergessen hatten. Kein Linter hat uns davor gewarnt.
• Verschachtelung in CSS-Präprozessoren ist cool, kann aber zu fehlerhaften Dingen führen, wie z. B. @media (max-width: 670px) and (max-width: 670px), wie ich sie bei Syntax.fm gefunden habe.

Dies ist nur die Spitze des Eisbergs, wenn es um Project Wallace geht. Es gibt noch so viel mehr zu lernen und zu entdecken, sobald Sie mit der Analyse Ihres CSS beginnen. Schauen Sie nicht nur auf Ihre eigenen Statistiken, sondern auch darauf, was andere tun.

Ich habe meine Constyble-Konfigurationen als Gesprächsgrundlage mit weniger erfahrenen Entwicklern verwendet, um zu erklären, warum ihr Build bei komplexen CSS-Blöcken fehlgeschlagen ist. Gespräche mit anderen Entwicklern darüber, warum wir bestimmte Arten des Schreibens von CSS vermeiden oder fördern, sind hilfreich für den Wissensaustausch. Und es hilft mir auch, auf dem Boden zu bleiben. Etwas erklären zu müssen, das ich seit Jahren mache, einem PHP-Entwickler, der nur helfen wollte, bringt mich dazu, zu überdenken, warum ich die Dinge so tue, wie ich sie tue.

Mein Ziel ist es nicht, jemandem zu sagen, was in CSS richtig oder falsch ist, sondern die Werkzeuge zu schaffen, damit Sie überprüfen können, was für Sie und Ihre Kollegen funktioniert. Project Wallace ist hier, um uns zu helfen, das CSS, das wir schreiben, zu verstehen.