Haben Sie jemals ein gut gemeintes, durchdachtes Designsystem erstellt, nur um zuzusehen, wie es zu einer immer größer werdenden und beängstigenden Codebasis heranwächst? Ich habe in gewisser Weise in die entgegengesetzte Richtung gearbeitet, die beängstigende Codebasis geerbt und versucht, daraus ein durchdachtes System zu erstellen.
Hier spricht Alex Sanders über das Thema und erklärt, wie sein Team bei The Guardian die Aufgabe der Erstellung von Designsystemen bewältigt und gleichzeitig die Komplexität bekämpft.
Systeme, die versuchen, Komplexität über lange Zeiträume hinweg durch Konventionen einzudämmen, werden zwangsläufig zur Entropie tendieren, da eine wesentliche Eigenschaft von Konventionen darin besteht, dass es trivial einfach ist, eine zu brechen.
Sie müssen nicht einmal böswillig sein. Eine Konvention ist keine Linie im Sand. Sie können einen sehr guten Grund haben, eine zu brechen oder zu dehnen, aber sobald eine Konvention nicht mehr vollständig eingehalten wird, sind nachfolgende Gründe, sie zu brechen oder zu dehnen, automatisch stärker, weil die Konvention bereits geschwächt ist. Je mehr dies geschieht, desto schwächer wird sie.
Komplexität und Entropie können zwei Ergebnisse derselben Situation sein, müssen aber nicht gegenseitig ausschließend sein. Interessant zu bedenken, dass unsere besten Absichten, vor Komplexität zu schützen, eher destruktiv sein können.
Mir gefällt auch sehr gut, wie Alex erklärt, warum es für sein Team nicht möglich ist, einen Tachyons-ähnlichen Ansatz zum Schreiben von Stilen zu verwenden, da ihre Entwicklungsumgebung etwas langsam ist. Es wäre für das Team schmerzhaft, diesen Wechsel vorzunehmen, obwohl er einige andere Probleme lösen könnte. Dies erinnerte mich daran, dass die Messung von Problemen auf diese Weise der Grund dafür ist, dass es nie eine einzige Möglichkeit gibt, CSS zu schreiben. Wir brauchen diese inhärente Flexibilität, auch auf Kosten der Einführung von Inkonsistenzen. Daher sind Konventionen weniger eine Linie im Sand und mehr ein Wegweiser.
Nebenbei bemerkt, gefällt mir sehr gut, wie Alex Stile und Attribute als Gründe dafür beschreibt, warum sein Team diese Stile schreibt. Es geht darum, sich an Geschäftsziele anzupassen.
...zehntausende von Regeln, die darauf abzielen, eine wartbare Reihe von Antworten auf Geschäfts- und Designprobleme zu beschreiben.
Das ist interessant, da ich glaube, dass wir hier nicht viel Zeit damit verbringen, speziell über die geschäftliche Seite von CSS und die funktionalen Anforderungen zu sprechen, die eine gestylte Benutzeroberfläche erfüllen muss.
Und vielleicht kann uns das Denken darüber helfen, langfristig bessere Stile zu schreiben. Löst diese CSS-Zeile ein Problem? Löst diese neue Klasse ein Problem, das unseren Kunden helfen wird? Das sind gute Fragen, die wir bei der Arbeit im Hinterkopf behalten sollten, obwohl ich weiß, dass ich nicht genug Zeit damit verbringe, darüber nachzudenken. Oft sehe ich das Design, das ich in Code umwandle, eher als ein zu lösendes Problem.
Vielleicht sollten wir die Art und Weise, wie wir Webseiten stylen, erweitern, denn vielleicht, nur vielleicht, hilft uns das, wartbareren Code zu schreiben, der darauf ausgelegt ist, ein echtes Geschäfts-ziel zu lösen.