Ein besonders großes Anliegen von uns ist es qualitativ hochwertige Web-Projekte zu liefern. Denn Qualität bedeutet auch immer nachhaltige Skalierbarkeit. Dabei stehen vor allem Design, Funktionalität und User Experience im Vordergrund, aber auch dem Autor soll seine Aufgabe erleichtert und angenehm gemacht werden.
Alles schön und gut, aber wie sieht es im Hintergrund aus, sprich: der Programmierung?
Die meisten Projekte sind sehr dringlich und da bleibt einem oft nichts anderes übrig, als den benötigten Code so gut und sauber wie möglich herunter zu schreiben. Erfüllt auf diese Weise grundsätzlich so gut wie immer seinen Zweck, aber wenn man das selbe Projekt ein paar Wochen später noch einmal öffnet um Änderungen durchzuführen, kann es leicht sein, dass man sich im eigenen Code hinten und vorn nicht mehr auskennt. Oder noch schlimmer: ein anderer Programmierer muss sich mit dem Code beschäftigen 🙂
So muss das natürlich nicht sein – so sollte es auch gar nicht sein. Um den gerade geschilderten Fall zu entschärfen, hilft es schon einmal ungemein allgemeine- und für Projekte spezifische Styleguides zu erstellen, die unter anderem das Aussehen des Programmcodes bestimmen.
Allgemeine Stylinguides/Coding Guidelines
Hier wird definiert wie Dinge zu schreiben sind, wie geklammert wird oder wie Kommentare auszusehen haben und das allgemein gültig für alle Projekte. Dies hat jede Menge Vorteile und wahrt eine gewisse Konsistenz, steigert die Lesbarkeit – erleichtert somit das Arbeiten für alle Beteiligten und so weiter.
Natürlich macht das nur Sinn, wenn man sich an diese Guides hält, was aber nicht so einfach ist. Im Arbeitsstress hat man wahrscheinlich keine Zeit/ Lust sich mit diesen Guidelines auseinanderzusetzen und sich daran zu halten – aber da muss man versuchen sich einfach zusammenzureissen und diszipliniert zu sein. Nach einiger Zeit wendet man die definierten Regeln sowieso automatisch an und das ganze fügt sich in den Alltag ein.
Ok, ich will auch sowas!
Das Erstellen der Guidlines ist schon eine große und aufwändige Aufgabe, denn für unterschiedliche Script- und Programmiersprachen etc. gelten oft unterschiedliche Regeln.
Aber zum Glück sind wir ja nicht die ersten die die Idee zu Guidelines haben und deswegen kann man im Internet jede Menge solcher Dokumente zu verschiedenen Sprachen finden.
Am besten man sucht sich mehrere Dokumente zusammen und pickt sich die Teile heraus die für den eigenen Guide bedeutend sind.
Als nächstes sollte der Guide auch besprochen werden, da andere Developer vielleicht andere Ansichten haben. Diese Zeit der Diskussion kann auch sehr anstrengend und langwierig sein, da jeder Programmierer im Normalfall seinen eigenen Stil entwickelt hat und an diesem meist auch festhalten möchte.
So, die Guidelines stehen jetzt
Jetzt müssen die Regeln nur noch eingehalten werden. Leichter gesagt als getan. Ich denke das dauert einfach eine gewisse Zeit bis alle sich daran halten, die Arbeitsgeschwindigkeit sich wieder einpendelt und sich der Workflow natürlich anfühlt. Es kann gut möglich sein, dass die eigene Arbeitsweise umgestellt werden muss und man in stressigen Situationen dazu verleitet wird auf alte Gewohnheiten zurück zu greifen. Es wäre hier jetzt sehr unrealistisch zu behaupten, dass man einfach diszipliniert bleiben muss, denn wenn etwas schnell erledigt werden soll, dann geht es einfach oft nicht anders. Da darf manchmal schon ein Auge zugedrückt werden. Allerdings sollte man sich davon nicht entmutigen lassen und sobald es wieder weniger stressig zugeht mit den Guidelines weiterarbeiten. Nach einiger Zeit hat man die Regeln sowieso im Blut und kann sie auch in stressigen Situationen beachten.
Projekt-Styleguides
Projektspezifische Styleguides sind sehr nützlich für große Projekte und definieren wie welche Elemente auf der Webseite, oder der Applikation auszusehen haben. Dabei wird noch oft der HTML Schnipsel für dieses Element in den Guide gegeben, was den Vorteil hat, dass man sich diesen ganz einfach herauskopieren kann wenn man ihn benötigt.
Somit bleibt auch hier eine gewisse Konsitenz gewahrt und Frontend-Änderungen stellen auch nach Wochen kein Problem dar – außerdem kann ein solcher Styleguide ziemlich gut aussehen.
Ein weiterer Pluspunkt ist, dass der Styleguide (wenn öffentlich erreichbar) bei den Besuchern der Website einen guten Eindruck hinterlassen kann, da er zeigt, dass hier professionell, sauber und strukturiert gearbeitet wird.
Schlusswort
Styleguides sind einfach super nützlich und sollten in keinem Agentur-Haushalt fehlen!
Linksammlung:
Allgemeine Guides die mir gefallen:
http://www.yellowshoe.com.au/standards/
http://google-styleguide.googlecode.com/svn/trunk/verschiedene Styleguides von Google
http://drupal.org/node/172169 Drupal JavaScript Guidelines
http://pear.php.net/manual/en/standards.php PEAR PHP Guidelines
Einige Beispiele gelungener Projekt- Seitenspezifischer Styleguides:
http://patternprimer.adactio.com/
http://style.rjmetrics.com/styleguide
http://oli.jp/2011/style-guide/
http://paulrobertlloyd.com/about/styleguide/
Mischformen:
https://github.com/styleguide/ Github Styleguide
Du willst mit jemanden über das Thema plaudern?
Einen kostenlosen Termin mit CEO Susanne vereinbaren!UX Snacks Vol.09
That’s a wrap on UX Snacks 2024. Am 7. November hat die vierte und letzte Ausgabe in diesem Jahr stattgefunden und wir nehmen mit diesem Recap ganz viel positive UX-Energie mit ins neue Jahr. Und keine Angst: Schon bald verkünden wir die Daten für 2025.
Jetzt lesenFolge #62 mit Susanne Liechtenecker
In Folge 62 besinnt sich Susanne auf die Anfänge dieses Podcasts und begrüßt keinen Gast, sondern erzählt über das Buch "Jäger, Hirten, Kritiker" von Richard David Precht und warum es sie inspiriert hat.
Jetzt anhören