BECS: Die entsetzlich aufgeblähte Quellcode Lösung

Last modified: February 9, 2011

Christian Heilmann führt in Seven Reasons for Code Bloating sieben Gründe an, warum “Bloated Embarrassing Code Solutions” (BECS – entsetzlich aufgeblähte Quellcode Lösungen) entstehen können.

Die Gründe sind bekannt, warum BECS entsteht:

zu wenig Zeit für ein Projekt
die falschen Werkzeuge verwendet, die überflüssigen Code verwenden
die eigene Arbeit zu wenig oder gar nicht dokumentiert
ohne Konzept ein Projekt beginnen
zu wenig Erfahrung
man will alles mit dem Quellcode abdecken, anstatt sich zu spezialisieren
auf Aufbau und Nutzen der Webseite hat man nur bedingt Einfluss letztendlich, dadurch versucht man zuviel abzusichern.

Eine gute Dokumentation braucht Zeit

Grundsätzlich stimme ich den Punkten zu, einige Einschränkungen sehe ich in den Beispielen, die Heilmann zur Unterstützung anführt:
Natürlich wäre eine gute und hinreichende Dokumentation der eigenen Arbeit wunderbar und wünschenswert, aber wie Heilmann bereits im ersten Punkt aufführt, fehlt meisthin die Zeit. Die Zeit reicht gerade mal hin, um ein Projekt einigermassen fristgerecht zu beenden und eventuell zu optimieren. Aber für eine Dokumentation der wesentlichen Punkte bleibt nur zwischendurch und knapp Zeit.

Leute lesen keinen Dokumentationen, machen ihren eigenen Stiefel ;)

Dem ist unumwunden zuzustimmen. Da kann man noch so sehr eine offizielle Dokumentation führen, Richtlinien und standardkonforme Lösungen vermitteln, die bleiben auf der Strecke, weil letztlich jeder das macht, was seinem Leisten am ehesten entspricht. Traurig, aber leider auch zu wahr. :-)

Zu wenig Erfahrung, zu viele Leute an einem Projekt

Heilmann reduziert meiner Ansicht nach hier zu stark alles auf den Erfahrungsaspekt. Die CSS-Beispiele, die er anführt, zeigen, dass er davon ausgeht, man sitzt immer alleine an einem Projekt. Aber: der Normalfall in einer Agentur ist, dass man eben nicht alleine an einem Projekt sitzt, viele Leute am Quellcode rumschrauben und somit das Gesamte aufblähen.
Natürlich ist dem zuzustimmen, dass es generell besser ist, allgemeine Dinge in der CSS-Datei vorher zu deklarieren und alles auf eindeutige CSS-IDs hinzuleiten und so wenig wie möglich speziell auf einzelne HTML-Elemente zu legen.

Dem widerspricht jedoch häufig der Alltag, im dem die von Heilmann beschworene CSS-Kaskadierungsfähigkeit (Vererbung von CSS) ein richtiger Fallstrick werden kann. Dinge in CSS ganz oben an erster Stelle zu definieren, kann dann bei grossen und von vielen bearbeiteten Projekten ungleich problematisch werden, weil nicht jeder alles im Blick hat und nicht jeder die Erfahrung mit der CSS Vererbung hat. Dann ist man mehr damit beschäftigt, die Probleme und Quellcode-Ebenen der Kollegen zu debuggen (Problemsuche), als mit seinen eigenen Projektteilen.
Freilich sollte man die Herleitung in CSS so schlank wir möglich halten und allgemeine, von allen geteilte Werte möglichst früh und zentral definieren.
Ein Problem bei Heilmanns Beispiel, alles an CSS-IDs zu binden, ist auch, dass man CSS-IDs streng genommen auch für eine sematische Strukturierung verwenden sollte und nicht beliebig auf der Seite verteilen, nur weil man sie braucht.

2 thoughts on “BECS: Die entsetzlich aufgeblähte Quellcode Lösung”

Chris Heilmann on 20.05.07 at 21:27 said:

Wow. Danke fuer die Uebersetzung. Zu Ihren Kritikpunkten: vieles davon wird klarer und wurde auch erwaehnt, allerdings dauert es noch etwas bis der Podcast rauskommt.
Das es keine Zeit zur Dokumentation gibt ist allerdings ein Zeichen das die Zeitvorgaben nicht genau ueberlegt wurden, oder eben kurz gehalten wurden um das Projekt zu gewinnen.
Zum CSS Thema: Mir egal wie viele Leute daran arbeiten, einer der nicht weiss worum es geht ist genug, um schlechten code zu erstellen. Einer der letzten Punkte in der Praesentation ist das wir unseren code nicht von jedem im Projekt bearbeiten lassen sollten sondern eben nur denen die es koennen. IDs haben keinerlei semantischen Wert, das ist ein Irrtum, sie sind allerdings sehr sehr wichtig um dem CSS eine Struktur zu geben, und daher ist die Kaskadierung ein sehr gutes Werkzeug um CSS klein zu halten. Als ich damals visit-britain.com machte hatten die 8 originalen Templates 3 IDs und jedes Modul der Seite eine eigene ID. Das CSS war 400 Zeilen. Zwei Jahre spaeter sind es mehrere tausend Zeilen und IDs nach Wahl, genau dem sollten wir versuchen vorzubeugen.
Derzeit bin ich dabei Yahoo! Answers neu zu planen und werde die Ideen auch veroeffentlichen wenn sie sich bewaehrt haben.
Das groesste Problem ist das es wirklich keine einzige gute Erklaerung gibt, wie man CSS auf einem Seiten-Level und fuer grose projekte plant und lesbar haelt. Zum groessten Teil auch deswegen, weil eben zu viele Koeche im HTML Brei rummachen.
Reply
serner on 21.05.07 at 22:25 said:

oh schön, dachte ich mir schon, dass eine stichwortartige Präsentation natürlich einen breiten Interpretationsspielraum zuläßt. Dann bin ich gespannt auf die Podcast-Version. :-)
Ja – das mit den fehlenden Zeiträumen ist schwer in den Griff zu kriegen. Aber eine Dokumentation der Arbeit wäre natürlich immer zwingend notwendig. Ich bemühe mich ja meisthin darum.
@CSS und unzureichender Code: Das ist ein optimaler Ansatz, nur jene an Projekte ranzulassen, die das Projekt auch in Ihrem Sinn bearbeiten können. Grundsätzlich sieht das ja auch so aus in der Praxis. ;-)
@IDs keinen semantischen Wert: Soweit ich mich erinnere, ich krame gerade meine Quellen durch und werde dazu auch einen Beitrag basteln, haben IDs durchaus einen “semantischen” Wert, insofern sie die Struktur einer Webseite als Eckpfeiler abbilden sollen. Es wird ja auch immer wieder empfohlen diese Struktur mit semantischen Namen zu versehen. Es gibt ja mittlerweile sowas wie Standards (header, navigation, content, footer etc..). Und über den Vorteil einer ID für die Kaskadierung brauchen wir ja nicht reden. :-)
Ich denke, ich habe Sie dahingehend etwas missverstanden, dass Sie nicht empfehlen (wie ich aus ihrem Beispiel visit-britain.com entnehme), eine wahllose ID-Verwendung zu betreiben, sondern sie eben modular auf- und auszubauen.
Ja – sie haben durchaus recht. Es ist schwierig, gute Beispiele und Erläuterungen für große und langfristige Projekte zu finden. Ich lese mich halt durch diverse Artikel und habe über die Jahre meine Erfahrung in diese Metaarbeit einfliessen lassen. Aber für mich immer noch ein sehr spannendes und unabgeschlossenes Thema.
Deswegen habe ich Ihren Vortrag sehr interessiert aufgenommen. :-)
Reply

sprungmarker

Suche

Artikel