Viele Programmiersprachen durchlaufen vor der Bereitstellung eine Code-Überprüfung. Ob es sich um eine schnelle Übersicht, eine eingehende Peer-Review oder vollständige Unit-Tests handelt, Code-Reviews helfen uns, Code mit Zuversicht zu veröffentlichen.
Ich begann mir vorzustellen, wie ein CSS-Code-Review aussehen könnte. CSS kann auf verschiedene Arten geschrieben werden, und der beste Weg ist oft projektbezogen. Ich versuche definitiv nicht, mit einem solchen Beitrag dogmatisch zu werden, sondern lege stattdessen die Grundlage für einen Ausgangspunkt, um das Beste aus CSS herauszuholen, bevor es veröffentlicht wird.
Warum sollte CSS überhaupt überprüft werden?
Es ist nur fair, sich zu fragen, warum wir CSS überhaupt überprüfen sollten. Eine Überprüfung ist ein weiterer Schritt, der Zeit, Kosten und Mühe und all die anderen Dinge hinzufügt, die uns scheinbar davon abhalten, ein Produkt zu versenden.
Gleichzeitig ermöglicht uns eine Code-Überprüfung, einen Schritt zurückzutreten, unsere Kampfausrüstung abzulegen und unsere Arbeit ehrlich zu bewerten – oder sie jemand anderem zur frischen Perspektive zu übergeben. Das unterscheidet uns von den Maschinen und kann uns am Ende den Ärger ersparen, uns mit Fehler- und Leistungsbehebungen herumschlagen zu müssen, die hätten behoben werden können, bevor sie ausgeliefert wurden.
Hier gibt es viel mehr Vorteile, als nur vorbeugend Fehler zu beheben. Ich finde, dass das Aufteilen einer Überprüfung in spezifische Bereiche, die sich auf diese Vorteile konzentrieren, hilft, das Gespräch zu strukturieren und diese positiven Ergebnisse zu priorisieren. Die Vorteile für Sie mögen anders sein als die, die ich hier behandeln werde, aber dies sind diejenigen, zu denen ich immer wieder zurückkehre.
Bereich 0: Es erfüllt seinen Zweck
Lassen Sie uns hier nicht verweilen, aber auch nicht vergessen. Die erste Aufgabe von CSS ist es, die Seite so zu gestalten, dass sie aussieht, wie sie aussehen soll. Sie entspricht dem Mockup des Designers oder passt zum Styleguide oder was auch immer sie tun soll. Und sie kann dies mit variablen Inhalten tun (Titel und Inhalte unterschiedlicher Länge, Bilder unterschiedlicher Größe usw.). Wenn nicht, muss dies zuerst behoben werden.
Wenn das Design responsiv ist, stellen Sie sicher, dass das Design fließend und an jedem Breakpoint das tut, was es tun soll.
Bereich 1: Stil und Konsistenz
Das Ziel ist hier, sicherzustellen, dass CSS gut geschrieben, organisiert und dokumentiert ist. Diejenigen unter uns, die Projekte von anderen Entwicklern übernommen haben, kennen die Vorteile hier. Code, der eine konsistente Benennungskonvention verwendet und eine gründliche Dokumentation enthält, ist leichter zu durchdringen und bietet Anweisungen zur Wartung und Verbesserung des Codes in der Zukunft.
Zu stellende Fragen
- Gibt es einen CSS-Styleguide für dieses Projekt? Wenn ja, folgt der Code diesem?
- Ist der Code gründlich dokumentiert? Gibt es verwirrende Elemente, Eigenschaften oder Hacks, die einen anderen Entwickler daran hindern könnten, zu wissen, warum etwas so geschrieben wurde, wie es geschrieben wurde?
- Gibt es offensichtliche Inkonsistenzen in der Benennung von Elementen oder in der Organisation ihrer Eigenschaften?
Verfügbare Ressourcen
- CSS Lint: Ein hervorragendes Werkzeug, um Fehler oder Inkonsistenzen zu finden. Es ist sogar als Grunt- und Gulp-Task verfügbar, die konfiguriert werden können, um gegen eigene Regelsätze zu prüfen.
- CSS Style Guides: Eine Sammlung von Styleguide-Beispielen, die als Inspiration für die Erstellung eigener Styleguides verwendet werden können.
- Was macht gute Dokumentation aus?: Dave DeSandro erklärt, wie Dokumentation mit Marketing zusammenhängt.
Bereich 2: Browserkompatibilität
Sobald CSS organisiert und konsistent ist, wende ich mich normalerweise der Frage zu, wie es in verschiedenen Browsern und Geräten aussieht. Gut geschriebener Code ist eine Sache, aber er ist nicht viel wert, wenn er nicht funktioniert, wo und wann er soll.
Zu stellende Fragen
- Welche Browser und Geräte unterstützt dieses Projekt? Haben wir Zugriff darauf zum Testen?
- Gibt es Analysen für diese Website? Wenn ja, geben sie uns Einblicke, für welche Browser das Testen wichtiger ist?
- Gibt es Fälle von "Hacks", die auf einen bestimmten Browser oder ein bestimmtes Gerät abzielen? Wenn ja, gibt es einen anderen Weg, sie zu umgehen? Sind sie gut dokumentiert?
Verfügbare Ressourcen
- Can I Use: Ein zentrales Repository, um nachzuschlagen, welche CSS-Eigenschaften mit welchem Browser und welcher Version kompatibel sind.
- Ghostlab: Eine App für synchronisierte Browser-Tests auf mehreren Geräten.
- OpenDeviceLab.com: Eine interaktive Karte, um nahegelegene Geräte-Labore für Tests zu finden.
- Einrichten eines Open Device Lab: Smashing Magazine befasst sich eingehend mit den Vorteilen von Geräte-Labs und gibt Tipps, wie man eines einrichtet.
- Support vs. Optimierung: Brad Frost behandelt hervorragend den Unterschied zwischen den beiden und wie sich das auf die Art und Weise auswirken kann, wie Code geschrieben wird.
- Dienstleistungen für Cross-Browser-Tests: Cross Browser Testing oder Browserstack.
Bereich 3: Spezifität
Jetzt ist es an der Zeit, zu beurteilen, wie spezifisch die Elemente im Code sind und ob es Möglichkeiten zur Refaktorierung gibt. Dies schafft eine verantwortungsvolle Kaskade von Stilen, bei der Elemente entweder so modular oder so spezifisch sind, wie wir es wollen.
Zu stellende Fragen
- Werden IDs irgendwo verwendet? Wenn ja, reicht ein Klassenname stattdessen aus? Sagt der Styleguide dazu etwas?
- Findet sich `!important` im Code wieder? Wenn ja, warum wurde es verwendet und kann der Code refaktorisiert werden, um seine Verwendung zu vermeiden?
- Verlassen wir uns auf Präfixe, und wenn ja, sind die Präfixe so organisiert, dass für nicht unterstützte Browser ordnungsgemäße Standardwerte vorhanden sind?
- Wie modular sind die Elemente? Halten sie einem "Kitchen Sink"-Test stand, bei dem sie alle im selben HTML-Dokument zusammen verwendet werden?
Verfügbare Ressourcen
- CSS Specificity Graph Generator: Ein Werkzeug zur Visualisierung der Spezifität in einer gesamten Stylesheet.
- Specificity Calculator: Eine nette Möglichkeit, zu visualisieren, wie spezifisch ein Element ist.
- Details zur CSS-Spezifität: Ein Beitrag darüber, was Spezifität ist und ihre Auswirkungen auf die Kaskade von Stilen.
- Responsive Deliverables: Ich liebe die Idee, im Allgemeinen "Mini-Bootstraps" zu erstellen, aber es wäre großartig, auch die Spezifität zu testen.
Bereich 4: Preprocessor-Nutzung
Ignorieren Sie dies, wenn das Projekt keinen Preprocessor verwendet. Aber wenn es einen verwendet, gibt es sicherlich einige zusätzliche Dinge zu bedenken.
Zu stellende Fragen
- Werden vorhandene Variablen dort verwendet, wo sie sollten? Wurden neue Variablen eingeführt? Wenn ja, sind sie sinnvoll und dokumentiert?
- Wurden andere Abstraktionen (z. B. extends, mixins, loops, maps usw.) effektiv und in Übereinstimmung mit dem Rest des Codes verwendet?
- Wird das neue CSS in die richtigen Partials platziert? Wurden neue Partials verwendet? Sind sie architektonisch sinnvoll?
- Folgen sie etablierten Preprocessor-spezifischen Styleguides?
Verfügbare Ressourcen
- Sass Style Guide hier auf CSS-Tricks
- Sass Guidelines von Kitty Giraudel
Bereich 5: Leistung
Ich nehme die Leistung gegen Ende einer Überprüfung auf, nicht um sie zu schmälern, sondern um sicherzustellen, dass sie das i-Tüpfelchen unseres Überprüfung-Sundae ist. Performantes CSS ist oft eine Frage der Verfeinerung und wie es verpackt und serviert wird, daher scheint es passend, den Überprüfungsprozess abzuschließen – auch wenn die Leistung bei der Arbeit immer im Hinterkopf mitschwingt.
Zu stellende Fragen
- Wie viel wiegt die endgültige CSS-Datei? Planen wir, sie zu minifizieren und zu gzippen (ja, bitte!), und wie groß ist der Gewichtsunterschied, wenn wir das tun?
- Wie viele verschiedene Stylesheets laden wir (über `
` oder natives `@import`)? Können wir diese Anzahl reduzieren? Können sie bedingt geladen werden? Asynchron? - Wir cachen CSS in der Produktion, oder?
Verfügbare Ressourcen
- CSS Stats: Geben Sie die URL einer Website ein und erhalten Sie eine Fülle von Statistiken, einschließlich eines Berichts über alle verwendeten Schriftarten und Farben.
- CSS Dig: Sehr ähnlich wie CSS Stats, aber als praktische Chrome-Erweiterung verpackt.
- unCSS: Ein Task-Runner, der ungenutztes CSS entfernt, indem er es mit dem HTML- und JavaScript-Markup vergleicht. Verfügbar für Grunt, Gulp und Broccoli.
- Critical CSS: Ein weiterer Task-Runner, der jedoch basierend auf dem HTML-Markup für eine gegebene Seite individuelle CSS-Dateien erstellt. Diese Optimierung wird von Google PageSpeed Insights konsequent empfohlen.
- loadCSS: Eine Funktion zum asynchronen Laden von CSS
Zusammenfassung
Ich würde definitiv nicht sagen, dass jede hier erwähnte Frage und jedes Werkzeug für alle Projekte notwendig oder auch nur relevant ist. Tatsächlich gibt es wahrscheinlich noch mehr Fragen und Werkzeuge zu bedenken. Gibt es Fragen, die Sie routinemäßig stellen, bevor Sie CSS veröffentlichen? Wo würde zum Beispiel die Barrierefreiheit für Sie Platz finden? Bitte teilen Sie es mit!
Denken Sie auch daran, dass das Ziel der Prüfung unseres Codes nicht darin besteht, ihn perfekt zu machen. Wir gehen aus vielen Gründen Kompromisse bei CSS ein (ob beabsichtigt oder nicht), und am Ende des Tages reicht es mehr als aus, einfach zu versuchen, eine gute Arbeit zu leisten, und dies ist Teil dieser Bemühungen.
Obwohl es in einigen Styleguides enthalten ist, denke ich, dass dies ein eigener Bereich nur für die Verschachtelung sein sollte.
Keine Erwähnung von SMACSS? Es war ein Segen für unser Team in Bezug auf die Organisation der Projektstruktur und Erweiterbarkeit.
Insgesamt guter Überblick für ein CSS-Code-Review. Danke!
Ich denke, SMACSS (oder jede Art von CSS-Standardkonvention) ist impliziert. Ziel ist es, sicherzustellen, dass alle angenommenen Standards konsistent angewendet werden und jeder im Team dafür zur Rechenschaft gezogen wird.
Eine Sache, die ich zu Bereich 0 hinzufügen würde: Es tut nichts, was es nicht tun soll.
Ich arbeite in einer Abteilung, die viele webbasierte Projekte generiert, die "ähnlich wie das andere, das du gemacht hast, aber..." sind. Der Ausgangspunkt für viele dieser Projekte ist das Kopieren des Codes des vorherigen, und standardmäßig wird dieser Code für die Bedürfnisse des neuen Projekts ergänzt. Das Ergebnis ist oft ein weitläufiges CSS, das oft Selektoren enthält, die im neuen Projekt nicht einmal vorhanden sind.
Daher wäre ein Review, das darauf hinweist, dass diese Dateien vieles tun, was nicht relevant ist, und die Ladezeit dadurch verlangsamen, ein nützlicher Schritt.
Das ist ein guter Punkt: Klar definieren, was CSS für das Projekt bedeutet, und sicherstellen, dass es weder diese Standards verletzt noch Grenzen überschreitet.
Sie können den fehleranfälligen menschlichen Faktor reduzieren, indem Sie Validierungsaufgaben während der Build-Automatisierung hinzufügen. Es ist sehr einfach, ständig zu überprüfen, ob Ihr CSS den zuvor definierten Standards entspricht.
Ich liebe die Verwendung von Scss-lint, um zu prüfen, ob ein Projekt sehr strenge Stilrichtlinien befolgt, einschließlich der Namenskonvention für Selektoren. Außerdem können Sie eigene reguläre Ausdrücke zum Testen erstellen.
Zustimmung, automatisierte Aufgaben sind großartig! Wenn Sie diese parallel zu einer Art gemeinsamer Code-Stilrichtlinie ausführen, wäre das ziemlich episch, anstatt diese Standards und die Dokumentation an zwei Orten pflegen zu müssen.
Ich bewerte tatsächlich ständig die CSS unserer Bootcamp-Studenten und ich kann sagen, dass Anfänger oft sehr schlechte Entscheidungen bei der Wahl von CSS-Selektoren treffen. Mit anderen Worten, sie haben vielleicht nur ein `header`-Element auf der Seite, also schreiben sie `header {}`, ohne die Erwartung eines weiteren Headers. Oder vielleicht schreiben sie `.some-component div {}`, mit der Idee, dass ihre Komponente im Moment nur ein div hat, also scheint das für sie in Ordnung zu sein. Ich meine damit, dass Anfänger Schwierigkeiten haben, die Zukunft des Projekts vorherzusehen und wie die Art und Weise, wie Selektoren geschrieben werden, zwangsläufig fehlschlägt, wenn mehr Markup hinzugefügt wird. In diesen Fällen könnten `.primary-header` und `.some-component .sub-component` stärker sein.
Offensichtlich können wir Selektoren nicht auf eine Weise schreiben, die gegen zukünftige Markup-Änderungen immun ist, aber ich würde sagen, dass eine weitere Sache, auf die man bei einer Überprüfung achten sollte, das ist, was ich "Future-Proofing" der Selektoren nenne, um es unwahrscheinlicher zu machen.
Das ist in der Tat ein wichtiger Punkt, und das gilt auch für viele Teams. Dort wäre es von Vorteil, im Voraus Standards in einer Art Code-Stilrichtlinie zu definieren, mit dem Wissen, dass auch diese gut gepflegt und im Zuge der sich entwickelnden Standards geändert werden muss... so wie wir es dieses Jahr mit einem Sass-Styleguide getan haben: https://css-tricks.de/sass-style-guide/
Eine weitere Sache, die es wert ist zu erwähnen, ist Parker https://github.com/katiefenn/parker
Sehr praktisches CSS-Statistik-Tool.
Wir haben bei einem früheren Unternehmen CSS- und HTML-Reviews durchgeführt (tatsächlich wurde jede Codezeile überprüft, bevor sie in Produktion ging).
Es dauert weniger lange, als die Leute denken. Wir haben uns keine detaillierten Analysen oder gar den gerenderten Inhalt angesehen – nur den Code. QA wird visuelle Fehler/Browser-Inkonsistenzen feststellen. Effektiv haben wir alles oben Genannte außer Bereich 0 und 5 geprüft.
Sie werden vielleicht auch überrascht sein, wie viel bei der Überprüfung auffällt.
Ich stimme Ihnen zu, es dauert kaum Zeit, und je mehr man es tut, desto besser erkennt man die Inkonsistenzen. Bei meinem ersten Job wurde ich am Ende jedes Projekts einer Code-Überprüfung unterzogen, und das hat mich zu einem viel besseren Entwickler gemacht, schließlich kann man nicht aus seinen Fehlern lernen, wenn man nicht weiß, dass es Fehler waren.
Ich stimme den Punkten zu, mit Ausnahme von `!important`. Es hat seine Verwendungszwecke, sollte aber nur unter bestimmten Umständen verwendet werden.
Ich folge dem ITCSS-System zur CSS-Organisation, und damit habe ich einen "Trumps"-Bereich, der am Ende des Stylesheets kommt. Er enthält eine Liste von Hilfsfunktionen, die immer gewinnen müssen. In dieser Datei erhält alles `!important` hinzugefügt.
Außerhalb davon sollte jedoch jedes gefundene `!important` genau geprüft werden, ebenso wie jede ID.
Toller Artikel, Geoff! Ich implementiere in den letzten Monaten viele ähnliche Techniken in meinem Team. Wir konzentrieren uns insbesondere auf die gemeinsame Nutzung von SCSS Lint und CSSComb, um unsere Styleguide-Konventionen im verteilten Team durchzusetzen und zu automatisieren. Durch die Automatisierung so vieler Stilkonventionen wie möglich haben wir unsere eigentliche Code-Review-Zeit frei gemacht, um uns auf strategischere Entscheidungen wie die Benennung von Klassen, die Spezifität und die Entscheidung, wann bestehende Website-Muster verwendet oder gebrochen werden sollen, zu konzentrieren.
Ich mag besonders die SCSS-Lint-Editor-Plugins für Atom und SublimeText, da sie eine visuelle Erinnerung an den Styleguide bieten, während man arbeitet. Ein weiterer Vorteil der visuellen Erinnerung ist, dass man sehen kann, was falsch ist, bevor man den Build fehlschlagen sieht. In unserem Fall arbeiten wir an der Verbesserung eines großen Legacy-Systems, daher wollte ich ein Werkzeug, das uns helfen kann, Abschnitte inkrementell zu verbessern, anstatt uns zu zwingen, eine vollständige Änderung vorzunehmen, bevor wir bereit sind.
Ein Bereich, der in unseren CSS-Code-Reviews zu einigen Debatten geführt hat, betrifft die Verwendung von Post-Prozessoren und wie sie den endgültig ausgegebenen Code beeinflussen. Zum Beispiel könnte man auf etwas stoßen wie
Man könnte eine vernünftige Kritik erwarten, die Folgendes beinhaltet:
padding: 0px;- Einheiten für "0"-Werte entfernen
transform: translate(20px,0);- Vendor-Präfixe?
line-height: 0.9;- hier wird keine "0" benötigt
font-size: 16px;- man könnte Bytes sparen, indem man stattdessen "font-size: 1pc" verwendet
margin: 0 !important;- warum "!important"? Ein Kommentar, der erklärt, warum Sie dies benötigen, wäre gut, außerdem benötigen Sie hier kein abschließendes Semikolon
Der Punkt ist, dass unser Post-Prozessor (in unserem Fall postcss) sich um all diese Dinge kümmert (außer dem Kommentar). Die Frage ist also: Wo zieht man die Grenze zwischen der Qualität von vorverarbeitetem Code und der Qualität der endgültigen nachbearbeiteten Ausgabe beim Überprüfen von Code? Wie findet man ein Gleichgewicht zwischen der Durchsetzung guter Codierungspraktiken und dem Lassen des Post-Prozessors seine Arbeit tun?
Wenn ich Geoff's Ratschläge lese, denke ich, dass wir unseren eigenen Prozess verbessern könnten, indem wir uns mehr auf die Bereiche 1, 3 & 4 konzentrieren und weniger auf Semantik und Mikro-Performance-Verbesserer, was ich auf jeden Fall mitnehmen werde.
Ich glaube nicht, dass die Qualität des verarbeiteten Codes wichtig ist, niemand wird ihn lesen, er ist für die Maschine.
Der vorverarbeitete Code ist es, wo wir Best Practices und Standards befolgen sollten.
Wie in meinem Kommentar oben ist der Kommentar unnötig, wenn Sie eine Trumps-Datei für strenge Überschreibungen verwenden, aber woanders sollte er kommentiert werden. Ebenso wie alle magischen Zahlen.
Generell frage ich mich bei Dingen wie `margin: 0;` immer, was es rückgängig macht. In Ordnung, wenn es ein Browserstandard überschreibt, wie der Margin bei einem Blockquote. Aber wenn es zuvor deklariertes CSS überschreibt, gibt es wahrscheinlich ein Problem mit der zugrunde liegenden Struktur. Wenn wir feststellen, dass wir viele Stile überschreiben, die wir wahrscheinlich zu früh deklariert haben.
Ich glaube nicht, dass das Weglassen bestimmter Einheiten oder des Semikolons bei der endgültigen Deklaration und so weiter im vorverarbeiteten Code wichtig ist, unser Post-Prozessor kann all diese Dinge entfernen. Ich persönlich ziehe es vor, die Semikolons beizubehalten, aus denselben Gründen, aus denen ich es für schlecht halte, sie in JavaScript zu entfernen – es ist eine häufige Fehlerquelle und Verwirrung.
Sehr gut. Danke