Prinzipien der Webentwicklung: Entwickeln Sie für was ist, nicht was sein könnte

Artikel vom 7. Juni 2011. ISSN 1614-3124, #44. Schwerpunkt: Webentwicklung (RSS-Feed für alle Themen).

Dieser und viele andere Beiträge sind auch als hübsches, wohlerzogenes E-Book erhältlich: On Web Development.

Webentwickler profitieren in jedem Projekt davon, sich auf das zu konzentrieren, was ist, nicht auf das, was sein könnte. Um Missverständnisse zu vermeiden, diese Konzentration schließt jedoch auch ein, was sein wird.

Der Grund für dieses Prinzip ist, dass Sie kein Hellseher sind. Das heißt, Sie mögen annehmen, dass Ihre Website in naher Zukunft ein 12-Spalten-Raster verwenden wird, wenn die Entwürfe vor Ihren Augen trotzdem 8 sagen, sind es 8, nicht 12. Wenn Ihre Website nur einen Seitentypen kennt, benötigen Sie nicht zwei. Und wenn sie von keinerlei Tabellen Gebrauch macht, müssen Sie auch keine Tabellen stylen. Zur Sicherheit: zu ignorieren, was sein könnte, bedeutet nicht, zu ignorieren, was sein wird, und das heißt, dass wenn Ihnen Ihr Designer versichert, dass die nächste Iteration 12 Spalten vorsieht, es nicht sonderlich smart ist, eine solche Wahrscheinlichkeit zu ignorieren.

Was passiert, wenn Sie sich nicht darauf konzentrieren, was ist, ist, dass Sie Kosten in die Höhe treiben, Komplexität erhöhen und eventuell von Beginn an »technische Schulden« mit sich herumschleppen. Das heißt, all die Zusatzfunktionen, die Sie in Ihren Website-Prototypen eingebaut haben, kosten Geld durch die Arbeit an ihnen allein, dann durch Dokumentation, aber auch durch die impliziten zusätzlichen Wartungskosten, wenn erstmal Zeit vergangen ist. Dafür zu entwickeln, was sein könnte, macht es schwieriger (nebenbei: schwieriger heißt nicht unbedingt schwierig – diese Unterscheidung ist wichtig), mit Ihrem Projekt zu arbeiten. Allzu gerne, auch wenn wir Wartungskosten bereits angeschnitten haben, sind Sie gezwungen, Sachen mit sich herumzutragen, die überhaupt nicht verwendet werden und damit nur im Weg stehen, wenn an dem gearbeitet werden soll, was von Bedeutung ist.

Ein Auge auf das zu haben, was ist, spiegelt Empirismus wider, und Empirismus füttert auch die Schneider-Metapher, die ich ehemals im Zusammenhang mit Frameworks aufgebracht habe: Sie wollen nach der bestmöglichen Lösung streben, und das bedeutet, diese Lösung auf tatsächliche Bedürfnisse zuzuschneidern. Ein guter Schneider wird Ihnen ein bisschen Freiraum für Ihren Bauchansatz geben – und so wollen Sie Ihrem Design und Code ein wenig Raum zum Wachsen und Schrumpfen schenken –, aber er wird Ihnen kein Zelt überreichen, nur für den Fall, dass Sie mal 50 Kilo zunehmen.

Wer meine Arbeit verfolgt hat mich dies bereits sagen hören: Webentwicklung besteht zu einem guten Teil daraus, mit Wahrscheinlichkeiten umzugehen. Sie wissen, dass ich in der Vergangenheit andere Prinzipien der Webentwicklung behandelt habe – siehe Artikelübersicht oder die populärsten Beiträge in meinem englischsprachigen Blog –, und dass es wahrscheinlich ist, dass ich diese Prinzipien auch zukünftig thematisieren werde.

Nach langer Abstinenz aus Europa und ebenso langer Publikationspause: Deutsche Sprache, schwere Sprache.

Über mich

Ich bin Jens, und ich bin ein Engineering Lead und Autor. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin W3C und WHATWG verbunden und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Mit meinem aktuellen Umzug nach Spanien bin ich offen für eine neue Führungsposition im Frontend-Bereich. Beachte und empfehle gerne meinen Lebenslauf oder mein LinkedIn-Profil.

Ich experimentiere gerne, nicht nur in der Webentwicklung, sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen.