Legacy Code – Wie kommt man da raus? 7 Punkte für bessere Software – PHP-Schulung

Wir kämpfen häufig alleine gegen Windmühlen und Legacy Code. Ständig wachsende Anforderungen bei immer geringerer Wertschätzung und immer geringeren Budgets gibt es leider immer häufiger. Zudem gibt es den ständig wachsenden Berg an Legacy Code, der auch nur von uns selbst gesehen und nicht wirklich ernst genommen wird. Immer schwerer fällt jeder Tritt in diesem Morast. Immer mehr Hilfskonstrukte werden für die Aktualisierungen der unterschiedlichen Umgebungen gebraucht. Oft gibt es nur noch lokal und live. Alle anderen Staging-Umgebungen wurden aufgrund der hohen zeitlichen Aufwände längst abgeschafft oder gar nicht erst eingerichtet. Git ist der einzige Lichtblick, um überhaupt noch einmal bei einem Bug einen Rollback machen zu können.

“Agil heißt nach vorne” lautet die Devise. Und: “Wird schon irgendwie, muss ja weitergehen.” Die Folgen sind verheerend: Keinen Bock mehr. Scrollen durch endlos lange Files. Der Kopf macht zu. Selbstschutz. Daraus kann ein Nervenzusammenbruch folgen. Ist mir selbst Ende 2017 passiert und hat mich bis heute im Griff. Macht euch bitte nicht kaputt! Und vor allem nicht für Sachen, die nicht wertgeschätzt werden.

Arbeitsalltag eines Webdevelopers – Bug Fixing in Legacy Code

Als Webdeveloper ist man das letzte Glied in einer Produktionskette, in der unnötig viel Zeit verbrannt wird. Der Programmierer, der es live bringt und mit seinen magischen Fähigkeiten Konzepte und Layouts in klickbare und funktionierende Applikationen verwandelt, soll hier auch noch die Zeitverluste rausholen und alle Anforderungen aus einem einfachen Layout Bild erkennen. Denn dafür wird man ja schließlich eingestellt und auch gut bezahlt. Und weil eh keiner draufguckt, ist es am Ende auch völlig egal, wie das Ziel erreicht wird. Deshalb nehmen Entwickler Umwege in Kauf und verzichten auf Abkürzungen. Das Ergebnis ist ihnen zunehmend egal und ganz leidenschaftsloser Legacy Code.

Abkürzungen hingegen erfordern höhere Kenntnisse und mehr Leidenschaft. Umgangssprachlich sagt man: “Der Code wurde hingerotzt”. Holen wir uns alles im Support wieder – für viele, vor allem größere Agenturen mit größeren Kunden ist das leider auch ein Geschäftsmodell. Am Ende schluckt der Kunde ja eh alles. Hier wird leider keine zweite externe Meinung in Form von Sachverstand eingeholt. Die Folgen reichen von enorm hohen Betriebskosten bis hin zu – natürlich – scheiternden Projekten. Denn mehr Code bedeutet mehr Fehler. Und Bugs kosten viel Geld.

Statt an guter Software zu arbeiten, treten viele Webdeveloper im Legacy Code auf der Stelle und wissen das auch. Sie werden die Firma verlassen, weil es ihnen keinen Spaß mehr macht, dort zu arbeiten. Dabei ist es ihnen egal, dass es in einer neuen Firma vermutlich nicht anders ist. Denn erstens werden ihnen in Stellenausschreibungen und Vorstellungsgesprächen falsche Versprechungen gemacht und zweitens stirbt die Hoffnung bekanntlich zuletzt. Im Zweifel gibt es beim neuen Arbeitgeber wenigstens mehr Geld.

Coder müssen coden und nicht “busy spielen”

Legacy Code – PHP-Schulung Roland Golla

Webdeveloper sitzen zusammen an sogenannten Entwickler-Inseln. Das können eigene Räume, aber auch Bereiche in Großraumbüros sein. Dabei tragen sie Kopfhörer und versuchen irgendwie, in einen kreativen Arbeitsprozess – den “Tunnel” – zu kommen. Grund für die Sitzinsel ist übrigens der stete Austausch der Entwickler untereinander: das gegenseitige Helfen und der ständige Know-how-Transfer. Zumindest in der Theorie.

Die Praxis sieht das meist komplett anders aus. “Das ist gerade echt schlecht, da musst du erstmal alleine durch. Du schaffst das schon.” Kurzum, es gibt dort keinen Austausch, der so intensiv ist, dass man permanent nebeneinander sitzen müsste. Zumal Entwicklern ein solcher Austausch häufig unangenehm ist, da sich niemand gerne in die Karten schauen lässt. Erst recht nicht, wenn man schlimmen Code noch schlimmer machen muss. Fakt ist: In Legacy-Code-Applikationen wird erstaunlich wenig Code verändert und bewegt. Deshalb wird nur wenig darüber gesprochen. Und alles andere ist ohnehin von oben ausdrücklich untersagt. Schließlich betrifft das jeweilige Ticket nur den Bug, und genau das wird (mit zu wenig Geld) bezahlt. Refactoring und Software-Qualität sind also kein Thema – dafür gibt es erstmal kein Budget. Und auch nicht für automatisierte Tests und Deployments. Hier wird auf eine Entscheidung von oben gewartet, die von nicht Technikern, sondern von BWLern getroffen wird. Als Folge werden die Desktops Orte sichtbarer Resignation. Die Entwickler hängen immer frustrierter auf Facebook und YouTube ab und verlieren zusehends die Lust an ihrer Arbeit – woraus dann oftmals Krankmeldungen und Kündigungen resultieren. Daher ist es wichtig, dass Webdeveloper sich konstruktiv zurückziehen können und Budgets für Verbesserungen bekommen. Dafür sollte es eigene Räume und/oder die Möglichkeit geben, per Homeoffice zu arbeiten.

Core Domain finden und Legacy Code entwirren

Legacy Code Core Domain finden

Statt sich auf ein einziges Feature mit tatsächlichem Mehrwert für die Nutzer zu konzentrieren und dieses aktiv im Markt anzubieten, werden Seiten in Deutschland mit einer Fülle von Standard-Features überfrachtet. Aus Lösungen für Slider, News, Medien, Newsletter, SEO-Landingpages lässt sich später jedoch kein USP ableiten. All solche Features wurden irgendwann einmal umgesetzt, werden aber eventuell gar nicht mehr benutzt – oder wurden es noch nie. So gibt es dann beispielsweise einen schicken Download-Bereich, der hochauflösende Bilder für die Presse zur Verfügung stellt. Doch nachdem es die Bilder von der Büroeröffnung doch nicht in die lokale Presse geschafft haben und es auch in Zukunft nicht schaffen werden, verwaist der Bereich. Solche Bilder müssen stattdessen vor allem in die sozialen Medien, die heute immer besser bedient werden wollen.

Trotzdem bleibt die Frage nach dem eigenen USP: Warum kauft ein User hier ein und was ist das wichtigste Produkt? Domain Driven Design ist eine Art der Software-Entwicklung, bei der sich der Kunde aktiv in den Prozess einbringen kann. Das bedeutet nicht, dass Marketing-Mitarbeiter plötzlich alle programmieren und Quellcode lesen können. Domain Driven Design stellt sicher, dass alle Beteiligten dieselbe Sprache sprechen und sich verstehen. Das Ganze hat sich in der Praxis bewährt, und es wurden viele erfolgreiche Projekte damit realisiert. Klar ist hierbei: Kunden und User müssen bei technischen Entscheidungsprozessen viel besser involviert werden, so dass ihre Anforderungen berücksichtigt werden können.

Standard-Features dagegen sind zwar nett – aber falsch und halbherzig genutzt, verursachen sie nur unnötige Kosten und sind Ballast. Davon muss man sich erstmal trennen und priorisieren. Statt eines Mediacenters gewährleisten direkte Ansprechpartner und Kontaktmöglichkeiten eine weitaus persönlichere und effektivere Kommunikation. Hier muss sich die IT besser verkaufen und einbringen, damit der Erfolg von Seiten und Projekten in allen Maßnahmen berücksichtigt wird. Webdesign und Features kommen nicht aus einem Teilelager, sondern Kommunikationsdesign muss entwickelt, erprobt und weiterentwickelt werden.

Die Route macht’s – Strategie gegen Legacy Code

Chaos ist entstanden und über Jahre gewachsen. Viele Zeilen und unnötiger, vielleicht seit Jahren nicht gesehener Code stellen eine große Herausforderung dar. Diese lässt sich nicht alleine bewältigen, wenn man sowieso schon das Tagesgeschäft schultern muss. Allen Beteiligten ist daher schon sehr lange klar, dass die Ausgangsbasis zu schlecht und zu alt ist, um mit einem Refactoring ans Ziel zu kommen. Also geht es um einen Rewrite. Neueste Framework-Version, neueste PHP-Version, neueste Komponenten und natürlich Docker mit automatisierten Tests. Dem gegenüber steht immer der Sparfuchs. Da sauberer Code in einem neuen System aber viel effektiver ist, mehr Spaß bei der Arbeit macht und das Arbeitsklima somit insgesamt gesteigert wird, rentiert sich der Mut zu dieser Entscheidung recht schnell.

Allerdings sollte man von einer parallelen Entwicklung absehen. Das klappt niemals gut, und der Browser Netscape ist vielleicht eines der populären Opfer einer solchen Fehlentscheidung. Man kann jedoch mit Lazy Loading einzelne Routen auf neuen Code bringen und als Default Fallback die Legacy-Code-Applikation laden. So können Teile in einer Applikation während ihres Betriebes ausgetauscht werden. Ein weiterer Mehrwert besteht darin, dass jederzeit einfach im Routing zurückgeschaltet werden kann. So kann man im laufenden Projekt eine neue Applikation schrittweise implementieren. Nur Mut, der Weg ist richtig und gut!

Ohne externe Expertise geht es nicht

Wie konnte es eigentlich so weit kommen und wer hat das Chaos und die ganzen Bugs eigentlich geschrieben? Gute Entwickler schreiben immer guten Code und schlechte Entwickler immer schlechten. Eine Verwechslung ist hier ausgeschlossen. Wer jahrelang auf der Stelle tritt, als Senior über Jahre an dem Projekt arbeitet und es immer weiter vor die Wand fährt, der muss dann auch mal in die Verantwortung genommen werden. An diesem Punkt hat sich aber leider eine ganz natürliche Betriebsblindheit entwickelt. Würde es derselbe Entwickler, wenn er es neu schreiben könnte, genauso machen?

Herausforderungen in der Software-Entwicklung sind sich in unterschiedlichen Projekten ähnlich und kehren immer wieder. Jemand mit breiter Projekterfahrung in unterschiedlichen Teams kann hier einen entscheidenden Vorteil bringen. Selbstverständlich sind auch Erfahrungen in aktuellen Technologien von klarem Vorteil. Häufig werden die Vorteile von modernen Bibliotheken auf der Ebene der Business-Logik nicht richtig eingesetzt. An dieser Stelle muss Know-how von außen eingekauft werden. Ein gezieltes Coaching und Consulting reicht aber nicht aus. Das muss regelmäßig erfolgen. Zudem gilt es, dabei auch das Fundament neu zu implementieren – hierzu müssen Programmierstunden eingekauft werden. Doch auf einer guten und sauberen Basis können neue Features dann auch viel einfacher und modularer implementiert werden. Außerdem sollte man von Anfang an auf eine hohe und gute Testabdeckung setzen. Damit ist es möglich, sich sicher im Code zu bewegen. Dann lässt sich auch “mal eben” etwas verbessern, ohne dass man Angst haben muss, gleich irgendetwas zu zerstören. Mit dieser Sicherheit kann ein Programmierer eine viel höhere Geschwindigkeit aufnehmen. Dieses Know-how aufzubauen, erfordert neben Zeit auch viel Passion und Leidenschaft. Dafür lohnt sich die Investition.

Keine Zeit – Kein Geld – Keine Zukunft

PHP Training Continuous Integration

Wir haben alle keine Zeit und arbeiten unter großer Anstrengung, und neben den bestehenden Baustellen kommen jeden Tag neue dazu. Der gesamte Prozess vom Kundenanruf bis zur Live-Stellung wird so gar nicht mehr wahrgenommen und optimiert. Die ständig wachsende technische Schuld in Form von Legacy Code ist eine Bedrohung für alle Existenzen, die damit verbunden sind – und schlimmstenfalls scheitert daran sogar gleich das gesamte Geschäftsmodell. Hier muss man mit viel Selbstdisziplin, Motivation und Ehrgeiz vereint am Turnaround arbeiten. Und zwar abteilungsübergreifend und nicht gegeneinander. Flickschusterei ist an dieser Stelle nicht zielführend. Die Entwickler dürfen sich dabei aber nicht immer als Opfer sehen und müssen auch mal Verantwortung übernehmen und verantwortungsbewusst arbeiten. Dazu gehört die persönliche Weiterbildung ebenso wie die Verbesserung des eigenen Codes und eine höhere Testabdeckung. Unter den gegebenen Umständen darf darunter jedoch nicht der gesamte laufende Betrieb leiden.

Daher mein Rat an euch Entwickler: Codet einfach besser, denn das zahlt sich irgendwann aus. Das mit den falschen arbeitgeberseitigen Versprechen steht zwar auf einem anderen Blatt, aber es kann ja wohl nicht sein, dass der gesamte Druck und das ganze Chaos immer mit unverminderter Wucht an die Programmierer weitergegeben wird. Schließlich bedeutet Programmierer zu sein, dass man in einem kreativen technischen Umfeld arbeitet und individuelle passende Lösungen für eine aktuelle Herausforderung findet. “Mach’s einfach nur irgendwie fertig” ist hier die völlig falsche Vorgabe, denn eben dadurch werden Programmierer verheizt. Das darf heute nicht mehr passieren! Immerhin haben wir einen attraktiven Arbeitsmarkt mit guten Arbeitgebern, die es verstanden haben, tatsächlich ihre Hausaufgaben zu machen – statt immer nur “gute Vorsätze für irgendwann einmal” zu formulieren.

Es bleibt dabei: Schlechte Software macht krank und traurig. Wenn ein Unternehmen nicht in der Lage ist, Mindestanforderungen wie automatisierte Tests und Deployments abzudecken, wird gute Arbeit nicht geschätzt. Das bringt keinen weiter und begünstigt Legacy Code. Beratungsresistenz müssen wir nicht heilen – wir haben keinen pädagogischen Auftrag. Wir wollen “nur” gut entwickeln und arbeiten. Das ist durchaus möglich und nötig.

Fazit zum Turnaround in IT-Projekten

Wer lange mit hoher Geschwindigkeit in die falsche Richtung fährt, muss einen Turnaround machen und einen Umweg in Form von finanziellen Investitionen in Kauf nehmen. Immer mehr Projekte schaffen das. Der Wettbewerbsvorteil liegt dabei auf der Hand. Aber der Vorteil ist nicht von Dauer, da sich zeitgemäße Software-Entwicklung zunehmend in Unternehmen verschiedener Größenordnungen etabliert. Der Aufwand hält sich in Zeiten von skalierbaren virtuellen Maschinen immer mehr in Grenzen. Es werden keine Dateien, sondern Systeme deployed. Wer hier nicht mitgeht, handelt unternehmerisch und menschlich falsch. Ein Turnaround ist ein langer Prozess mit viel Selbstdisziplin. Es ist vor allem aber auch eine Teamaufgabe. Der Markt ist jedenfalls da. So hat der Montag wieder eine Chance und ist kein Tag mehr, den man am liebsten streichen würde.