Grundsätzlich verwende ich ja gerne meinen Moleskine. Für schnelle Notizen unterwegs ist so ein kleines Notizbuch hervorragend und funktioniert gut. Für komplexe Themen, viele Projekte, teilweise voneinander abhängig, ist ein handgeschriebenes Notizbuch nicht gut brauchbar. Genauso wenig sind des Werkzeuge wie OneNote und Co.
„Komplexe Notizen überall verfügbar“ weiterlesenVon WordPress direkt ins Fediverse
Vor einiger Zeit hatte ich erzählt, dass es mich (wieder einmal) ins Fediverse verschlagen hat und ich vielen Social Media-Plattformen den Rücken gekehrt habe. Nach einigen Monaten hat sich für mich dieser Schritt als positiv erwiesen und immer mehr verlagert sich dorthin.
Nun stellte sich auch die Frage, wie ich die Blogposts meiner Blogs einfach ins Fediverse bekomme und siehe da, es gibt es ActivityPub-Plugin für WordPress. Plattformen wie Mastodon, Pleroma, Friendica usw. werden damit unterstützt.
„Von WordPress direkt ins Fediverse“ weiterlesenEnde des Bloggens? Niemals.
In letzter Zeit ist es hier am Blog ruhiger geworden. Das liegt an mehreren Gründen. Es haben sich Themen verschoben und bei der Neuausrichtung dieses Blogs war ich mir lange Zeit nicht sicher, in welche Richtung es gehen soll. Das Thema Fotografie habe ich ja komplett herausgezogen und auf dem Blog ist auch einiges los. Nichts desto trotz bleibt dieses Blog weiter bestehen und auch die Inhalte werden wieder kommen.
„Ende des Bloggens? Niemals.“ weiterlesenSocial Media neu gelebt
Vor einigen Jahren hat es mich schon mal ins Fediverse verschlagen. Damals habe ich den Gedanken dahinter und die Funktionsweise nicht ganz durchschaut. Mittlerweile bin ich wieder im Fediverse vertreten und möchte auch nicht mehr weg. Im Gegenteil. Immer mehr meiner Social Media Aktivitäten verlagere ich dorthin. Aber warum?
„Social Media neu gelebt“ weiterlesenHomeoffice in der digitalen Welt
Corona hat gerade bezüglich Homeoffice sehr viel bewegt. Umso überraschender ist es, dass zahlreiche Unternehmen trotz guter Erfahrungen zurückrudern und Homeoffice wieder einschränken. Womit hat das zu tun und warum dies aus meiner Sicht ein Fehler ist, möchte ich in diesem Beitrag vermitteln. Hierbei spreche ich hautpsächlich für den Bereich der Softwareentwicklung, da ich selbst darin tätig bin und ihn daher gut beurteilen kann.
„Homeoffice in der digitalen Welt“ weiterlesenPython lernen #2: Installation / Tools
Im zweiten Teil der Serie geht es um die Installation. Das notwendige Setup findest du unter https://www.python.org/downloads/. Unterstützt werden alle gängigen Betriebssysteme. Ich installiere Python 3.9.2 für Windows.
„Python lernen #2: Installation / Tools“ weiterlesenPython lernen #1: Der Einstieg
Du möchtest, genauso wie ich, Python lernen? Dann geh diesen Weg gemeinsam mit mir. In dieser Artikelserie werde ich meine Fragen, Antworten und Erkenntnisse mit dir teilen.
Den Anfang macht eine kleine Liste von Informationsquellen, die ich mir im Vorfeld herausgesucht habe und die ich in der weiteren Zeit verwenden werde. Gerne freue ich mich auch über Hinweise auf weitere interessante Webseiten, Bücher und Videos.
Am Ende dieses Artikels findest du eine Liste aller Artikel, die laufend erweitert wird und vorerst nur diesen beinhält – aber hoffentlich kontinuierlich wächst.
„Python lernen #1: Der Einstieg“ weiterlesenGuten Rutsch ins neue Jahr 2021
Zugegeben, 2020 war es sehr ruhig hier am Blog. Der Hauptgrund lag zum Einen in meinem Job, der hauptsächlich organisatorische und architekturelle Aufgaben bereithält und weniger Entwicklungsthemen und zum Zweiten ging meine Freizeit in das Thema Fotografie.
„Guten Rutsch ins neue Jahr 2021“ weiterlesenWarum Aufgabenlisten oft nicht funktionieren
Oft hat man mehr Aufgaben, als man sich merken kann. Damit man diese nicht vergisst, schreibt man sie auf eine Aufgabenliste. Richtig priorisiert und für den passenden Zeitpunkt vorgesehen, wird die Erledigung sichergestellt. Allerdings sind damit auch einige Fallstricke verbunden.
Wie meine eigene Erfahrung und ein Gespräch mit einem Freund gezeigt hat, bedarf der Umgang mit Aufgabenlisten sowohl einer gewissen Disziplin, als auch einer korrekten Verwendung.
„Warum Aufgabenlisten oft nicht funktionieren“ weiterlesenWie gehe ich mit Legacy Code um?
Niemand will mit Legacy Code arbeiten. Die Gründe sind vielfältig und nachvollziehbar, generell ist Legacy Code auch sehr uncool und häufig ist gar nicht klar, wie damit umgegangen werden soll.
Definition Legacy Code
Bei der Definition, was denn Legacy Code überhaupt ist, gibt es viele Meinungen. Oft wird darunter alter Code verstanden, oder Code, der von nicht mehr im Unternehmen befindlichen Entwicklern geschrieben wurde. In manchen Fällen wird auch der Sourcecode einer älteren Version als Legacy Code bezeichnet. Beliebt ist diese Bezeichnung auch für Code, deren Design/Architektur als nicht-optimal empfunden wird.
Ich sehe das viel pragmatischer und stimme diesbezüglich mit Michael C. Feathers überein: Er bringt es in seinem Buch Working Effectively with Legacy Code auf folgenden Punkt:
The main thing that distinguishes legacy code from non-legacy code is tests, or rather a lack of tests. (Michael C. Feathers)
Code ohne automatisierten Tests ist Legacy Code. So einfach. Dabei ist es vollkommen egal, wann der Code geschrieben wurde und wer das getan hat. Kann er nicht automatisiert getestet werden bzw. wird er es nicht, ist es Legacy Code. Punkt.
Legacy Code verringern
Mit obiger Definition ist es doch einfach, Legacy Code zu entfernen. Es gilt einfach Tests zu schreiben. Zahlreiche Bücher beschreiben zudem, wie man denn Legacy Code umbaut und getestet bekommt. Kaum ein Buch beschreibt allerdings, wie dies im “laufenden Betrieb” möglich ist.
Wir müssen Bugs fixen, Features implementieren, wir haben keine Zeit für zusätzlichen Aufwand.
Die Realität sieht dann aber oft anders aus. Häufig macht alter, ungetesteter Code in großen Mengen viele Probleme. Neue Implementierungen an einer Stelle führen zu Fehlern auf einer ganz anderen (natürlich völlig unerwarteten) Stelle. Die Probleme treten allerdings erst beim Kunden auf, wodurch Bugfixes dringend durchgeführt werden müssen, wodurch wiederum andere Arbeit liegen bleibt. So baut sich zusätzlicher Druck auf. Als Ergebnis werden Abkürzungen genommen, also weniger Wert auf ein sinnvolles Design gelegt, die Stabilität leidet. Die Software wird immer anfälliger und alle Beteiligten investieren immer mehr Zeit in “lebenserhaltende Maßnahmen”.
Wie kommt man nun aus dieser Abwärtsspirale heraus, wenn Zeit rar ist?
Ich sage es mal so: Nichts tun und auf zusätzlichen Aufwand herausreden, oder dass ein Testing gar nicht möglich ist, bringt definitiv keine Verbesserung. Im Gegenteil, es wird immer schlimmer. Man muss also Hand anlegen und aktiv an einer Verbesserung arbeiten.
Stete Verbesserung notwendig
Monatelanges Refactoring und das, über die Jahre, versäumte Aufholen von Tests wird (meist) nicht möglich sein. Kaum jemand akzeptiert (finanziell) monatelanges Entwickeln “ohne sichtbaren Output”. Was aber durchaus möglich ist: Für einen Bugfix können Tests geschrieben werden, gegebenenfalls ist auch ein Refactoring kleinerer Codestellen möglich. Das ist vielleicht nicht viel, macht aber eine Codestelle schon sehr viel sicherer.
Lebt das jeder im Team, gibt es über Monate hinweg viele neue Tests. Das Ergebnis ist eine verbesserte Stabilität. Natürlich ist der Anfang schwer und man glaubt nur durch ein großes Refactoring eine Verbesserung herbeiführen zu können. Die Macht von vielen kleinen Verbesserungen darf man nicht unterschätzen.
Nicht einschüchtern lassen
Vielfach werden diese kleinen Refactorings mit Tests nicht durchgeführt, da der Entwickler der Meinung ist, diese Änderung würde nichts bringen. Das mag durchaus so erscheinen, wenn man 100.000e oder gar Millionen Sourcecode-Zeilen vor sich hat. Aber nehmen wir ein kleines Rechenbeispiel:
Jeden Tag können für 200 Zeilen Code Tests geschrieben werden (um das Funktionieren von Bugfixes zu verifizieren). Das Team hat 5 Mitglieder. Dann sprechen wir am Tag von 1000 Zeilen getesteten Code – und das ist recht gering angesetzt. Grob hochgerechnet reden wir dann von 200.000 getesteten Sourcecode-Zeilen nach einem Jahr, oder ca. 13% der Software, wenn das Projekt in Summe 1,5 Millionen Zeilen Code umfasst.
Mehr getesteter Code bedeutet weniger Bugmeldungen == höhere Kundenzufriedenheit und mehr Zeit für wertschöpfende Maßnahmen.
Nun gut, man könnte nun behaupten, dass es ja 7,5 Jahre bedarf, damit die gesamte Software getestet ist. Das ist wohl wahr, vergessen werden darf jedoch nicht, dass für diese getesteten Stellen Fehler sofort aufgedeckt werden können und daher gefixt werden, bevor der fehlerhafte Sourcecode an den Kunden ausgeliefert wird. Wir haben also nach einem Jahr vermutlich um 10% weniger Fehlermeldungen von Kunden und entsprechend weniger Belastung. In dieser verbleibenden Zeit können entweder neue Features entwickelt werden (was dem Unternehmensergebnis direkt zuträglich wäre) oder aber vermehrt in die Stabilität der Software investieren.
Dass darüber auch die Kundenzufriedenheit gesteigert wird (und vermutlich eher weitere Aufträge nach sich zieht), versteht sich von selbst.
Neue Funktionen nicht ohne Tests
Für neue Funktionen sind verpflichtend (sinnvolle) Tests zu schreiben. Daher wird alles Neue schon testbar aufgebaut und die Wahrscheinlichkeit von durchgerutschten Fehlern ist gering. Zu Beginn ist durchaus etwas mehr Zeit für das Schreiben der Tests anzuberaumen. Der notwendige Aufwand verringert sich durch die aufgebaute Erfahrung aber sehr schnell.
Damit das wirklich funktioniert, muss der Aufwand für Tests mitgeschätzt werden. So kommt der Entwickler nicht zusätzlich unter Druck. Druck würde an dieser Stelle nur dazu führen, dass auch für neuen Code keine Tests geschrieben werden, wir also wieder in unser altes Schema verfallen.
Grundvoraussetzung
Entwickler sind am Ende einer langen Wertschöpfungskette. Dadurch ist der Druck besonders hoch. Vor allem, wenn schwerwiegende Probleme auftreten. Generell haben Probleme sehr schnell gelöst zu werden und Features müssen ohnehin sofort implementiert werden.
Damit Schwierigkeiten in der Stabilität, erhöhter Support-Aufwand und damit hohe “unproduktive” Kosten gesetzt werden können, muss die Entwicklung von allen unterstützt werden. Gerne werden für Probleme auch Workarounds gefunden, die den Kunden zwar befriedigen, für die eigene Software allerdings keine Lösung bringen und das Problem nur verschleiern, oder über die Zeit noch schlimmer werden lassen.
Natürlich ist dabei auch Geduld gefragt. Was über Jahre hinweg versäumt wurde, kann nicht in wenigen Tagen oder Wochen behoben werden. Erste Erfolge sind wohl Monate entfernt, aber sie kommen sicher und sind – das ist das Schlimme an dieser Geschichte – nicht sofort ersichtlich. Es sind die Probleme, die nicht mehr auftreten, aber genau deshalb werden sie auch nicht mehr wahrgenommen. Die produktiven Stunden nehmen allerdings zu und daran kann man eine Verbesserung durchaus messen.
Fazit
Legacy Code ist Sourcecode, für den keine automatisierten Tests bestehen. Es bedarf etwas Mut und Wille um Tests zu schreiben, notwendige Umbauten durchzuführen. Auch wenn dies mühsam und kaum schaffbar erscheint, selbst die kleinste Verbesserung ist eine Verbesserung. Viele kleine Verbesserungen werden über die Zeit zu einer großen Verbesserung. Es gilt also, einfach zu starten, so aussichtslos es auch erscheinen mag, denn nur so kann die Software überhaupt besser werden. Nichtstun macht alles schlimmer. Handle jetzt und sorge für Verbesserungen. Jede noch so kleinste Verbesserung hilft. Alle im Unternehmen sitzen im selben Boot.
Update 13.12.2020: Überarbeitung und Ausbesserungen
Erstveröffentlichung: 23.10.2016