Alex Rampp

Ideen für produktive Softwareentwickler

5 Fallen in der Softwareentwicklung

Mit einer sehr eindrucksvollen Keynote hat Dr. Carola Lilienthal das derzeitige Software Architecture Summit in Berlin eröffnet. In ihrem Vortrag nannte sie einige Fallen, in die die Softwareentwicklung immmer wieder gerät. Dieser Artikel beschreibt meine Top 5 Fallen sowie meine persönlichen Erfahrungen dazu.

1. Das Modell-Monopol

Die Entwicklung benutzt Modelle, die der Kunde bzw. der Anwender nicht versteht. Problem dabei ist, dass damit Feedback vom Kunden über das Modell praktisch unmöglich ist. Als Lösungsmöglichkeit wurde Domainstorytelling genannt.

Obwohl ich Lösungen sehr oft zusammen mit Kunden und Anwendern entwickle, kann ich hier vermutlich noch viel lernen. Gerade das Thema
Ubiquitous Language
und Domainstorytelling sind mir zwar bekannt, ich wende sie aber noch zu wenig in Kundenprojekten an. Meist werden Modelle relativ informell entwickelt – dieses Wissen z. B. in ein Glossar zu überführen würde wahrscheinlich nochmal ordentlich Klarheit schaffen.

2. Die Soll Falle

Man Fokusiert sich viel zu schnell darauf, was der SOLL-Zustand sein soll, nachdem die neue Anwendung eingeführt ist. Dabei vergisst man, erst einmal genau zu analysieren, was der IST-Zustand ist.

Dies ist meiner Erfahrung nach eine Falle, in die sowohl Kunden, als auch Entwickler sehr oft geraten. Wenn ich an ein neues Projekt herangehe, versuche ich deshalb immer zuerst zu verstehen, wie der Kunde derzeit arbeitet und wo der wirkliche Bedarf liegt. In den seltensten Fällen möchte der Kunde eine Software, nein er möchte vielmehr eine Lösung für ein Problem (siehe auch Nobody wants to use software).

3. Zu starker Fokus auf Wiederverwendung

Man fokusiert sich beim Design von Komponenten darauf, dass diese Komponente auf jeden Fall wiederverwendet werden kann. Das führt zu generischen Lösungen, die für die eigentliche Problemstellung zu kompliziert sind. Besser ist es, einfache Lösungen, die konkret auf das eine Problem zugeschnitten sind, zu bauen.

Oft hat man im Unternehmen bestimmte Bibliotheken oder sogar ganze Plattformen, die oft benötigten Code bündeln. Problem dabei ist, dass diese meist erweitert/geändert werden müssen um ins aktuelle Projekt zu „passen“. Oft werden diese Bibliotheken von externen Teams betreut, die z. B. andere Releasezyklen haben als das eigene Team. Somit hat man sich durch den Fokus auf Wiederverwendung eine zusätzliche externe Abhängigkeit geschaffen.

4. Fokus auf einzelne Komponenten

Einzelne Komponenten werden Komplett „fertig“ gebaut, während das Gesamtsystem aus dem Blick gerät. Werden die Komponenten dann (relativ spät im Projekt) zusammengefügt ergeben sich oft Probleme durch unterschiedliche Schnittstellen oder inkompatible Konzepte.

Ich sehe hier sogar noch ein weiteres Problem: sehr spätes Anwenderfeedback. Fertigt man eine Komponente nach der anderen, so hat man sehr spät eine erste lauffähige Version und kann sich somit sehr spät Feedback einholen. Die Lösung sind hier Durchstiche oder sog. „Minimum Viable Products“. D. h. man beschränkt sich auf das absolute Minimum an Features die dem Anwender einen Mehrwert bringen, entwickelt die als Durchstich und liefert diese aus. Ich kann aus eigener Erfahrung bestätigen, dass Kunden begeistert sind wenn sie bereits nach 2 Wochen eine erste funktionierende Version mit minimalem Featureset bekommen.

5. Die Expertenfalle

Die Entwickler sehen sich als die wahren Domänenexperten und reden nicht mit dem Anwender. Dies führt dazu dass die Entwickler nicht wissen, wie der Anwender mit ihrer Software arbeitet und die Anwendung am Bedarf vorbei entwickelt wird.

Hier stimme ich voll zu. Anwender benutzen die Software oft ganz anders, als man es sich als Entwickler vorstellt. Deshalb ist es essentiell, von Anfang an Kontakt zum Anwender zu haben. In einem Beratungsprojekt lieferte ich einmal eine Version meiner Software aus und begleitete anschließend einen Anwender durch seinen Arbeitstag. Die meiste Zeit schaute ich ihm einfach über die Schulter um herauszufinden, wie unsere neue Lösung seine Arbeitsprozesse beeinflusst. Dabei stellte sich heraus, dass durch die suboptimale Sortierung der Felder eines Eingeabeformulars immer wieder Fehler passieren – solche Details stehen in keinem Anforderungsdokument.

Fazit

In einem komplexen Projekt lauern Fallen an jeder Ecke. Wichtig ist dabei, regelmäßig zu reflektieren um diese Fallen zu erkennen. Ich denke nicht, dass es sich verhindern lässt in die eine oder andere (unbekannte) Falle zu tappen. Wichtig ist aber, diese Falle im nachhinein zu erkennen und daraus zu lernen sowie seine Erfahrung zu teilen, damit andere nicht auch in diese Falle geraten.

Seek, Sense, Share – 3 Schritte zum persönlichen Wissensmanagement

Wir alle nehmen täglich sehr viele Informationen auf. Wir konsumieren jede Menge Blog-Posts, Tweets, Zeitschriftenartikel, Videos, Bücher usw.. Allerdings habe ich oft das Gefühl, dass dabei zu wenig hängen bleibt. Wichtiges Wissen scheint regelrecht durch die Finger zu rieseln. Einfach ein paar schnelle Notizen zu machen ist auch nur eine bedingte Lösung, da Notizen ohne System schnell zum Chaos führen.

Ein System in dieses Chaos zu bringen versprechen Methoden zum persönlichen Wissensmanagement oder neudeutsch „Personal Knowledge Management“ (PKM). Beim PKM geht es darum, Informationen zu sammeln, zu sortieren und neu zu verknüpfen sodass daraus neue Ideen entstehen. Was in der Theorie gut klingt, ist in der Praxis allerdings gar nicht so leicht. Leider gibt es nicht „das eine Tool“ oder „die eine Methode“, die sicher zum Ziel führt.

Bei meiner Recherche bin ich allerdings auf einen interessanten Vortrag von Harold Jarche über sein PKM Framework namens „Personal Knowledge Mastery“ gestoßen. Das Framework besteht aus drei Säulen – Seek, Sense, Share.

Seek

Zunächst einmal geht es darum, relevante Informationen zu finden. Neben den üblichen Verdächtigen wie Suchmaschinen, soziale Netzwerke, Fachzeitschriften und Bücher nennt Harold Jarche hier explizit persönliche Kontakte. Persönliche Empfehlungen haben bei ihm oft einen höheren Stellenwert, weil sie sozusagen bereits gefiltert sind. Die empfehlende Person hat diese Information scheinbar als für mich relevant erachtet.

Ich habe zum Beispiel nach Möglichkeiten zum Wissensmanagement gesucht. Über Google stieß ich schließlich auf Harold Jarche’s Website, sowie seinen Vortrag „Putting people back in control of their learning“ auf Youtube.

Allgemein setze ich für die Suche nach Informationen meist auf Suchmaschinen (meist Google), Videoplattformen (YouTube, Vimeo), diverse Podcasts, soziale Netzwerke (meist Twitter), Fachzeitschriften, Bücher aber auch Usergroup-Treffen, Fachkonferenzen sowie persönliche Kontakte.

Sense

Nachdem man relevante Informationen gefunden hat, geht es darum diese Informationen in seinen persönlichen Kontext einzuordnen. In dieser Säule wird der eigentliche Mehrwert generiert. Sensemaking heißt vor allem zu experimentieren – versuchen, das Erlernte in seine eigene Welt zu integrieren. Dass nicht alles funktioniert und Fehler gemacht werden ist dabei völlig normal. Wichtig ist hierbei ein geschützter Raum, indem Fehler erlaubt sind ohne dass gleich eine Katastrophe passiert.

Als ich den Video-Vortrag von Harold Jarche gesehen habe, notierte ich die für mich relevanten Punkte in Form einer Sketch-Note (siehe unten). Zudem machte ich mir Gedanken, wie ich eigentlich mit Informationen umgehe und wo die drei Säulen „Sense, Seek, Share“ in meiner täglichen Arbeit auftauchen. Darüber hinaus sprach ich mit ein paar Kollegen über das Thema und merkte so, dass das Thema durchaus Relevanz hat.

Sketchnote über Harold Jarche's Wissensmanagement Framework

Allgemein muss ich sagen, dass ich diesen Part am anspruchsvollsten finde. Hier gibt es leider keine Patentrezepte; ausprobieren, hinfallen, wieder aufstehen lautet die Devise. Im Entwickleralltag gehe ich meist wie folgt vor: Entdecke ich eine neue Technologie die ich spannend finde, so probiere ich diese zuerst in einem Spielprojekt aus. Wir veranstalten in unserer Firma alle paar Wochen einen sogenannten „Exploration Day“ der genau dafür da ist – einfach mal einen Tag mit etwas Neuem zu experimentieren. Komme ich danach zum Schluss, dass diese Technologie uns weiter hilft, so versuche ich sie zunächst in weniger kritischen Bereichen eines realen Projekts einzusetzen.

Share

Ein sehr wichtiger Schritt in Jarche’s Framework ist das Teilen von Wissen. Indem man Erkenntnisse anderen mitteilt, lernt man oft selbst noch vielmehr darüber. Zudem schafft man dadurch persönliche Kontakte, die einem in Zukunft sicherlich nützlich sein können. Durch das Teilen von Wissen entstehen schließlich Netzwerke, von denen man selbst oft mehr zurückbekommt als man jemals investieren könnte.

Im Beispiel habe ich den Video Vortrag zunächst auf Twitter geteilt. Zudem habe ich die Idee in Form eines Kurzvortrages meinem Team in der Arbeit vorgestellt. Darüber hinaus habe darüber diesen Blogartikel geschrieben.

Blogartikel teile ich meist über meinen Twitter-Account. Anstatt einfach den Link zu teilen, versuche ich dem Leser einen kleinen Mehrwert in Form eines Zitats oder meiner persönlichen Meinung zu liefern. Darüber hinaus baue ich gerade diesen Blog auf. Im Berufsalltag teile ich Wissen meist (firmenintern) in Form von Vorträgen oder Workshops.

Fazit

Auch wenn Personal Knowledge Mastery nichts bahnbrechend Neues ist, so trifft Harold Jarche allerings mit den drei Säulen „Seek, Sense, Share“ den Nagel auf den Kopf. Gerade darum geht es beim Wissensmanagement. Vor allem der starke Fokus auf das Teilen von Wissen und den Aufbau von persönlichen Netzwerken ist in einer immer komplexer werdenden Welt wichtig. Es ist als Einzelner einfach nicht mehr möglich, einen Gesamtüberblick über ein Themengebiet zu bekommen.

Falls Du das Wissensmanagement Framework von Harold Jarche genauso spannend findest wie ich, dann fange jetzt mit der Umsetzung an. Teile diesen Artikel zusammen mit einem persönlichen Statement in einem sozialen Netzwerk oder schicken den Link an eine Person, die Deiner Meinung nach von Personal Knowledge Mastery profitieren könnte.

Telemetriedaten erfassen mit dem Visual Studio Mobile Center

Möchte man ohne großen Aufwand Telemetriedaten und Absturzberichte seiner App sammeln, so sollte man sich das Visual Studio Mobile Center näher anschauen. Derzeit noch in der Testphase, soll es laut Microsoft in naher Zukunft HockeyApp und die Xamarin Test Cloud ablösen. Neben den hauseigenen Plattformen Xamarin und UWP werden Java, Swift und React Native unterstützt.

Einrichtung

Zunächst muss man sich unter mobile.azure.com anmelden. Dies ist während der Testphase kostenlos. Mit dem anschließenden Assistenten erstellt man nun eine neue „App“ im Mobile Center.

Um Telemetriedaten zu erfassen nimmt man folgende Anpassungen an der eigenen App (am Beispiel von Android) vor:

1. Dependencies in Gradle File eintragen:

dependencies {
def mobileCenterSdkVersion = '0.11.1'
compile "com.microsoft.azure.mobile:mobile-center-analytics:$latex {mobileCenterSdkVersion}"
compile "com.microsoft.azure.mobile:mobile-center-crashes:${mobileCenterSdkVersion}" }

2. In der onCreate() Methode der Mainactivity den Mobile SDK starten:

MobileCenter.start(getApplication(), "<APP SECRET>",
Analytics.class, Crashes.class);

Dieses Beispiel startet die Module „Analytics“ (erfassen von Telemetriedaten) sowie „Crashes“ (erfassen von Absturzberichten). Den String „<APP SECRET>“ ersetzt man selbstverständlich durch das eigene App Secret (zu finden unter „Getting Started“ in der Mobile Center Web Oberfläche) ersetzen.

Nachdem die oben genannten Anpassungen vorgenommen wurden kann man die App bereits starten. Nach erfolgreichem Start findet an unter „Analytics“ bereits die ersten Ergebnisse:

Telemetrie Übersicht

Eigene Events

Ziel von Telemetriedaten ist es, herauszufinden welche Funktionen die Benutzer am meisten Nutzen. Um dies zu ermöglichen, kann man an beliebigen Stellen im App Code Telemetrie-Events senden:

Analytics.trackEvent("Connecting")
// ...
Analytics.trackEvent("Disconnecting")

Nach dem Ausführen tauchen diese Events unter Analytics/Events auf:

Ansicht eigener Events

Absturzberichte

Um einen Absturz zu provozieren wirft man einfach eine Exception in der eigenen Anwendung (die natürlich nicht behandelt wird). Alternativ kann man auch mit folgender Code-Zeile einen Absturz verursachen:

Crashes.generateTestCrash();

Wechselt man auf der Webanwendung in das Modul „Crashes“ so erhält man eine gruppierte Ansicht, der aufgetretenen Abstürze:

Ansicht der Crash Reports

Zu jedem Absturz erhält man detailierte Auswertungen nach betroffenen Geräten, OS- und App-Versionen sowie Stack Traces:

Ansicht der Crash Reports

Fazit

Um bei einer kleineren App schnell Absturzberichte und Telemetriedaten zu erfassen ist das Visual Studio Mobile Center eine gute Wahl. Man sieht dem ganzen Projekt zwar durchaus an dass es noch sehr jung ist, die bereits implementierten Features funktionierten bei meinem kurzen Test aber durchwegs zuverlässig.

Neben der Datenerfassung gibt es auch noch Module zur Testunterstützung, zum Verteilen von Testversionen und Verteilen von Pushnachrichten. Da diese nicht im Fokus meiner kleinen Untersuchung standen kann ich zu deren Qualität keine Aussage treffen.

Da das Tool sich derzeit noch in einer Testphase befindet, ist es komplett kostenlos. Im Gegenzug dazu hat man natürlich keine garantierte Verfügbarkeit. Gerade bei missionskritischen Apps sollte man dies auf jeden Fall kritisch hinterfagen.

Abschließend muss ich gestehen, dass mir gerade die Einfachheit des Tools sehr gut gefällt. Meist sind Analytics Lösungen zwar sehr mächtig, aber auch kompliziert – was gerade bei kleinen Projekten oft Overkill ist. Dies ist beim Mobile Center richtig gut gelöst. Zudem besitzt bereits die frühe Version eine sehr gute Dokumentation. Den derzeitigen Stand würde ich für kleinere Sideprojekte empfehlen und bei kritischen Apps auf etablierte Lösungen zurückgreifen.

Resümee zur Clean Code Days Konferenz

In der vergangenen Woche war ich zum ersten mal auf den Clean Code Days in München.

Workshoptag

Los ging es am ersten Tag mit einem Workshop zum Thema „Testgetriebene Analyse von Legacy Code“, den ich zusammen mit einem Kollegen hielt. Die Teilnehmer bekamen dabei eine C# Code Basis mit diversen Problemen „vorgesetzt“. Gemeinsam analysierten wir den Code mit Hilfe von Experimenten, die wir als Unit Tests implementierten. Dabei waren natürlich diverse Hürden z. B. durch Abhängigkeiten zu überwinden. Hier zeigten wir den Teilnehmern, wie man sich im sogenannten „Brown Field“ nach und nach ein Sicherheitsnetz schafft, das komplexere Refactorings möglich macht. In einer abschließenden Diskussionsrunde tauschten wir Erfahrungen Tipps & Tricks aus.

Das Feedback der Teilnehmer war durchweg positiv und auch uns machte der Workshop viel Spaß.

Tag 1: Clean Code mit dreihändigen Affen

In seiner Keynote „Von Clean Code zu Clean Software“ stellte Dr. Elmar Jürgens klar, dass sich Qualität nicht nur auf Code beschränkt. Insbesondere die Organisation und Umgebung in der Entwickler arbeiten hat massive Auswirkungen auf die Qualität einer Software. Interessanterweise lassen sich diese Auswirkungen im Code finden, was Jürgens eindrucksvoll an realen Beispielen demonstrierte. Netterweise stehen die durchaus sehenswerten Slides online zu Verfügung.

Remy Loy zeigte anschließend, wie man Clean Code im Bereich funktionale Programmierung erweitern kann. In seinem Vortrag gab er viele Tipps, wie sich die Code Qualität mit funktionalen Erweiterungen verbessern lässt.

Nach einem leckeren Mittagessen kam mein persönlicher Höhepunkt des Tages. Lutz Marquardt und Frank Blendinger präsentierten Clean Code Konzepte in einer ganz neuen Form – als Rollenspiel. Das Publikum schlüpfte dabei in die Rolle eines Programmierers und konnte an entscheidenden Stellen durch Handzeichen den Verlauf der Geschichte beeinflussen. Hierbei begegnete uns ein Ork als unser Chef, ein dreihändiger Affe der sich für Testautomatisierung aussprach sowie ein Staubsauger, der durch einen Bug plötzlich Menschen tötet („Code Reviews können Leben retten!“). Glücklicherweise erschien uns ein Geist namens „Bob“, der uns einen alten Folianten namens „Clean Code“ schenkte. Auch wenn ich dabei wenig neues gelernt habe war dieses Event purer Spaß und macht Lust auf mehr.

In seinem Vortrag „Clean Code for the Front End“ zeigte Mathias Arens, wie moderne Web Frontend Entwicklung funktioniert. Hier konnte ich am Meisten mitnehmen, da ich nicht primär Frontend Entwicklung betreibe, trotzdem aber immer mal wieder damit konfrontiert werde. Mathias zeigte hier viel Erfahrungswissen sowie verbreitete Patterns. Insbesondere die CSS Namenskonvention Block Element Modifier (BEM) erscheint simpel, ist aber sehr mächtig – diese Methodik kommt auf jeden Fall in meinen Werkzeugkasten.

Mike Kaufmann zeigte wie man mit Sonar Cube Kennzahlen zur technischen Schuld berechnen kann. Trotz der durchaus beeindruckenden Präsentation bezweifle ich allerdings, dass man so ein komplexes Thema in ein paar wenigen
Zahlen erfassen kann. Seiner Aussage „Clean Code ist Team Sport“ stimme ich allerdings voll zu.

In einer sehr unterhaltsamen Live Coding Session zeigte uns Roland Golla, wie man mit dem PHP Framework Codeception komplette End-to-End Tests für Webanwendungen implementiert.

Beim anschließenden Feierabendbier erzählte mir Roland über seine Initiative Never Code Alone in der er soziale Einrichtungen mit Software-Entwicklungsprojekten unterstützt und gleichzeitig den Austausch in der Entwicklercommunity fördert.

Tag 2: Clean Code ist mehr als nur Code

Frisch ausgeruht legte ich an diesem Vormittag den Fokus auf Themen, die über das codieren hinausgehen.

Stark war hier die Aussage von Steven Kolbenschlag, dass die Einführung von agilen Vorgehensweisen oft scheitert, wenn die Code Qualität nicht stimmt. Er schloss seinen Vortrag „Wie agil ist ihr Code?“ mit der Aussage, dass die Vorteile des agilen Vorgehens ohne Clean Code Development nicht voll ausgeschöpft werden können.

Francois Lorioux teilte Erfahrungen aus seinem 30-jährigen Berufsleben und zeigte worauf es ankommt, wenn Software über viele Jahr(zehnte) wartbar und erweiterbar sein soll. Neben vielen Tipps und Anekdoten gefiel mir hier der Satz „If you want to kill software, use inheritance“ besonders gut.

Im Vortrag „Erfolgsfaktor Mensch“ zeigten Claudia Simsek-Graf und Christoph Meyer, dass Software letztlich von Menschen gemacht wird und dass Projekte meist an menschlichen Konflikten scheitern statt an technischen Problemen. Die sehr interaktive Session bot viel Raum zum Erfahrungsaustausch und Diskussion. Gerade die Aussage „Clean Code funktioniert nicht im Alleingang“ kann ich aus eigener Erfahrung voll unterschreiben.

Da es ganz ohne Code doch nicht geht hörte ich mir zum Abschluss Gregor Trefs Vortrag „Combinator als funktionales Entwurfsmuster in Java 8“ an. Positiv überraschte mich, dass der Vortrag von Anfang an sehr praxisorientiert war und die oft etwas trockene Theorie der funktionalen Programmierung weggelassen wurde. Am Beispiel Eingabevalidierung zeigte Gregor, wie man mit Hilfe von primitiven Funktionen und Kombinatoren immer komplexere Regeln realisieren kann ohne die Lesbarkeit zu verschlechtern. Neben der Präsentation hat er die Methode auch in einem Blogartikel beschrieben.

Fazit: Gerne wieder

Insgesamt ziehe ich von den Clean Code Days ein sehr positives Fazit. Insbesondere die familiäre Atmosphäre war super – da geht es bei größeren Konferenzen oftmals anonymer zu. Ich hatte viele spannende Gespräche während und lernte viele neue Leute kennen.

Die Räumlichkeiten sowie die Organisation waren toll. Das Essen schmeckte allerdings mal wieder zu gut – was der schlanken Linie nicht gerade förderlich ist ;-).

Ein kleiner Wermutstropfen war lediglich, dass sich relativ viele Vorträge eher am Einsteigerniveau und der bekannten Literatur orientierten. Hier wäre es schön, in Zukunft mehr fortgeschrittene Themen sowie Spezialthemen (z. B. Anwenderberichte über Refactoring in regulierten Bereichen wie Medizintechnik) zu sehen.

Insgesamt waren es drei super Tage in München, die Lust darauf machten sich noch mehr mit dem Thema auseinanderzusetzen. Ich freue mich schon auf eine Wiederholung im nächsten Jahr.

Rückblick auf die Night of Patterns bei den Dodneddern

Am Donnerstag war ich bei der „Night of Patterns“ der .Net User Group in den Räumen der Conplement AG in Nürnberg. Wie zu erwarten ging es um Designpatterns aber auch um Antipatterns. Die beiden Moderatoren Gustin und Alex gestalteten das Thema spannend und kurzweilig.

Einführung

Zunächst definierten die Moderatoren den Begriff „Pattern“ und unterschieden dabei zwischen Architektur-, Designpatterns, Idomen sowie Anti-Patterns. Architektur- und Designpatterns sind Lösungsschablonen für wiederkehrende Probleme. Ein Architekturpattern beschreibt dabei die Struktur einer Anwendung, während ein Designpattern einen bestimmten Teilaspekt beschreibt. Ein gutes Beispiel für Design- und Architekturpatterns sind die berühmten Patterns der Gang of Four. Im Gegensatz zu Patterns beziehen sich Idome auf eine bestimmte Programmiersprache oder Technologie. Ein Beispiel ist das Dispose-Pattern in C#. Ein Antipatten ist dagegen eine Schablone für eine schlechte Lösung. Ziel von Antipatterns ist, Erfahrungen über Fehler auszutauschen.

Patterngallerie

Nach dieser Einführung ging es zum Interaktiven Teil des Abends. Die Teilnehmer wurden dazu aufgefordert, (Anti-)Patterns auf einen Post-It zu schreiben und ans Whiteboard zu hängen

Danach wurden Gruppen gebildet und darauf geachtet, dass der Erfahrungsstand der Mitglieder möglichst unterschiedlich ist. Nun durfte sich jede Gruppe ein (Anti-)Pattern auswählen und in Gruppenarbeit eine Flipchartseite darüber erstellen. Die Struktur war vorgegeben. Neben dem Kontext und einer Beschreibung sollte aufgezeigt werden, welche Konsequenzen der Einsatz des entsprechenden Patterns hat. Zudem sollten sich die Teilnehmer Gedanken machen, wann ein Pattern ungeeignet oder auch ein Antipattern geeignet sein könnte.

Nachdem jedes Team ein Pattern ausgearbeitet hatte, starteten alle Teilnehmer zum „Rundgang durch die Patterngallerie“. Dabei stellte jedes Team sein Pattern innerhalb zwei Minuten vor, anschließend gab es vier Minuten Diskussion. Durch die strikte zeitliche Taktung wurde sichergestellt, dass man sich nicht in Detaildiskussionen verliert.

Nach diesem Rundgang war noch ein wenig Zeit für lockere Diskussionen, Fachsimpeln und Erfahrungsaustausch.

Fazit

Auch wenn das Thema Patterns für mich nicht neu ist konnte ich doch die eine
oder andere Idee mitnehmen. Gerade Diskussionen, wann man ein Anti-Pattern
bewusst doch einsetzen kann sind immer wieder spannend. Zudem hat mir der
Rahmen, wie das Thema rübergebracht wurde sehr gut gefallen. Gerade für ein Community-Event wie bei den Doddneddern genau das richtige.

Ich freue mich schon auf das nächste Treffen am 30. März. Thema ist der ReSharper SDK und wie man damit für den ReSharper Plugins erstellt.

Tipps für eine aussagekräftige Versionshistorie

Wenn ich (z. B. in einem neuen Projekt) auf einer bestehenden Code Basis aufbauen soll, wandert mein Blick meist sehr schnell in die Commit-Historie des Versionskontrollsystems. Ich möchte mir damit einen Überblick verschaffen wann welche Features eingebaut wurden, wer an der Code Basis gearbeitet hat und warum gewisse Änderungen vorgenommen wurden.

Leider findet man immer wieder Historien, die so oder so ähnlich aussehen:

bff324d fix bug
a2fd532 first try
765a88f next try
dd876b2 add feature

Mit solchen Commit Messages lässt sich wenig anfangen. Dieser Artikel gibt einige einfache Tipps, die helfen zu einer aussagekräftigen Historie, die einen echten Mehrwert liefert, zu kommen.

Erwartungen an eine gute Historie

Eine gute Historie erzählt eine Geschichte. Nämlich die Geschichte, wie die Software entstanden ist. Sie gibt einen Überblick wann welche Features eingebaut und wann welche Bugs gefixt wurden. Hat man einen Fehler, so lässt sich mit einer guten Historie nachvollziehen, wann und unter welchen Umständen dieser Fehler entstanden. Dadurch kann man lernen, solche Fehler künftig zu vermeiden. Eine gute Historie enthält zudem Informationen warum gewisse Änderungen vorgenommen wurden. Hier kann man auch auf Tickets in Issue Trackern oder Anforderungen verweisen.

Wie man zu einer aussagekräftigen Historie kommt

Die folgenden Beispiele basieren auf dem Versionskontrollsystem git. Sie lassen sich aber auch auf andere Systeme übertragen.

Verständliche Commit Messages

Eine verständliche Commit Message beantwortet folgende Fragen:

  • Warum ist die Änderung nötig?
  • Was trägt diese Änderung zur zu implementierenden Anforderung aus?
  • Welche Seiteneffekte hat diese Änderung?

Zudem sollte man gewisse Formatierungsregeln einhalten. Die wichtigsten Regeln sind:

  • Separiere die Überschrift vom Textkörper mit einer Leerzeile
  • Limitiere die Überschrift auf 50 Zeichen
  • Zeilenlänge des Textkörpers sollte nicht länger als 72 Zeichen sein

Diese Regeln sind im Git Umfeld etabliert und viele Tools bauen darauf auf. Hält man sich daran, kann jeder die Historie einwandfrei lesen und durchsuchen.

Hier ein Beispiel für eine aussagekräftige und dennoch kurze Commit-Message

tcp: tcp_probe: use spin_lock_bh()
tcp_rcv_established() can now run in process context.
We need to disable BH while acquiring tcp probe spinlock,
or risk a deadlock.
Fixes: 5413d1b ("net: do not block BH while processing socket backlog")
Signed-off-by: Eric Dumazet 
Reported-by: Ricardo Nabinger Sanchez 
Signed-off-by: David S. Miller 

Quelle: Linux Kernel, Commit e70ac17

Atomare Commits

Es gibt Entwickler, die committen erst wenn ein Feature komplett „fertig“ ist. Dadurch entstehen meist sehr große Commits. Diese Commits haben verschiedene Probleme:

  • Sie sind schwer zu lesen, weil sie meist viele verschiedene Änderungen enthalten.
  • Einzelne Änderungen können nicht einzeln referenziert werden (z. B. beim Cherry Picking)
  • Da große Commits viele Änderungen enthalten, müssten auch die Commit Messages entsprechend lang sein. Meist wird aber darauf aus Bequemlichkeit verzichtet, hier alle Änderungen aufzuführen.

Ein atomarer Commit dagegen ist in sich abgeschlossen und liefert einen Mehrwert für die zu lösende Aufgabe. Wird ein Feature in mehreren atomaren Commits entwickelt so ist viel besser nachvollziehbar, wie ein Feature (oder auch ein Bug) entstanden ist. Code Reviews gestalten sich einfache und Techniken wie Cherry Picking oder Bisecting können sinnvoll angewendet werden.

Single Purpose Branches

Fängt man ein neues Feature, Bugfix, Refactoring o.ä. an, so ist es sinnvoll zunächst einen neuen Branch zu erstellen. Das hat den Vorteil, dass man auf einer stabilen Basis arbeitet. Würden alle Entwickler auf dem master-Branch arbeiten, wäre die Wahrscheinlichkeit sich in die „Quere“ zu kommen recht hoch.

Diese Entwicklungsbranches sollten kurzlebig und auf ein Thema beschränkt sein. Dadurch ist die Wahrscheinlichkeit von Merge-Konflikten gering und die neuen Funktionen stehen schnell allen Entwicklern zur Verfügung. Diverse Git Tools zeigen Branches grafisch an, wodurch schön nachvollziehbar ist, was wann entwickelt und gemerged wurde.

History neu schreiben

Gerade bei schwierigen Refactorings arbeite ich oft mit sehr kleinen („sub-atomaren“) Commits. Dabei kann es durchaus vorkommen, dass der Code bei bestimmten Versionsständen nicht einmal kompiliert. Solche Versionen möchte man natürlich nicht veröffentlichen. Sie helfen aber, eine große Aufgabe (z. B. Refactoring einer zentralen Komponente) handhabbar zu machen.

Möchte man die Änderung nun anderen Entwicklern zur Verfügung stellen, ist es ratsam, die Historie „glatt zuziehen“ sodass keine nicht-funktionierenden Versionsstände existieren und oben genannte Punkte eingehalten sind.

Dazu bietet Git mehrere Möglichkeiten:

  • Mit git commit --amend kann man den letzten Commit schnell und einfach ändern
  • Mit git merge --squash <feature branch> fasst man alle commits von „<feature branch>“ zu einem einzigen zusammen.
  • Mit git cherry-pick <commit> kann man einzelne Commits auf einen Branch anwenden.
  • Mit git rebase -i HEAD~3 lassen sich die letzten drei Commits nachbearbeiten. Durch den Parameter -i wird interaktives Rebasing gestartet. Mit Hilfe der folgenden Dialoge lassen sich Commits ändern, zusammenfassen, splitten, neu sortieren oder löschen.

Einen detaillierteren Überblick über die Möglichkeiten, die Historie zu bearbeiten findet man hier.

Fazit

Es ist durchaus sinnvoll der Historie eine gewisse Beachtung zu schenken. Auch wenn zu Projektbeginn meist alles klein und übersichtlich ist, ist es auf lange Sicht sinnvoll sich von Anfang an um eine aussagekräftige Historie zu kümmern. Wie in diesem Artikel gezeigt, reichen dazu ein paar einfache Regeln. Der Software-Archäologe, der sich die Code Basis in zehn Jahren anschaut wird es einem sicher danken.

Worum geht es hier?

Ich bin gerade dabei, einen neuen Blog über Softwareentwicklung zu konzipieren. Du wirst dich sicher fragen, „noch ein weiterer Blog übers programmieren?“ – Jein. Klar geht es in diesem Blog auch ab und an über Programmierthemen, allerdings immer mit einem bestimmten Fokus: Qualität.

Qualität?

Für Softwarequalität gibt es viele Definitionen, vereinfacht lässt sich Softwarequalität allerdings wie folgt definieren:
  • sie funktioniert
  • der Quellcode ist leicht verständlich
  • neue Anforderungen lassen sich einfach und schnell umsetzen
  • ein Benutzer kann die Software intuitiv bedienen

Was ist das Problem?

Unsere Branche hat immer noch ein Qualitätsproblem. Insbesondere im Bereich Wartbarkeit und Code Qualität werden oft Kompromisse zugunsten kurzfristiger Ziele eingegangen. Das mag in manchen Fällen durchaus gerechtfertigt sein, oft fallen einem diese Entscheidungen aber früher oder später auf die Füße. Durch die Bewegung weg von schwerwiegenden Prozessen, hin zu leichtgewichtigen, agilen Entwicklungsmodellen nimmt die Verantwortung des Softwareentwicklers zu. Die Aussage „not my job“ gilt nicht mehr. Jeder Einzelne ist für die Qualität des abgelieferten Produkts verantwortlich. Und hier ist das Problem. Allzu oft habe ich selbst Aussagen wie „das ist fertig, ich muss nur noch Unit-Tests schreiben“ oder „Fertig, aber irgendwann müsste man das mal refaktorieren“, gehört. Aus irgend einem Grund lassen wir Entwickler uns immer wieder dazu hinreisen halbfertige Arbeiten abzuliefern.

Die Lösung?

Eine Einfache Lösung kann ich leider auch nicht bieten. Es liegt auch nicht an fehlenden Methoden und Techniken. Ich denke es ist eher eine Frage der eigenen Einstellung. Hierzu gibt es den Begriff „Software Craftsmanship“. Damit ist gemeint, dass wir Softwareentwickler uns nicht als Industriearbeiter, sondern als Handwerker verstehen sollten. Hast du einen (guten) Handwerker schon einmal „Fertig“ sagen gehört, während die Hälfte noch im Rohbau ist – wir Softwareentwickler machen das jeden Tag. Um die Qualität in unserer Branche zu heben brauchen wir keine schwerwiegenden Prozesse. Stattdessen muss jeder Einzelne dazu bereit sein, das Bestmögliche abzuliefern. Das heißt manchmal auch, Konflikte mit Kunden oder Vorgesetzten einzugehen falls die Qualität zur Disposition steht. Dass das nicht Einfach ist versteht sich von selbst. Ich möchte mit meinem Blog meine Erfahrungen, die ich in den letzten Jahren über diese Thematik gesammelt habe teilen. Dabei wird es teilweise um harte technische Themen, zum Teil auch um die sozialen Aspekte in einem Entwicklerteam gehen. Zudem freue ich mich über spannende Diskussionen mit meinen Lesern.

Ein paar Fragen an Dich

  • Was hältst Du von diesem Konzept?
  • Welche Fragen, Probleme oder Wünsche hast Du im Bezug auf Softwarequalität?
  • Wie wird Qualität in Deinenm Team gelebt, bzw. gibt es überhaupt ein Qualitätsproblem?
 PS: Dieser Artikel ist Teil der ersten Aufgabe der Blog Momentum Challenge 2016

© 2018 Alex Rampp

Theme von Anders NorénHoch ↑