Technical Debt: 20 Jahre Arbeit und nichts als technische Schulden
Dieser Artikel ist eine Übersetzung. Das englische Original des US-amerikanischen Softwareentwicklers und Unternehmers Matt Watson ist hier zu finden(öffnet im neuen Fenster) .
"Technische Schulden" ist mit Abstand das meistbenutzte Buzzword dieser Tage. Die Leute sagen: "Wir kommen mit unserem MVP schnell voran und minimieren gleichzeitig die technischen Schulden ." Das soll wohl cool klingen. Ich kann darüber nur lachen. Denn alles wird irgendwann zu technischen Schulden. Meine gesamte Karriere ist inzwischen technische Schuld oder der Code ist veraltet.
Wenn du nicht glauben kannst, dass auch deine gesamte Karriere irgendwann zu technischen Schulden wird, warte, bis du diesen Artikel gelesen hast. Ich werde dir zeigen, was sich alles in meiner 20-jährigen Berufslaufbahn verändert hat.
Ich bin als Visual-Basic-6-Entwickler ins Berufsleben eingestiegen. Von 1999 bis 2003 habe ich mehrere Apps gebaut. Man kann mit Sicherheit behaupten, dass alles, was in Visual Basic 6 geschrieben wurde, nach heutigen Standards technische Schuld oder schon längst ersetzt worden ist. Ein Hoch auf " on error resume next(öffnet im neuen Fenster) " !
Ich habe viel Zeit damit verbracht, klassische Active Server Pages (ASP) zu entwickeln. Ich war auch Experte dafür, Webseiten mit dem Internet Explorer 6 zum Laufen zu bringen. Im Lebenslauf kann man damit nicht mehr angeben! Visual Basic, ASP, IE6 und Netscape sind allesamt längst vergessene Technologien. Wie Strong Bad sagen würde: " Delorted!(öffnet im neuen Fenster) "
Alte Sprachen: Perl, Delphi, Fortran, Foxpro, Coldfusion
Neben Visual Basic 6 gibt es eine ganze Reihe von Programmiersprachen, die in den vergangenen 20+ Jahren unbeliebt geworden sind. Wenn du irgendetwas in einer der folgenden Sprachen entwickelt hast, versuchen andere jetzt vermutlich herauszufinden, wie man es umschreiben kann, weil es schwer ist, Programmierer für diese Sprachen zu finden: Perl, Delphi, Fortran, Foxpro, Coldfusion.
Gibt es noch Anwendungen in diesen Sprachen? Ja. Kann man Leute dafür einstellen? Schwierig. In den meisten Fällen müssen diese Unternehmen die alten Anwendungen modernisieren und in den Ruhestand schicken.
In den frühen 2000er Jahren hielten viele Adobe Coldfusion für den letzten Schrei. Erinnert sich noch jemand an den kleinen Aufstieg des Programms?
Ruby on Rails läuft Gefahr, auf diese Liste zu kommen. Es wird unbeliebter und man findet nur schwer Entwickler dafür. Was die Sprache früher einzigartig gemacht hat, ist jetzt auch in anderen Sprachen verfügbar.
Programmiersprachen kommen und gehen. Entwickler wollen keine Jobs, bei denen sie Fähigkeiten erlernen, die nicht gefragt sind. Es ist immer ein Gleichgewicht von Angebot und Nachfrage. Entwickler wechseln schnell das Boot und wollen immer das Neueste in ihrem Lebenslauf.
Was ist aus ActiveX, Java Applets, Flash und Silverlight geworden?
Einige der ersten Anwendungen, die ich entwickelt habe, verwendeten ActiveX-Steuerungselemente im Internet Explorer 6. Sie waren damals notwendig, wenn man drucken und andere unsichere Dinge machen wollte. PDFs waren noch nicht so verbreitet, und das Drucken aus dem Browser war ein Albtraum, wenn auch ein lustiger.
Auch Java-Applets waren mal ein großes Ding. Sie waren langsam, und es war immer ein Kampf, die richtige Java-Version auf dem Computer zu haben. Ich werde nie vergessen, was es für ein Alptraum war, mit Netzwerk-Firewalls umgehen zu müssen, die Java-Applets erforderten. Diese Albträume vermisse ich nicht, und zum Glück ist das alles Vergangenheit.
Natürlich erinnern wir alle uns an Macromedia/Adobe Flash. Eine Zeitlang war es der Liebling des ganzen Internets. Es gab unendliche Flash-Spiele und haufenweise Software, die in Flash mit Action Script gebaut war. Mit einem Produkt namens CheerpX kann man alte Flash-Apps mit Webassembly zum Laufen bringen.
Microsoft brachte dann einen Flash-Konkurrenten namens Silverlight heraus , ein ziemlich großartiges Framework für C#-Entwickler. Meine Firma hat damit ein paar tolle Sachen umgesetzt. Bekanntermaßen setzte Apple Flash und Silverlight ein Ende, als es den Support in seinen Browsern einstellte.
Hier ist ein Screenshot des Finanzrechners, den wir bei Vinsolutions vor mehr als zehn Jahren mit Silverlight entwickelt haben. Silverlight gibt es schon lange nicht mehr, und der Finanzrechner wurde komplett in Javascript umgeschrieben, aber die neue Version ist lange nicht so so cool wie die alte!
Meine erste mobile Anwendung
Meine erste mobile App habe ich 2004 geschrieben. Man kann sich kaum noch dran erinnern, aber damals gab es noch kein iPhone und auch kein Android. Meine App war für Compaq-PDAs zur Bestandsverfolgung für Autohändler gedacht. Sie war in C# für das .Net Compact Framework geschrieben und lief auf Windows CE.
Der PDA hatte eine 1-Megapixel-Kamera. Die Fotos waren ein bisschen furchtbar, aber okay – zumindest, wenn es bewölkt war und nicht so blendete. Junge, hat sich die Technik verändert! Diese Anwendung ist schon lange auf dem Schrottplatz gelandet, aber 2005 war sie das Neueste vom Neuen.
Swift: ein großer Schritt
Swift ist ein weiteres sehr gutes Beispiel dafür, wie schnell sich Entwicklerwerkzeuge verändern. Sobald Apple Swift herausbrachte, war es kaum noch zu rechtfertigen, Code in Objective C zu schreiben. Bestimmt gibt es auch jetzt nur ein paar Anwendungsfälle, für die man es braucht. Aber mit Swift ist die Entwicklung bedeutend einfacher, und es ist ein großer Entwicklungsschritt. Man kann behaupten, dass alle in Objective C geschriebenen Anwendungen inzwischen wohl technische Schulden sind.
Webforms war cool ... bis MVC kam
Nachdem ich eine Weile verrückte Inline-Scripts für die Entwicklung von Webapps geschrieben hatte, war ich sehr froh, auf die neuen ASP.Net-Webformulare umzusteigen. Ihre serverseitigen Steuerungselemente machten die Entwicklung erheblich einfacher. Ziel war es, die Erstellung von Webanwendungen wesentlich zu vereinfachen. Das hat weitgehend geklappt. Man konnte wiederverwendbare UI-Komponenten serverseitig erstellen und sie im Browser rendern, so wie es heute noch mit 100 Prozent Javascript gemacht wird.
Webforms war nicht perfekt, aber eine erhebliche Verbesserung. Es lief super, bis Ruby on Rails MVC (Model View Controller) Frameworks für die Entwicklung von Webanwendungen populär machte. MVC überholte schnell alle Webformulare, die wir je entwickelt hatten. Alles, was in Webformularen steckt, zählt definitiv zu den technischen Schulden (obwohl dieselbe Idee mit Blazor(öffnet im neuen Fenster) ein Comeback erlebt).
MVC ist König (eine Weile)!
Ehe man sich versah, unterstützte jede Programmiersprache MVC-Frameworks. Wir gingen dazu über, alles Neue in ASP.NET MVC umzusetzen. Es war einfach überall, auch in Django, Laravel, Symfony, Spring usw.
Heute ist MVC längst aus der Mode gekommen. Alles wird jetzt mit React, Angular, Vue und anderen Frameworks umgesetzt. Bevor es die gab, hatten wir andere Javascript-Frameworks. Bei Stackify haben wir Knockout verwendet, ein recht populäres Frontend-Framework.
Wer erinnert sich an eins dieser Frameworks: Knockout, Ember, Aurelia, Meteor, Backbone, Handlebars? Ich wette, alles, wo eins dieser Frameworks verwendet wurde, ist überholt und wird jetzt als technische Schuld betrachtet. Die erste Generation von Front-End-Frameworks hat gegen React und Angular verloren.
Angular JS
Angular wurde 2015 von Google entwickelt und eroberte die Szene im Sturm. Schnell wurde es zum beliebtesten Frontend-Framework. 2016 gab es dann ein großes Update und Angular war nicht mehr abwärtskompatibel. Rate mal, was das heißt! Alles, was in der ursprünglichen Version enthalten war, ist jetzt technische Schuld. In meiner Firma habe ich noch Projekte in der alten Angular-Version – große technische Schulden, die wir upgraden müssen.
Das dreckige alte SOAP & WCF
Bevor REST-APIs und JSON zum De-facto-Standard wurden, gab es noch eine andere Möglichkeit: SOAP(öffnet im neuen Fenster) , kurz für Simple Object Access Protocol. Es erleichterte den Aufruf von Webdiensten sowie die automatische Codegenerierung von Proxy-Klassen für den korrekten Aufruf der Dienste und wurde hauptsächlich vom Windows Communication Framework (WCF) über XML verwendet.
Es funktionierte großartig ... bis es nicht mehr funktionierte. Eines der schlimmsten Projekte meiner Karriere bestand darin herauszufinden, wie Sicherheitszertifikate zwischen meinem Unternehmen und einem anderen Anbieter über WCF und SOAP verwendet werden konnten. Das Versprechen von SOAP und WCF war großartig, aber es war ein Albtraum, es über die Zeit zu pflegen.
Ich vermisse SOAP und WCF nicht. Microsoft hat die WCF-Unterstützung in .Net Core aufgegeben und bevorzugt Rest, gRPC, GraphQL usw. Das Community-Projekt CoreWCF(öffnet im neuen Fenster) hält es aber am Leben.
Im Laufe der Zeit haben sich die Technologien verändert, mit denen wir Webdienste aufrufen. Ältere Methoden funktionieren immer noch, aber die meisten Menschen würden sie wahrscheinlich gern in den Ruhestand schicken.
Wichtige Sprachversionen
Ein weiteres häufiges Problem sind größere Versionssprünge bei Programmiersprachen, seien es Ruby, PHP, .NET oder andere. Sie erfordern in der Regel eine Reihe von Änderungen am Code – oder sogar, ihn neu zu schreiben. .Net Core wurde als neuere, leichtere und schnelle Version von .Net veröffentlicht und für die Ausführung unter Linux entwickelt. Einfacher C#-Code lässt sich ziemlich leicht portieren, aber niemand verwendet nur einfachen Code für eine reale Anwendung.
Bei komplexen Unternehmensanwendungen gibt es jedoch viele potenzielle Probleme bei der Navigation auf dem Upgrade-Pfad. Dieses Problem ist eine große technische Schuld und muss gelöst werden, ansonsten bleibt man auf einer uralten Version sitzen. Diese großen Versionsupdates werden irgendwann zu großen "Technische Schulden" -Projekten.
An alten externen Abhängigkeiten kleben
Eine unserer größten Herausforderungen bei Stackify war die Abhängigkeit von einer alten Version von Elasticsearch. Es gab an einem Punkt bedeutende Änderungen in der Funktionsweise, die nicht mehr vollständig abwärtskompatibel waren. Da wir es sehr viel verwendeten, wurden die nötigen Upgrades der Projekte zu einem massiven technischen Schuldenberg.
Wir schoben es immer weiter auf die lange Bank und irgendwann waren wir hoffnungslos im Hintertreffen. Das ist noch ein Beispiel dafür, wie echte technische Schulden eine Plage fürs Unternehmen sein können.
Open-Source-Alternativen lassen meinen Code alt aussehen
Bei Stackify haben wir unsere eigenen Tracing-/Profiling-Bibliotheken für sechs Programmiersprachen entwickelt. Das war unglaublich viel Arbeit. Und, naja, dann tauchte OpenTelemetry(öffnet im neuen Fenster) auf und machte all unsere Arbeit überflüssig. Warum selbst verwalten, wenn man den Open-Source-Industriestandard verwenden kann? Stackify ist dabei, den .Net Profiler, den ich mitentwickelt habe, nach und nach abzuschaffen.
Jeder Code wird alt oder ersetzt
Mit den Jahren muss man mit ansehen, wie fast alles, was man kreiert hat, aus irgendeinem Grund verschrottet und ersetzt wird oder auf alter Technik basiert. Mehrere Anwendungen, die ich zu Beginn meiner Karriere entwickelt habe, wurden eingestellt, weil die Unternehmen aufgekauft wurden und beschlossen, eine völlig andere Technologie zu verwenden.
Die meiste Software hat eine begrenzte Lebensdauer, die kürzer ist, als man denkt. Jeder Code wird irgendwann technische Schuld, die alle modernisieren und umschreiben wollen. Oder die Geschäftsanforderungen ändern sich dramatisch.
Zugegeben, in der Unternehmenswelt kommt es häufiger vor, dass interne Anwendungen ewig im Einsatz bleiben. Eine Eisenbahngesellschaft oder eine große Bank verwendet seit 40 Jahren dieselbe mainframe-basierte Software.
Ich prophezeie, dass WebAssembly die heutige Front-End-Entwicklung irgendwann überholen wird und eine ganz neue Welt entstehen wird.
Die Realität der technischen Schulden
Bei neuen Projekten wollen alle immer die technischen Schulden geringhalten. Ich verstehe das. Man muss das Gleichgewicht finden zwischen dem Ziel, Dinge zum Laufen zu bringen, und dem Versuch, sie perfekt zu machen.
Aber nichts ist technische Schuld, nur weil es nicht perfekt ist. Perfektion gibt es nicht. Was heute perfekt ist, wird in Zukunft nicht mehr perfekt sein. Wir müssen lernen, mit weniger als perfekt zu leben.
Die andere Seite der technischen Schulden ist, dass alles vergänglich ist. Entweder gibt es erhebliche Probleme bei der Aktualisierung auf die neuesten Versionen oder die Technologie wird aufgrund neuerer Methoden nicht mehr verwendet. Viel Glück bei der Einstellung von Mitarbeitern für alte Technologie-Stacks!
Irgendwann wird alles zu technischen Schulden. Wer Glück hat, dessen Code überlebt lange genug, dass sich später jemand anders mit den technischen Schulden herumschlagen muss.
All dein Code wird irgendwann gelöscht.
(Übersetzung: Juliane Gunardono)
- Anzeige Hier geht es zum Handbuch für Softwareentwickler bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.