GWT Checkliste – Dinge, über die man vor dem Coden nachdenken sollte.

By | 21. November 2012

Die Hälfte meiner Kunden engagieren mich, weil sie keine oder wenig Erfahrung in der Entwicklung von GWT Anwendungen haben. Ich habe gute Erfahrungen damit gemacht, mit ihnen die Punkte der nachfolgenden Liste durchzugehen, bevor wir mit der Entwicklung beginnen. Sie haben direkten Einfluss auf die Komplexität und die Architektur der Anwendung und sollten deshalb von Anfang an berücksichtigt werden.

  • Tests und TDD Ja, es gibt Kunden, die keine Unit-Tests haben wollen. Sie denken, das kostet Zeit. Das Gegenteil ist aber der Fall – Tests sparen Zeit und viel, sehr viel Geld. Warum? Hier einige Argumente:
    • Die Entwicklung ohne Tests verläuft exponentiell. d.H. zu Beginn benötige ich vielleicht 4h für eine Funktion, nach zwei Monaten würde die selbe Funktion mich 6h kosten und nach drei vielleicht schon 10h. Das liegt an den entstehenden Seiteneffekten und an dem zunehmend größeren Refactoring Aufwand, weil sich auch der alte Code mit der Zeit ändert. Die Anwendung wird ständig umgebaut und es geht Funktionalität verloren, ob man will oder nicht. Nur eine gute Testabdeckung ist in der Lage neuentstandene Fehler zu erkennen.
    • Tests bewirken eine lose Kopplung des Systems. Beim schreiben eines Tests merke ich schnell, ob der Aufwand, den ich in das Mocken von Abhängigkeiten stecke angemessen oder zu groß ist. Ist er zu groß, ist die zu testende Klasse zu komplex. Trenne ich die Klasse dann in zwei Teile und verbinde sie über ein Interface, entsteht eine lose Architektur – also genau das Ziel.
    • Tests geben Zufriedenheit und Sicherheit. Kein Scherz. Die Arbeit an einem zwei Wochen jungen System macht wesentlich mehr Spass, als an einem drei Jahre alten Dinosaurier, den Dutzend möchtegern-Entwickler vergewaltigt haben. Das liegt an der Angst „etwas kaputt zu machen“. Eine gute Testabdeckung gibt jedem Entwickler die Sicherheit die von ihm verursachten Seiteneffekte beim nächste Build zu entdecken.
    • Der Lebenszyklus einer Software wird drastisch verlängert. Eine automatisch getestete Anwendung ist ein Qualitätsprodukt und kann weiterentwickelt werden, ohne das die Qualität darunter leidet.

    Deshalb mein Ratschlag: Den Kunden und alle Projektmitglieder von der Notwendigkeit der Tests überzeugen. Der Kunde profitiert davon am meisten, auch wenn er es zu Beginn nicht sieht. Und noch ein Ratschlag: Die erste Klasse einer neuen Funktion sollte die Testklasse sein. Hier eine kleine Erleichterung.

    Gestern haben wir übrigens den 500-sten Unit Test in meinem aktuellen Projekt gefeiert. Bis Weihnachten werden wir sicher die 750 Tests Marke knacken.

  • CI und Nightly Build Also ich mags ganz gern. Ob Jenkins oder TeamCity ist ganz egal. Nach jedem Commit wird das Projekt gebaut und Compile- und Testfehler werden sofort bemerkt. Alle Projektmitglieder werden darüber per Mail informiert und der Verursacher kann reagieren. An dieser Stelle wäre vielleicht ein „Hut der Schande“ angebracht, den derjenige tragen muss, der den Build kaputt gemacht hat? 😉 Der Nightly Build ist ebenso wertvoll, denn der aktuelle Entwicklungsstand kann auf ein Testsystem deployed werden und steht als Diskussionsgrundlage oder zum Präsentationszweck zur Verfügung.
  • Dependency Injection ist der Punkt, auf den ich bestehen würde. Ohne DI ist der Aufbau von unterschiedlichen Umgebungen nicht möglich. Die Anwendung wird unweigerlich zu einem Monolithen – einem schlecht zu wartenden System und letztlich zu einer Qual für jeden Entwickler. Mir fällt ehrlich gesagt auch kein vernünftiger Grund ein, der gegen DI spricht. Deshalb meine Empfehlung: Von Anfang an Gin.
  • Mehrsprachigkeit Ein Punkt, der viel Disziplin und Konsequenz verlangt. Mal eben ein Titel hier, eine Fehlermeldung da, ein Ich ändere das später… dort und schon entsteht viel unnötige Nacharbeit. Soll die Anwendung mehrsprachig sein, dann müssen gleich zu Beginn die Gleise Richtung i18n gelegt werden. Und das betrifft nicht nur den Client. Ich würde folgende Fragen stellen:
    • Soll der Sprachwechsel im „Betrieb“ erfolgen können. Also ohne den Browser neu zu laden?
    • Sind Geldbeträge im Spiel und auch Währungen?
    • Wie werden die Übersetzungen verwaltet? Statisch oder in z.B. einer Datenbank?
    • Liefert der Server bereits übersetzte Texte oder Meldungen? (Wenn ja, würde ich keinen Aufwand darauf verschwenden eine clientseitige Lösung umzusetzen, sondern alles serverseitig machen. Sonst gibt es doppelten Pflegeaufwand.)
  • Undo / Redo Ja, gibt es auch in Webanwendungen 🙂 Das einfachste Pattern für die Umsetzung ist das Command-Pattern. Ein kleiner Tipp von mir: Der EventBus eignet sich hervorragend zur Umsetzung der Undo/Redo Funktion. Denn wenn man näher hinsieht, setzt der EventBus das Command-Pattern bereits um.
  • RPC Eine GWT Anwendung ohne Serverkommunikation kenne ich persönlich nicht (höchstens ein Login-Formular). Mein Favorit ist der GWT RPC Mechanismus mit dem von Ray Ryan aus der Google I/O 2009 vorgeschlagenen Command-Pattern. Die Wahl, ob GWT RPC, GWT JSON, RequestFactory oder einfach nur REST mittels eines HTTP Clients, sollte zu Beginn gefällt werden. Es kommt aufs Backend an.
  • Modularität Ein Thema, über das sich viele GWT Entwickler den Kopf zerbrechen, und das ist auch gut so. Eine GWT Anwendung, die nicht in Module geteilt ist, endet mit Schmerz. Und zwar für den Entwickler. Der DEV-Mode wird immer langsamer, die Compile-Zeiten immer länger und das Kompilat KB für KB immer größer. Eine gute Strategie ist es die Anwendung sowohl auf Projektebene als auch logisch zu trennen. Eine Art Plugin – Mechanismus erlaubt es einzelne Module unabhängig von anderen Entwicklern und anderen Modulen zu entwickeln. Eine gemeinsame Grundlage – ein Framework – bestehend aus DI, MVP, EventBus, RPC, i18n, Settings und Resources bildet die Schnittstelle zwischen den Modulen und erlaubt beliebige Erweiterbarkeit. Hinzu kommt, dass jedes Plugin/Modul mittels Code Splitting nachgeladen werden kann und der Anwender nicht Megabytes von unnötigem Code laden muss.
  • SEO Support Ein ungeheuer spannendes Thema für alle Möchtegern Marketing-Agenturen. Ein langweiliges Thema für einen GWT Entwickler. Aber eins, über das man sich Gedanken machen sollte. So sieht das Markup einer klassischen GWT Anwendung aus:
    <html>
      <body>
        <div id="content"></div>
      </body>
    </html>

    Und das ist zufälligerweise auch der Inhalt, den der Google Bot zu sehen bekommt. Denn GWT erzeugt das Markup dynamisch und wird von Suchmaschinen nicht erfasst. Was tun also, wenn SEO eine Anforderung ist? Ganz einfach: Sparsamer mit den Widgets umgehen und das Markup zu möglichst großen Teilen initial vom Server erzeugen lassen. An dieser Stelle empfehle ich GwtQuery, weil sich damit am einfachsten eine Brücke zwischen Markup und GWT herstellen lässt.

  • Web / Desktop Das Look & Feel der GWT Anwendung gibt der Kunde vor. Sollte es eher einer Desktopanwendung gleichen, macht der Einsatz einer Bibliotheken wie GXT einfach Sinn. Wenn es eher eine klassische Webanwendung werden soll, dann wäre der Einsatz von plain GWT evtl. sinnvoller.
  • Mobile – ja oder nein Ein Smartphone wird ganz anders Bedient als ein PC. Dementsprechend funktioniert nicht alles, was man sich für den PC Browser ausgedacht hat auf meinem iPhone. Insbesondere Touch-Gesten, Doppelklicks und Bereiche mit Scrollbars bereiten dem Anwender Schwierigkeiten. Bei einer kleineren Anwendung macht ein Hybridbetrieb bei dem einzelne Widget mittels Deffered Binding ausgetauscht werden evtl. Sinn. Bei einer Größeren Anwendung wäre eine komplett eigene Oberfläche für ein Smartphone vielleicht sinnvoller.
  • Authentication / Security Was darf der Anwender und was nicht? Sieht die UI für alle Benutzergruppen identisch aus? Wie funktioniert die Authentifizierung? Vielleicht SSO? Graut man Menu-Einträge, die nicht ausgeführt werden dürfen, aus oder versteckt man sie ganz? Um die Security herum gibt es viel Klärungsbedarf und auch hier entscheidet der Einzelfall.

So, ich hoffe dem einen oder anderen GWT-Entwickler einige Anregungen gegeben zu haben. Aber mal davon abgesehen, würde mich auch über andere Erfahrungen und ergänzende Beiträge freuen. Kommentare sind also willkommen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.