Die CMS-Falle: Vorboten und Gegenmaßnahmen
Kommentare

Dass Content Management Systeme (CMS) groß, umfangreich und kompliziert sind, hat ja bekanntermaßen sein Gutes: Es hat tausende Jobs geschaffen. (Auch meinen.) Doch viele Mannstunden der Beschäftigung

Dass Content Management Systeme (CMS) groß, umfangreich und kompliziert sind, hat ja bekanntermaßen sein Gutes: Es hat tausende Jobs geschaffen. (Auch meinen.) Doch viele Mannstunden der Beschäftigung gehen ins Land, in denen Entwickler Probleme mit ihnen komplizierter machen als sie in Wirklichkeit sind. Der russische Back-End-Entwickler Maxim Chernyk arbeitet seit einigen Jahren in der Branche (wenn auch in Ruby), und er hat dabei schon einige Projekte miterlebt, deren Minimum Viable Product sich in ein unwartbares Ungetüm verwandelt hat. In seinem jüngsten Blog-Post erläutert er die CMS-Falle näher, in die wir alle viel zu schnell geraten können. Seine Beobachtungen lassen sich zu folgenden Punkten kondensieren:

  • Die CMS-Falle ist erreicht, wenn die Entwicklung des CMS der Entwicklung des Inhaltes im Wege steht.
  • Anfängliche Entscheidungen werden später zu Einschränkungen.
  • Es wird immer schwieriger, das wachsende Framework mit neuen Features auszustatten.
  • In neuen Features gehts es immer mehr darum, sie irgendwie im bestehenden Code unterzubringen, als darum, sie gut auszugestalten.
  • Schlechte Architektur ist auch bei 100 Prozent Testabdeckung qualvoll.
  • Bei schlechter Architektur neigt man zu Workarounds, die in Pfusch ausarten (sh. „The Drupal Syndrome„).

Anschließend gibt Chernyk Tipps, wie man ein komplexes System (d.h. ein System mit nicht nachvollziehbar vielen vernetzten Knoten) weniger komplex macht:

  • Die Zahl der Knoten lässt sich reduzieren, indem man weniger Dinge zur Laufzeit ausführt. (Keep it static, stupid)
  • Komplizierte, konkrete Logik sollte in Klassen ausgelagert werden (Strategie Entwurfsmuster)

Besonders wenn man darauf achtet, möglichst oft auf statische Seiten und Elemente zu setzen, reduziert sich die Zahl der beweglichen Teile in der Architektur drastisch. Genau diese sind es nämlich, die im späteren Verlauf des Projektes immer schwerer zu überblicken sind. Code schreiben ist leicht; ihn hingegen zu lesen ist schon viel schwieriger. Und wenn Ihr nicht eines Tages von eurem früheren Selbst böse überrascht werden wollt, könnte euch vielleicht der eine oder andere der obigen Hinweise in Zukunft helfen.

Aufmacherbild: Booby trap von Shutterstock / Urheberrecht: M R

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -