Ich sprach neulich mit einem brillanten Ingenieurfreund, der erwähnte, dass er nie etwas von Grund auf neu bauen könne. Seine gesamte Karriere bestand darin, den (oft ziemlich schlechten) Code anderer Leute zu warten.
In einer perfekten Welt würden wir alle Code von Grund auf neu schreiben, er würde perfekt funktionieren und wir würden ihn in eine Wolke packen, damit ihn niemand mehr ansieht.
Wir wissen alle, dass es so nicht läuft. Code muss gepflegt werden.
Kyle Simpson beginnt oft seine Vorträge mit der Aussage, dass wir nur 30 % unserer Zeit mit dem Schreiben von Code verbringen und 70 % unserer Zeit mit dessen Pflege. Ein guter Kollege und Programmierer zu sein, bedeutet nicht nur, ein geschickter Problemlöser zu sein, sondern auch lesbar zu sein. Große Entwickler erstellen Code mit Blick auf die Wartung.
Ich scherze oft, dass ich keinen Code-Ninja einstellen möchte. Ninjas kommen mitten in der Nacht und hinterlassen ein blutiges Chaos.
Ich möchte einen Code-Hausmeister. Jemanden, der durch die Gänge des Codes geht, Teile reinigt, vernachlässigte Bereiche abstaubt, andere auf Hochglanz poliert und unnötige Stücke wegwirft. Diese sanftere, genauere Analogie bevorzuge ich. Das ist die Person, die Sie in Ihrem Team haben wollen. Das ist die Person, die Sie in Ihren Code-Reviews haben wollen.
Ein großes Dankeschön an JD Cantrell, der ein großartiger Code-Hausmeister und Code-Reviewer ist.
Denken wir über Code-Pflege aus der Perspektive zweier verschiedener Programmierparadigmen nach
In der Programmierung gibt es viele Werkzeuge und Verfahren, um dasselbe Ziel zu erreichen. Es gibt keine richtige Antwort. Hier ist eine prägnante Definition von Michael Feather von zwei sehr beliebten Programmierparadigmen
Objektorientierte Programmierung macht Code verständlich, indem sie bewegliche Teile kapselt...
Funktionale Programmierung macht Code verständlich, indem sie bewegliche Teile minimiert.
Betrachten wir beide im Hinblick auf nicht nur Verständlichkeit, sondern auch Wartung.
Funktionale Programmierung
Ich habe selbst den Wert der Verwendung eines funktionalen Ansatzes in Front-End-JavaScript erfahren. Wenn wir Code schreiben, wollen wir manchmal davon ausgehen, dass er für immer so verwendet wird, wie wir es beabsichtigt haben, aber die meisten von uns tun das schon lange genug, um anzuerkennen, dass dies nicht immer der Fall ist.
Funktionale Programmierung beinhaltet, ist aber nicht beschränkt auf:
- Sie ist deklarativ – wir schreiben auf eine Weise, die wiederverwendet werden kann, und sagen dem Computer nicht genau, was er bei jedem Schritt tun soll. Dies hat einige Ähnlichkeiten mit Abstraktion.
- Sie ist rein – wir verändern oder modifizieren nichts außerhalb des Geltungsbereichs der Funktion, und aus diesem Grund...
- Sie ist unveränderlich – Sie geraten nicht in eine Situation, in der Sie dieselbe Eingabe mehrmals mit unterschiedlichen Ergebnissen versehen.
Ich glaube, funktionale Programmierung kann aufgrund der fehlenden Nebeneffekte äußerst nützlich für die Wartung sein. Das ist riesig. Das verhindert, dass unser Code brüchig wird. Leute denken manchmal, das größte Problem seien Fehler in unserem Code. Ich würde argumentieren, dass der schlimmste Code nicht der ist, der Fehler verursacht und fehlschlägt. Diesen können wir mit methodischer Isolierung nachverfolgen. Der schlimmste Code ist Code, der sich auf unvorhersehbare Weise leise und überall verhält. Sie rennen durch die Codebasis und spielen Whack-a-Mole, und manchmal ist es schwierig, den Schuldigen zu finden. Ein funktionaler Programmierstil geht dieses Problem präventiv an, da er von Grund auf darauf ausgelegt ist, dies zu verhindern (so gut wie möglich).
Hier sind einige Ressourcen, wenn Sie tiefer in funktionale Programmierung eintauchen möchten
- Anjana Vakil: Learning Functional Programming with JavaScript – JSUnconf 2016
- Mary Rose Cook: Eine praktische Einführung in funktionale Programmierung
- Kyle Simpson:Functional Lite
So sehr ich funktionale Programmierung liebe, bitte beachten Sie, dass es immer noch Probleme mit der Wartung geben kann. Wenn einige Dinge dieselbe reine Funktion verwenden und Sie diese Funktion im Laufe der Zeit für eine ihrer Anwendungen anpassen, können Probleme auftreten, bei denen Sie auch andere Dinge ändern, die versteckte Abhängigkeiten sind. Gute Dokumentation ist hier sehr hilfreich.
Objektorientierte Programmierung
Im Gegensatz dazu ist die objektorientierte Programmierung eher wie das Befolgen der Schritte eines Rezepts. Sie verwendet Objekte, die Daten enthalten können oder auch nicht, und Methoden, die tendenziell prozedural sind. Typischerweise haben Objekte eine Vorstellung von sich selbst (z. B. „this“ in JavaScript). Objektorientierung konzentriert sich nicht auf Reinheit, sondern neigt dazu, Kapselung zu verwenden, um sicherzustellen, dass nichts in den äußeren Geltungsbereich austritt.
Im besten Fall denken objektorientierte Ansätze tendenziell über die höchste Ordnung von etwas nach, dann reduzieren sie sich auf jede Art von Instanz, die Sie haben können, und zerlegen, was in jedem Fall zu tun ist. Wenn Sie es sich wie das Linsche System der Klassifizierung von Tieren vorstellen und wie wir Morphologietbäume erstellen würden (wer würde das nicht? :)) Sie würden damit beginnen zu fragen, ob es warmblütig ist? Dann, hat es Fell? Dann hat es eine Schnauze? usw. Ich verhunze hier wirklich die Biologie, aber es ist ein Beispiel.
Im schlimmsten Fall erfährt objektorientierte Programmierung viel berechtigte Kritik, weil man manchmal nicht klar beschreibt, was man zu beschreiben glaubt. Sie können sich das so vorstellen: Sie denken, etwas sei eine Banane, aber es ist wirklich ein Pfirsich, weil Ihnen nur gesagt wurde, dass Sie eine Frucht haben. Wir haben bereits kurz darüber gesprochen, wie solche Codes ein Albtraum für die Wartung sein können, also ist das zwar nicht immer der Fall, aber es kann sicherlich vorkommen.
Ein anwendbares Beispiel in CSS
Mit beiden funktionalen und objektorientierten Ansätzen im Hinterkopf betrachten wir, wie sich das auf CSS und das Konzept von Autorenschaft versus Wartung auswirkt. CSS wird deklarativ und rein geschrieben. Sie können einen CSS-Block nicht mit einem anderen CSS-Block verändern.
Ich denke, viele Leute würden erwarten, dass ein rein funktionaler Ansatz für CSS am besten wäre. Sie könnten das mit der Pflege von CSS so rein wie möglich assoziieren, woher Ideen wie CSS Modules stammen. Das Konzept ist, dass, wenn Sie die Stile für das Ding, das Sie ändern, dort einkapseln, wo Sie sie brauchen. Sie beschäftigen sich nur mit dieser Instanz. Keine Nebeneffekte. Ich stimme dem nicht zu. Sie vermeiden auf diese Weise einige Dinge.
- Sie vermeiden Konflikte. Hier bekommt die objektorientierte Programmierung manchmal einen schlechten Ruf.
- Sie vermeiden Benennung. Das Benennen ist schwierig. Sie können das Benennen mit diesem Ansatz vermeiden.
- Sie vermeiden den Umgang mit der Kaskade. Darauf werde ich gleich eingehen.
Für andere Arten der (Nicht-CSS-)Programmierung halten wir Dinge rein und vermeiden globale Geltungsbereiche und sind damit im Reinen! Das muss also überall gelten, richtig?
Hier müssen wir zum Thema das richtige Werkzeug für den Job kommen. Wenn wir Wartung über Schreiben betrachten, hier glänzen andere Ansätze
- Unternehmen, ob groß oder klein, führen mindestens alle 1-2 Jahre Redesigns durch. Wenn Ihre Codebasis groß ist, mit vielen Leuten, und Sie die Zeilenhöhe überall von 1,1rem auf 1,2rem ändern müssen, müssen Sie dann in jedes Modul zurückgehen und diesen Wert ändern? Ein globales oder ein erweitertes Objekt wird hier außergewöhnlich nützlich.
- Die Kaskade kann helfen, wenn Sie sie verstehen und organisieren. Das ist dasselbe wie jedes hochentwickelte Softwaredesign. Sie können sich ansehen, was Sie bauen, und verantwortungsvolle Entscheidungen über Ihren Build und Ihr Design treffen. Sie entscheiden, was auf der obersten Ebene liegen kann und von anderen, kleineren Teilen geerbt werden muss. Dies vermeidet Spaghetti-Code in CSS und hält Ihren Code DRY.
- CSS ist Design. Gutes Design ist von Natur aus erfolgreich, wenn es kohäsiv ist. Eine CSS-Codebasis, die sich an der Design-Infrastruktur ausrichtet, auf der sie aufbaut, ermöglicht saubereren Code mit dem zusätzlichen Vorteil einer besseren Zusammenarbeit. CSS kann auch für Designer selbsterklärend sein: „Moment, wir haben noch einen tertiären Button? Warum?“ Lecks in kohäsiven UI/UX kündigen sich in diesem Modell gut an.
- Das Benennen kann bei der Dokumentation helfen. Dieser Punkt ist etwas kniffliger und ich bin mir nicht sicher, ob er ganz notwendig ist, aber erwähnenswert. Ob Sie BEM, SMACSS/OOCSS oder Atomic mögen, gut gemachtes Benennen kann Ihnen tatsächlich gute Informationen darüber geben, wo eine Klasse verwendet wird und warum.
Die Paradigmen teilen sich Eigenschaften
Wie Sie vielleicht vermuten, sehe ich zwar Wert in anderen Paradigmen, meine Präferenz ist jedoch ein funktionaler Stil. Vor diesem Hintergrund fragen Sie sich vielleicht, warum ich einen objektorientierten Ansatz für CSS wertschätzen würde.
Trotz seines Namens teilt OOCSS Eigenschaften mit der funktionalen Programmierung. Um OOCSS korrekt und wie beabsichtigt zu verwenden, erstellen Sie hauptsächlich Mixins, die ähnlich wie Funktionen mit Parametern (oft mit Standardwerten) in Ihrem System ausgedrückt werden. Sie sind rein und können für mehrere Anwendungen verwendet werden.
Es verwendet immer noch objektorientierte Ansätze. Mit einer sehr intelligenten Architektur, die antizipiert, wie sich Dinge gegenseitig beeinflussen könnten, und sorgfältig überlegt, was vererbt werden sollte. Angesichts der Tatsache, dass CSS im Grunde eine Gruppe von Objekten ist, ergibt dies in einem CSS-Kontext tendenziell mehr Sinn als in anderen Sprachen.
Letztes Jahr habe ich ein Team geleitet, um ein riesiges Front-End-Komponentensystem komplett zu refaktorisieren. Es verwendete eine OOCSS-Architektur. Ich habe selbst den Nutzen dieses Modells gesehen. Designer konnten mich bitten, etwas zu ändern, und wir konnten es schnell auf der ganzen Website aktualisieren sehen. Sie konnten sogar ihre Meinung ändern, ohne zu viel Aufwand. Eine Last-Minute-Anfrage von oben hat unsere Veröffentlichung nicht verzögert. Ich sage definitiv nicht, dass es keine schmerzhaften Punkte gab – aber es war überraschend reibungslos für seine Größenordnung. Das hat dazu geführt, dass ich die Art und Weise, wie ich CSS für andere Anwendungen schreibe, mit ganz neuen Augen betrachte.
Zukunftsorientiert
Leute neigen dazu, diese Dinge gegeneinander auszuspielen
- CSS
- Styling via JavaScript
Ich würde argumentieren, dass Sie auf beide Arten wartungsfreundlich sein oder einen Wartungsalbtraum schaffen können.
Sie können Dinge wie Zeilenhöhen, Schriftarten und Verhaltensweisen absolut verantwortungsvoll in Aphrodite, React-CXS oder CSS Modules handhaben. Ich mag einige dieser Ansätze sehr. Sie können Vererbung handhaben und für einen DRY-eren und wartungsfreundlicheren Ansatz erweitert werden.
Aber auch wenn Sie es können, habe ich persönlich nicht genügend Beispiele von Projekten gesehen, die es tun. (Ich würde gerne Beispiele sehen!)
Meistens sehe ich, dass Leute eine Variable oder zwei für die Markenfarbe herausnehmen und nichts weiter. Ein paar Variablen machen keine verantwortungsvolle Systemarchitektur aus. Ich denke, wir können hier mehr tun, wenn wir über unseren Code nicht in Bezug auf das nachdenken, was leichter zu schreiben ist, sondern was leichter zu ändern ist. Oder besser noch, in Bezug auf das, was für andere leichter zu ändern ist.
Bitte kümmern Sie sich auch um gute Dokumentation! Mit beiden Programmierparadigmen müssen Sie alle Ihre Abhängigkeiten kennen, bevor Sie sie anpassen. Großartige Dokumentation bedeutet auch, dass Sie zielgerichteter in Ihren Entscheidungen sind. Es gibt weniger "Ach ja"-Momente, wenn Sie anderen erklären müssen, was ein Ding ist und wo es verwendet wird.
Die Probleme, die ich in diesem Artikel behandle, sind Probleme der Zusammenarbeit und des Maßstabs. Nicht jedes Unternehmen, jede Website oder sogar jede Webanwendung beschäftigt sich mit diesen Dingen. Dies ist ein Meinungsartikel, der auf Erfahrung beruht. Unterschiedliche Dinge funktionieren für unterschiedliche Projekte.
Meine Hoffnung für diesen Artikel ist es, Entwickler zu ermutigen, vorausschauend zu denken. Wir stecken alle zusammen drin, und das Beste, was wir tun können, ist, voneinander zu lernen. Wenn Sie mir völlig widersprechen, ist das völlig in Ordnung. Meine Hoffnung ist, dass Sie auch dadurch, dass Sie eine Haltung einnehmen, eine Richtung festigen, in die Sie sich mit Wartung als Kernkonzept bewegen.
Danke für die interessante Lektüre. Wartung und insbesondere Dokumentation sind Probleme, die anscheinend immer auftreten. Um etwas von meinem Arbeitsplatz zu teilen: Selbst in einem Team von 3 Entwicklern (und einem Auszubildenden) können ordnungsgemäße Entscheidungsfindung und Dokumentation entscheidend sein.
Eines unserer Teammitglieder ist derzeit im Urlaub, und wenn es darum geht, Dinge zu reparieren, macht der Mangel an Dokumentation unsere Bemühungen ineffizient.
Ich mag die Analogie des Ninjas und des Hausmeisters. Ich bin es leid, dass Arbeitgeber immer sagen, sie suchen nach „Code-Ninjas“.
Couldn’t agree more.
Toller Artikel! Ich bin nicht wirklich überzeugt vom „DRY“-Teil. CSS scheint in jeder einzelnen Situation mit DRY zu kämpfen…
Danke für den Kommentar, ich werde versuchen zu erklären, was ich meine. Nehmen wir an, Sie haben einige Inline-Formularelemente. Ein Label, ein Eingabefeld und ein Button. Um die visuelle Konsistenz zu erhalten, könnten Sie eine Mixin schreiben oder eine Klasse erweitern, die es Ihnen ermöglicht, gleichzeitig Padding, Schriftart und Zeilenhöhe anzuwenden. So schreiben und, schlimmer noch, pflegen Sie diese Stile nicht separat.
Es ist ein kleines Beispiel, ich weiß, aber es drückt hoffentlich aus, warum es großartig sein kann, Stile DRY zu machen, egal wie Sie sie schreiben.
Ich denke tatsächlich, dass CSS einfach wegen der Funktionsweise der Kaskade DRY fördert. Sie funktioniert besser durch Komposition (klassisches OOP-Prinzip).
Sie können Basisstile haben, die das notwendige Aussehen und Gefühl in groben Zügen festlegen, und dann, wenn Ihre Module spezifischer werden, können Sie spezifischere Stile hinzufügen, die sowohl zur Funktionalität als auch zum Erscheinungsbild beitragen.
Auf diese Weise müssen Sie die Basisstile nicht über Module hinweg neu festlegen und können das Überschreiben anderer Module durch spezifische Ebenen der Spezifität vermeiden, was mehr oder weniger der Funktionsweise von OOCSS im Großen und Ganzen entspricht.
OOP in der Praxis ist nur so gut wie sein Design, und das hängt normalerweise davon ab, wie erfahren der oder die Entwickler darin sind, zu verstehen, wie Dinge strukturiert werden sollten. Ich persönlich versuche, meine Stile so gut wie möglich DRY zu machen, aber zu Ihrem Punkt erfordern bestimmte Ausnahmefälle aus Gründen der Fristen hässliche Lösungen.
Dies ist das erste Mal, dass ich jemanden über Wartung sprechen höre, seit Jens Meiert 2004 oder so darüber geschrieben hat. Vielleicht sollten Sie sich mit ihm zusammentun und den Wartbarkeitsleitfaden aktualisieren, den er geschrieben hatte. http://meiert.com/en/blog/20090617/maintainability-guide/ – das ist alles, was wir haben. Ernsthaft.
Oh wow, das ist so cool. Das habe ich noch nie gesehen. Was für eine großartige Ressource, und ja, sie könnte eine kleine Überarbeitung gebrauchen. Danke fürs Posten!
Der Ton dieses Artikels spricht mich an. Obwohl ich im Laufe der Jahre als Webdesigner und Entwickler angestellt war, bestand 70 % oder mehr meiner Rolle darin, den Code anderer, den ich übernommen habe, wiederzuverwenden (und schließlich neu zu schreiben). Ich hatte nie wirklich die Gelegenheit, meine Rolle als eigentlicher Designer oder Entwickler in diesem Sinne zu spielen. Vielmehr war ich eine Art Hausmeister – ein Wartungstechniker. Das hat meine Karrierewünsche leider zurückgehalten, da niemand je nach einem „mittleren“ Designer oder Entwickler (auch bekannt als „Hausmeister“, „Wartungstechniker“) sucht – es sei denn, jemand liest das hier und möchte so etwas, ich suche gerade!
Ich liebe deine Arbeit, Sarah, ich strebe immer hoch, damit ich eines Tages großartige Dinge für echtes Geld produzieren kann.
Danke! Und ja, ich denke, viele von uns sind Wartungstechniker oder haben zumindest einen guten Teil unserer Karriere damit verbracht.
Wie wir CSS schreiben, verändert sich heutzutage viel (zum Guten). Mit mehr komponentenbasiertem Design in JavaScript arbeiten wir daran, CSS anzupassen, um dieselbe Kultur zu teilen. Aber ich habe die Kaskade immer als mächtiges Merkmal von CSS und nicht als Nebeneffekt empfunden (heute streite ich irgendwie darüber… bin mir nicht sicher :)).
Was denken Sie über das Kaskadenmerkmal im Zusammenspiel mit komponentenbasiertem CSS-Design heutzutage?
Hallo Gyandeep,
Ich behandle die Kaskade und komponentenbasierte Stile ab diesem Abschnitt im Artikel: https://css-tricks.de/on-style-maintenance/#article-header-id-3
Wird funktionale Programmierung wirklich wieder zum angesagten Kind? Scheint, als wäre ein „Sei vorsichtig, wen du in der Mittelstufe hässlich nennst“-Meme angebracht.
Mein Problem mit den meisten Argumenten für funktionale Programmierung ist, dass sie davon ausgehen, dass Ihre Objekte dumme Objekte sind und dass Ihre Interaktionen mit ihnen immer blind für den Inhalt sind.
Nehmen Sie Ihre Analogie, dass ich annehme, eine Frucht sei eine Banane, weil mir gesagt wird, es sei eine Frucht. Das IST ein Problem, aber das Problem ist nicht, dass ich eine Frucht bekommen habe, das Problem ist, dass ich Annahmen darüber getroffen habe, was das bedeutet.
Dasselbe gilt für OOP und funktionale Programmierung.
Wenn mir eine (Stück) Frucht gegeben wird, untersuche ich sie. Auch wenn ich das nur sehr kurz tue, verhindert es, dass ich in eine Tomate beiße und hoffe, es sei eine Aprikose. Dasselbe gilt für OOP. Wenn Ihr Objekt in verschiedenen Zuständen sein kann und eine Interaktion je nach Zustand anders wäre, dann machen Sie das Bestätigen dieses Zustands zum Teil der Interaktion.
public class fruit {protected $skin;
public function eat() {
if ($this->skin) {
//Schale entfernen
$this->skin = FALSE;
}
//essen
}
function __construct (boolean $skin) {
$this->skin = $skin;
}
}
Hehe, gerade bemerkt, dass ich Beispiele zwischen Text und Code vertauscht habe.
Interaktion mit Objekten, bei der man annimmt, dass sie sich in einem bestimmten Zustand befinden, ist das Problem. Nicht das Fehlen des Objekts selbst.
Die Frucht-Analogie wäre wahrscheinlich ein gutes Beispiel dafür, wann wir das Erweitern eines Objekts in Betracht ziehen sollten.
Ich halte das OO-Paradigma für ein Versagen. Es klingt theoretisch gut, aber in der Praxis erfordert es, dass man zu viele bewegliche Teile im Auge behält, und wenn sie auf ein Team verteilt sind, vervielfachen sich diese beweglichen Teile exponentiell. An diesem Punkt bin ich davon überzeugt, dass die Lösung darin besteht, das zu tun, was Dave Rupert in einer Folge von CodePen vorgeschlagen hat: eine junk.css-Datei zu haben, in die jeder Designer/Entwickler seine Stile einwirft, und es sollte einen Inhouse-CSS-Hafenmeister geben, der diesen Junk in ein überschaubares/dokumentiertes System mit einem Styleguide umwandelt.
Ich finde es auch lustig, dass es keinen Mangel an schnippischen Tweets über Atomic CSS gab, aber Atomic CSS scheint der Inbegriff von kompositorischem CSS zu sein, während OOCSS der Inbegriff von Vererbung in einer Sprache ist, die mit globalen Variablen erstellt wurde.
Vorerst denke ich, die beste Lösung ist:
Erstellen Sie einen globalen Reset, der generische Typografie enthält.
Teilen Sie Dinge in kleinere Komponentendateien auf. Jake Archibalds Beitrag zu Stylesheet-
<link>-Elementen und HTTP2s Vorliebe für viele kleine Dateien sorgen dafür, dass dies fortschrittlich und schnell geladen wird.Töten Sie Globale und Spezifität, während Sie die Komponierbarkeit mit etwas wie CSS Modules beibehalten.
Stellen Sie ein paar Leute als CSS-Hafenmeister ein, wenn Ihr Unternehmen es sich leisten kann. Wenn nicht, dann ist Ihr CSS wahrscheinlich nicht unmöglich zu verwalten oder kostet Sie sehr viel.
Das „Wähle das richtige Werkzeug für den Job“ beginnt sich wie eine Ausrede anzufühlen. Ich bin auch schuldig, aber wir entwickeln uns nicht weiter, bis wir definitiv sagen können, dass etwas Mist ist. In der realen Welt ist OOCSS nicht ideal. Es hat uns zum kritischen Nachdenken über CSS gebracht, und jetzt haben wir die Ideen/Werkzeuge, um es zu beheben. Lassen Sie uns sie verwenden und OOCSS loslassen.
Es ist total in Ordnung, dass Sie anderer Meinung sind, und der Punkt des Artikels war nicht, jeden dazu zu bringen, OOCSS zu schreiben. Der Punkt war, das Denken über Wartung zu verdeutlichen. Ihr Plan scheint ein guter zu sein, vorausgesetzt, Sie arbeiten bereits mit HTTP2 (es gibt andere Möglichkeiten zu kompilieren, auch wenn Sie das nicht tun). Abgesehen davon bin ich nicht ganz davon überzeugt, dass ich in Ihrem Argument zweckmäßiges Denken über langfristige Wartung gehört habe. Es gibt ein wenig „Lasst sie Kuchen essen“ in Ihrer Verschreibung, die Stile für Ihre Website zu verkaufen, aber gleichzeitig eine starke Meinung darüber, wie sie geschrieben werden sollte.
In Bezug auf „das richtige Werkzeug für den Job wählen“ als Ausrede – ich denke, es besteht die Gefahr, Graustufen in der Entwicklung nicht zu verstehen. Wenn Sie es schon einmal gehört haben, liegt es vielleicht daran, dass die Leute dazu neigen, Dinge zu wiederholen, die sich richtig anfühlen.
Nun, ein Schisma oder ein Plan für Neulinge und alte Hunde, um sich von Feature Creep zu lösen und die Wartbarkeit zu erzwingen.
Ich spiele seit 2001 nach denselben Regeln, ohne ein großes Manifest einzurichten, das ich forcieren würde, wann immer ich die Gelegenheit dazu habe. Mein Plan heißt Semantisches Web.
cu, w0lf.
Ich kann aus Erfahrung berichten, wie wir die Art und Weise, wie wir CSS bei bet365.com schreiben (insbesondere mobile.bet365.com), neu gestaltet haben. Dies führte wiederum dazu, dass ich http://ecss.io schrieb (was wiederum auf der Basis von https://benfrain.com/enduring-css-writing-style-sheets-rapidly-changing-long-lived-projects/ geschrieben wurde).
Eines, das früh offensichtlich wurde, ist, dass die meisten zwar Lippenbekenntnisse zum Nutzerbedarf abgeben, aber wenn man sich auf die Entwicklerergonomie in CSS konzentriert und Werkzeuge zur Durchsetzung von Konsistenz einsetzt (besonders wichtig bei 20+ Entwicklern an einem Projekt), ist das Nettoergebnis Code, der für Entwickler einfacher zu entfernen und nach Bedarf zu ändern ist. Entkopplung ist SEHR wichtig für die Code-Wartung. Deshalb sieht ECSS dies in vielerlei Hinsicht vor.
Atomic ist der „Vater“ von Ansätzen des Single Responsibility Principle. Diese führen typischerweise zu weniger CSS, erfordern aber das Verständnis einer Abstraktion und generell mehr Arbeit in Vorlagen. Dies passt möglicherweise zu Ihren Bedürfnissen oder auch nicht (es passte mir nicht, aber das System hat viel Verdienst).
Für mich ist bei einer großen Codebasis die prinzipielle Wahl, ob man sich für Abstraktion oder Isolation entscheidet. Das sind die beiden Hauptentscheidungen, und darüber hinaus gibt es geringere Entscheidungen.
Abstraktion (z. B. SRP-Ansätze) bietet eine geringere resultierende Dateigröße auf Kosten von (typischerweise) mehr Vorlagenarbeit und der Notwendigkeit für Entwickler, eine fremde Abstraktion zu verstehen.
Isolation bietet die einfache Entfernung ganzer Module und eine direktere Entwicklerergonomie (normalerweise schreibt man CSS wie üblich), führt aber naturgemäß zu mehr CSS – obwohl es nie genug ist, um es als Problem zu betrachten.