© Liashko/Shutterstock.com
Entwickler Magazin
Die Legacy-Code-Falle

Da müssen wir später noch mal ran …

Neben den vielen großen und langjährigen Legacy-Code-Applikationen gibt es immer mehr Neuentwicklungen. Neue Extensions und Module bieten neue Möglichkeiten und somit Chancen für Kunden und Unternehmen. Allerdings gibt es ein großes Problem, das weiterhin Legacy-Code produziert: der Entwickler. In diesem Artikel möchte ich verschiedene Aspekte der Entwicklung beleuchten und an gute Softwarequalität und Arbeit appellieren.

Roland Golla


„Das ist totaler Crap, ich würde am liebsten alles neu schreiben“, stöhnte der Azubi neben mir am Tisch, als er sich mit einer TYPO3-Extension eines aktuellen Projekts auseinandersetzen musste. Den Wunsch hört man immer häufiger. Und es gibt ja auch tatsächlich immer wieder Neuentwicklungen – egal, ob das nun Modul, Extension oder Plug-in genannt wird. Die Chancen, sich hier zu beweisen und nach den eigenen Vorstellungen arbeiten zu können, sind verlockend. Hoch motiviert geht es also ans Werk. In Zeiten von Composer kann auch eine große Bandbreite externer Libraries ohne große Aufwände zusätzlich implementiert werden. Für jeden Anwendungsfall die passende technologische Lösung, so geht Web-Development heute. Aber der Schein trügt, denn wo am Anfang der Entwicklung nichts ist, da gibt es vor allem eins: sehr viel zu tun.

Aller Anfang ist schwer

Neue Technologien und Versionen brauchen viel Erfahrung und sind bei Weitem keine Selbstläufer. Wenn aber noch keine konkreten Erfahrungen vorliegen, muss man sich diese sehr schnell erarbeiten. Hier kämpfen Entwickler also nicht nur gegen die Projektsanduhr, sondern auch gegen die eigene Ungeduld. Wurde vielleicht doch auf das falsche Pferd gesetzt …? Bis auf Weiteres ist man jedenfalls gezwungen, eine lauffähige Version mithilfe von Google und Stackoverflow zusammenzubasteln – also genau das zu tun, was man eigentlich nicht wollte.

Dies machen Entwickler bis zu einem bestimmten Punkt, auf den sie aufbauen können, denn trotz allem lässt sich auch so ein gutes Ergebnis erzielen, das jede Menge Potenzial bietet. Allerdings ist das ein Ergebnis mit Abstrichen, und zu den negativen Folgen dieser experimentellen Phase zählen Userstatements, die nicht mehr genutzt werden, Variablen- und Methodennamen, die nicht mehr treffen, und Klassen, die zu groß geworden sind. Zwar ist ersichtlich, dass gearbeitet wurde und wird – das allein ist jedoch kein Zeichen für Softwarequalität. Klar ist: Skalierbarkeit und Wartbarkeit sind zwei zentrale Ziele guter Softwareentwicklung, die nachträglich nicht implementiert werden können.

Der Plan – das Big Picture

Kleine, große und auch Teilprojekte brauchen Struktur. Wie viele Files und wie viele Zeilen Code benötige ich dafür? Allerdings sehe ich immer wieder Entwickler, die einfach drauflos coden. So entsteht Chaos. Trial-und-Error-Coder kann man diese Sorte meist junger Entwickler nennen. Im Laufe des Projekts wird es neben dem strukturellen Chaos der Files auch im Quellcode zunehmend chaot...

Entwickler Magazin
Die Legacy-Code-Falle

Da müssen wir später noch mal ran …

Neben den vielen großen und langjährigen Legacy-Code-Applikationen gibt es immer mehr Neuentwicklungen. Neue Extensions und Module bieten neue Möglichkeiten und somit Chancen für Kunden und Unternehmen. Allerdings gibt es ein großes Problem, das weiterhin Legacy-Code produziert: der Entwickler. In diesem Artikel möchte ich verschiedene Aspekte der Entwicklung beleuchten und an gute Softwarequalität und Arbeit appellieren.

Roland Golla


„Das ist totaler Crap, ich würde am liebsten alles neu schreiben“, stöhnte der Azubi neben mir am Tisch, als er sich mit einer TYPO3-Extension eines aktuellen Projekts auseinandersetzen musste. Den Wunsch hört man immer häufiger. Und es gibt ja auch tatsächlich immer wieder Neuentwicklungen – egal, ob das nun Modul, Extension oder Plug-in genannt wird. Die Chancen, sich hier zu beweisen und nach den eigenen Vorstellungen arbeiten zu können, sind verlockend. Hoch motiviert geht es also ans Werk. In Zeiten von Composer kann auch eine große Bandbreite externer Libraries ohne große Aufwände zusätzlich implementiert werden. Für jeden Anwendungsfall die passende technologische Lösung, so geht Web-Development heute. Aber der Schein trügt, denn wo am Anfang der Entwicklung nichts ist, da gibt es vor allem eins: sehr viel zu tun.

Aller Anfang ist schwer

Neue Technologien und Versionen brauchen viel Erfahrung und sind bei Weitem keine Selbstläufer. Wenn aber noch keine konkreten Erfahrungen vorliegen, muss man sich diese sehr schnell erarbeiten. Hier kämpfen Entwickler also nicht nur gegen die Projektsanduhr, sondern auch gegen die eigene Ungeduld. Wurde vielleicht doch auf das falsche Pferd gesetzt …? Bis auf Weiteres ist man jedenfalls gezwungen, eine lauffähige Version mithilfe von Google und Stackoverflow zusammenzubasteln – also genau das zu tun, was man eigentlich nicht wollte.

Dies machen Entwickler bis zu einem bestimmten Punkt, auf den sie aufbauen können, denn trotz allem lässt sich auch so ein gutes Ergebnis erzielen, das jede Menge Potenzial bietet. Allerdings ist das ein Ergebnis mit Abstrichen, und zu den negativen Folgen dieser experimentellen Phase zählen Userstatements, die nicht mehr genutzt werden, Variablen- und Methodennamen, die nicht mehr treffen, und Klassen, die zu groß geworden sind. Zwar ist ersichtlich, dass gearbeitet wurde und wird – das allein ist jedoch kein Zeichen für Softwarequalität. Klar ist: Skalierbarkeit und Wartbarkeit sind zwei zentrale Ziele guter Softwareentwicklung, die nachträglich nicht implementiert werden können.

Der Plan – das Big Picture

Kleine, große und auch Teilprojekte brauchen Struktur. Wie viele Files und wie viele Zeilen Code benötige ich dafür? Allerdings sehe ich immer wieder Entwickler, die einfach drauflos coden. So entsteht Chaos. Trial-und-Error-Coder kann man diese Sorte meist junger Entwickler nennen. Im Laufe des Projekts wird es neben dem strukturellen Chaos der Files auch im Quellcode zunehmend chaot...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang