Laut Harry Roberts, Senior UI Developer bei BSkyB, sollten Entwickler ein Konzept namens shit.css verwenden, um jegliches Quick-Fix-Hack-CSS in Projekten zu speichern.
Roberts erklärte in einem Blog-Beitrag, dass dies möglicherweise verhindern würde, dass Entwickler Hacks im gesamten CSS sehen, und dass solche Dinge daher standardmäßig akzeptabel sind.
Darüber hinaus wurde in dem Artikel darauf hingewiesen, dass ein solcher Ansatz, wenn er ordnungsgemäß dokumentiert und von den Mitteln zur Iteration begleitet wird, einen schnelleren Fortschritt in Richtung saubereres CSS in Projekten ermöglichen könnte, in denen Hacks verwendet wurden (aus welchen Gründen auch immer).
.net sprach mit Roberts (HB) über das Hacken von CSS und die potenziellen Vorteile, die Shame.css bei korrekter Verwendung mit sich bringen könnte.
.net: Glauben Sie, dass einige Leute in der Branche dazu neigen, unrealistisch zu sein, dass (hoffentlich) kurzfristige Hacks erforderlich sind, um eine Website zum Laufen zu bringen?
HR: Große Zeit. Wenn Sie an einer Website oder einem Produkt arbeiten, das / das Millionen Pfund pro Jahr verdient, müssen Fehler, Brüche oder Macken so schnell wie möglich behoben werden. Ihrem Produktbesitzer ist es egal, ob Ihr CSS perfekt ist - er kümmert sich darum, dass die Website betriebsbereit und funktionsfähig ist und diese Einnahmen übertrifft. Guter Code ist wichtig, und Hacks sind alles andere als ideal, aber zu denken, dass Sie Hacks und kurzfristige / schnelle Korrekturen immer verhindern können, ist ein Mittelschiff.
.net: Sie würden also sagen, dass sie nur ein notwendiges Übel im Geschäft sind?
HR: Wenn ein Kunde Ihnen den Hals runter atmet oder eine Funktion auf einer Live-Site nicht funktioniert, müssen Sie sicherstellen, dass die richtigen Stakeholder zufrieden sind. Wenn Sie eine Stunde damit verbringen, die perfekte Lösung für etwas zu schreiben, das Sie in zwei Minuten oberflächlich hätten reparieren können, würde ich sagen, dass Sie die falsche Person bei Laune halten - dh sich selbst!
In meiner eigenen Arbeit habe ich festgestellt, dass der „Bedarf“ an Hacks relativ proportional zur Größe des Projekts zunimmt, aber das Gute daran ist, dass Sie wahrscheinlich auch später mehr Projektzeit für die Behebung dieser Hacks haben werden.
.net: Wo kommt Shame.css ins Spiel? Was halten Sie bei diesem Konzept konkret für einen CSS-Hack?
HR: Etwas, das mit mehr Zeit besser hätte gemacht werden können. Es ist schwer, sich Beispiele außerhalb des Kontexts vorzustellen, aber ich denke, Sie werden oft wissen, wann etwas ein Hack ist. Haben Sie etwas geschrieben, das Sie einem Kollegen erklären sollten? Das ist wahrscheinlich ein Hack!
In Shame.css geht es daher darum, eine Datei mit Dingen zu erstellen, die Sie besser hätten machen können und die Sie besser machen können, wenn Sie Zeit haben, sie erneut zu besuchen. Es ist wirklich eine selbstschreibende To-Do-Liste - eine Datei mit Hacks, die Sie beiseite legen, um darüber nachzudenken, wenn Sie mehr Zeit haben.
.net: In Ihrem Artikel erwähnen Sie die Dokumentation von Hacks, aber gibt es kein Argument, dass Entwickler CSS im Allgemeinen eher dokumentieren sollten als nur für Hacks?
HR: Ja! Wenn es eine Sache gibt, die alle Entwickler mehr tun sollten, ist es, Kommentare zu schreiben. Sie sollten alles kommentieren, was allein aus dem Code nicht sofort ersichtlich ist. Dokumentieren Sie Ihren Code, damit Ihr Kollege am nächsten Tag die Kontrolle übernehmen kann, wenn Sie auf dem Heimweg von einem Bus angefahren werden.
.net: Was schlagen Sie in Bezug auf die Integration von shit.css vor?
HR: Wenn Sie einen Präprozessor verwenden, @importieren das schade. [scss | less | etc] Datei direkt am Ende, idealerweise. (Dies kann immer zu Problemen mit der Spezifität und der Reihenfolge der Quellen führen, sodass Ihr Kilometerstand variieren kann.)
Wenn Sie keinen Präprozessor verwenden, aber einen anständigen Erstellungsprozess haben, sollte Ihr gesamtes CSS vor der Bereitstellung verkettet und minimiert werden.
Wenn Sie keinen Präprozessor verwenden und Sie haben keinen Build-Prozess, dann sollten Sie diesen wahrscheinlich beheben, und zweitens ist ein Hacks-Abschnitt am Ende Ihres Stylesheets wahrscheinlich die beste Wahl. Shame.css ist nicht für die öffentliche Ansicht vorgesehen. Verwenden Sie daher niemals ein separates Stylesheet, das von einem Linkelement in Ihrem Markup aufgerufen wird. Sie sollten nur ein verkettetes und minimiertes Stylesheet bereitstellen.
.net: Wenn sich Sham.css als Konzept wirklich durchsetzt, wie könnte es Ihrer Meinung nach den Designprozess und die Websites im Allgemeinen verändern?
HR: Shame.css ist nur so nützlich wie die Entwickler, die es implementieren. Es ist alles gut und schön, Hacks zu isolieren und zu dokumentieren, aber wenn Sie sie nie reparieren oder erneut besuchen, sitzen Sie einfach im selben Boot wie zuvor.
Shame.css signalisiert für mich eine breitere Verschiebung der Entwicklung; Es muss nicht auf CSS beschränkt sein. Das Konzept besteht lediglich darin, „Ihre Hacks zu realisieren, zu dokumentieren und zu verdeutlichen“. Sie können dieses Denken auf alles anwenden.
Die eigentliche Arbeit, die mit shit.css verbunden ist, besteht darin, Ihr unmittelbares Team (Entwickler) an Bord zu holen und dann das Unternehmen / PMs / Scrum-Master / BAs / Produktbesitzer (usw.) auf die Tatsache aufmerksam zu machen, dass ein Produkt manchmal weniger enthält -dann-idealer Code, aber dass dieser Code existiert, um die Geschäftsanforderungen zu erfüllen.
Sagen Sie ihnen, dass Sie Hacks isolieren und dokumentieren, und erhalten Sie etwas Entwicklungszeit, um die Dinge aufzuräumen. Es ist einfacher, ein Geschäftsmodell für das Aufräumen einer Codebasis zu erstellen, wenn Sie es quantifizieren können. Wenn Sie Ihrem Projektmanager einfach sagen: "Ich muss einige Dinge aufräumen, bevor ich zu Feature X übergehen kann", ist das nicht immer ausreichend! Nehmen Sie eine Liste mit Dingen zu Ihrer PM und versuchen Sie, einen halben Tag Sprintzeit für die Reinigung zu haben.
Die Idee hinter shit.css ist einfach, Ihre Hacks transparenter, quantifizierbarer und isolierter zu machen. Es liegt an Ihnen, was Sie mit diesen Informationen machen!
