Warum wir (AutoScout24) uns entschieden haben, unsere Android-App komplett neu zu schreiben. Ein Erfahrungsbericht aus meinem Arbeits-Alltag als Android Developer bei AutoScout24.
Bei der Enwicklung unserer neuesten Version 3.0.x haben wir uns entschieden das Fundament unserer Android-Applikation auszutauschen und den kompletten Code neu schreiben. In den folgenden Punkten möchte ich euch erleutern, welche Gedanken uns dazu getrieben haben und was wir uns erwarten davon.
Optik war enorm veraltet und träge Ansichtenwechsel.
Es ist kein Geheimnis, dass die Version 2.x.x im Jahre 2014 keinen Schönheitspreis mehr gewinnen könnte. Im Jahre 2013 ebenfalls nicht und im Zweifel hätte sie es auch im Jahre 2012 nicht geschafft…
Dies war der Grund, warum wir (fernab der Entscheidung dass wir den Code neu aufsetzen) uns für ein Komplett-Facelifting der Applikation entschieden haben. Unser Focus lag dabei im flüssigen Ablauf von Animationen, flüssigem Scrollen von Listen, einer übersichtlichen Detail-Seite und einer angenehmen und tollen User-Experience mit Pattern die sich auch bei anderen Applikationen bewehrt haben (zB. die Erreichbarkeit der Left-Hand über die ganze
App hinweg).
Zugleich haben wir aber auch drauf geachtet, nicht zu fancy zu werden. Manche Animationen und Transitions sind zwar schön, lassen die Souveränität ein wenig leiden.
Weiterentwicklungszeit drastisch minimiert.
Wer “alten” Code kennt, der weiss dass es keinen Spaß macht ihn zu lesen, zu verstehen und vor allem… ihn zu verändern!
Noch problematischer ist es, wenn die Applikation nicht nur von einem Team entwickelt wurde, das vielleicht während den Jahren gewachsen ist. Wenn Agenturen ihre Hände im Spiel hatten, wenn kopierter Code aus anderen alten Quellen benutzt wurde oder wenn Entwickler an der App gearbeitet haben, die ins kalte Wasser geworfen wurden, ist das Produkt ein einzig wirrer Haufen Code, der nur sehr schlecht wartbar ist.
Eine oder mehrere dieser Phänomene betraf auch unsere Version 2 und 1 der AutoScout24 Android Applikation. So bestand die Applikation aus einem Wirrwarr, der nur sehr schwer verständlich und leserlich war. Allein das Verändern einer Klasse, die eigentlich abgekoppelt sein sollte vom Rest, zog einen Ratenschwanz mit sich der nicht mehr vertretbar war.
Durch das neu-schreiben der App, haben wir versucht alles negative Aspekte der vorherigen Version zu negieren, in dem wir es besser machen ;) Wir haben sehr drauf geachtet, Pattern zu benutzen die Best-Practice sind und einen strukturierten und geordneten Code fördern. Natürich haben wir auch sehr viel Wert darauf gelegt, dass die einzelnen Module und Klassen von einander abgekoppelt sind, so das man agil und schnell auf Veränderungen in der Gesamtstruktur reagieren kann.
Komponentengetriebene Entwicklung bei AS24-Android!
Zusätzlich haben wir uns auch einem Geschenk unserer Entwickler-Generation angenommen, nämlich der Möglichkeit komponengetrieben zu entwickeln. Dank der umfangreichen und sehr intensiv getriebenen Open-Source-Community bei Android, konnten wir mithilfe von leistungsstarken und guten Frameworks unseren Code verstärken und verbessern. Vor
allem die Frameworks von Sqaure respektive Jake Wharton – okhttp, Picasso, Dagger, Butterknife – waren uns eine große Hilfe. Verstärkend kam noch das Otto-Framework hinzu, dass ich hier präsentiert habe. Hier eine kurze und schnelle Übersicht, was die Frameworks aus macht.
Okhttp: Integration des Protokolls SPDY in die Verbindungsaufbau mit unserem Server und die Parallelisierung der http-Aufrufe.
Dagger: Die Möglichkeit Manager und weitere Klassen zu injecten anstatt sie als Singleton zu definieren und den Code dadurch testbarer zu machen.
Butterknife: Man kann mithilfe von Butterknife View-Elemente in Fragments, Activities und Adapter injecten und sieso an einer zentralen Stelle im oberen Bereich der jeweiligen Klasse bündeln. Leserlichkeit steigt und die Fehleranfälligkeit sinkt.
Picasso: Ein Luxus-Framework, das das Asynchrone herunterladen und anzeigen von Bildern für einen übernimmt. Es basiert auf okhttp und bietet der App noch zusätzlichen “Drive”, sobald Bilder ins Spiel kommen (zB in der Ergebnis-Liste oder in einer Detail-Ansicht).
Testing war das O und das A!
Da wir zusätzlich zum Start des Neuschreibens der App auch eine sehr starke Testumgebung aufgebaut haben, mit viel Automatisierung und Continuous Integration, hatten wir von der ersten Klasse an direkt das Ziel auch eine hohe Testabdeckung zu erreichen. Dies relaisierten wir, indem wir zu jeder geschriebenen Klasse, direkt auch die entsprechende Test-Klasse geschrieben haben.
Das dies zeitaufwendig ist, war uns klar. Dennoch haben wir uns dafür entschieden, da Tests sich in jeder Form auszahlen. Eventuell entfalten Tests nicht gleich beim ersten Release ihre volle Stärke, aber spätestens nach ein/zwei Update-Iterationen werden nach Code-Änderungen einige Tests failen… was auch gut so ist! Nur so kann man darauf reagieren und unerwartetes Verhalten abfangen. Die Qualität unserer App steigt, unsere Sorgen als Entwickler sinken da wir eine Art Backup haben und die Stimmung steigt dementsprechend :)
Wie das Testing bei uns exakt funktioniert, werde ich in einem späteren Post noch exakter zeigen, aber hier schon mal ein kleiner Einblick:
– Mit Hilfe von Spoon, können wir Unit- und Click-Tests auf allen angeschlossenene Geräten (bei uns circa 10) synchron durchführen. Im Vergleich zur Variante, in der die Tests auf 10 Geräten nacheinander durchgeführt werden, reduziert sich die Gesamtzeit um 45 Minuten, bei einer Durchschnitts-Testzeit vn 5 Minuten.
– Wir ziehen Kopien von unserem Code (Github) und stellen uns selber Anfragen mit den Code-Änderungen und fragen nach Erlaubnis (uns selber), dass diese Änderungen in den Code mit aufgenommen werden, ganz nach dem im Open-Source bekannten Fork-Pullrequest-Verfahren. Sobald so eine Anfrage hineinflattert, bekommen wir Emails zugesandt und können uns die Änderungen des Kollegen anschauen. Wenn alles i.O. ist vom Code her und die Tests auf unserem Server durchgelaufen sind, drücken wir auf einen Button und der Code wird automatisch in unseren Hauptcode integriert. Dadurch reduzieren wir die Möglichkeit das Schwachsinn eingecheckt wird um ein vielfaches.
Zusätzlich, haben wir einen QA-Kollegen, der sehr gute Arbeit macht im manuellen Testing und viele viele Probleme und Fehler aufgedeckt hat, während und auch nach der Entwicklungszeit. Dies war für die saubere Entwicklung der App eine sehr große Hilfe!
Teamwork rocks!
Anders als vor einem Jahr, besteht unser Team nun aus 4 komplett unterschiedlichen Entwicklern. Jeder hat seine
Vorteile und Stärken, die er dem Team (im positiven) aufdrückt. Wir sind kommunikativ, was das Teambuilding enorm
fördert, haben Spaß und lachen viel und lernen von einander. Vor allem das gegenseitige Lernen, sehe ich persönlich
als ein großes Plus bei uns.
Zusätzlich wirkt sich die enge Zusammenarbeit mit Product Owner und Teamlead positiv auf unser Wohlbefinden als
Entwickler aus. Wir tragen Verantwortung für “unser” Produkt, synchronisieren unsere Meinungen aber auch nach oben,
die uns dann auch dementsprechend das Vertrauen geben und uns walten lassen. Dieses gegebene Vertrauen stärkt uns
und erlaubt es auch, durch innovative Ideen coole neue Sachen in das Produkt einfließen zu lassen.
Dennoch liegt unser Fokus darin, eine Applikation auf die Beine zu stellen, die Customer-Value-getrieben ist aber
auch die internen Vorgaben erfüllt. Sobald wir zu verspielt werden, werden wir auch wieder in die richtige Bahn
gelenkt, von unserem PO, der die letztendliche Verntworung für die Applikation trägt.
