Kolumne: Olis bunte Welt der IT

Die neue Welt von Blazor – oder: Altlasten nicht überbewerten
Keine Kommentare

Heute schreiben wir tollen Code. Tatsächlich schreiben wir heute den besten Code, den wir je geschrieben haben! Wenn ich „wir“ sage, meine ich nicht die Menschheit im Allgemeinen, sondern jeden einzelnen Programmierer. Ich hoffe, Sie stimmen mir zu: Der Code, den ich heute schreibe, ist wesentlich besser als der von gestern. Klar, manchmal schreibe ich auch Code, der stark von Kaffeemangel oder dergleichen beeinträchtigt ist – der wird dann morgen korrigiert.

Wir lernen ständig dazu

Prinzipiell ist der Job des Programmierers einer, der dauerndes Lernen erfordert. Wir lernen, mit der Programmiersprache der Wahl schöneren Code zu schreiben, also besser wartbaren, performanteren oder auch kompakteren Code. Wir lernen neue Programmiersprachen – aus Neugierde oder Notwendigkeit. Die Zielplattformen ändern sich im Laufe der Zeit, ebenso die bevorzugten Patterns oder gar Entwicklungsmethoden. So schreiben wir nach und nach nicht nur gefühlt besseren Code, wir schreiben ihn auch auf eine bessere Weise. Das ist natürlich lobenswert, und ich selbst mag diesen Aspekt der Softwareindustrie. Ich fühle mich wohl mit der Idee, dass morgen alles wieder anders und hoffentlich noch besser sein wird.

Altlasten bleiben Lasten

Ein Problem des ständigen Lernens ist aber, dass die Zufriedenheit mit dem bereits geleisteten, also mit dem Code von gestern, nicht groß ist (oder bleibt). Wenn ich gestern etwas besonders Gruseliges geschrieben habe, ändere ich das heute eventuell wieder – aber langfristig bleibt der Code der Vergangenheit doch ärgerlich lange bei mir, auch wenn ich schon längst den geistigen Meilenstein „Das macht man doch gar nicht mehr so“ passiert habe. So sammeln sich Altlasten an. Wir erinnern uns, ein Problem schon einmal gelöst zu haben, wollen aber gar nicht auf diese alte Lösung zurückgreifen, wenn es drauf ankommt, da eine aktuelle Lösung eigentlich ganz anders aussehen sollte. Natürlich ist dieses Problem in Programmiererteams noch viel größer, da hier zu jedem Zeitpunkt unterschiedliche Wissensstände, Präferenzen sowie Zufriedenheitsgrade mit der momentan aktuellen Technologie aufeinandertreffen.

C# 8.0 Spickzettel

Kostenlos: C# 8.0 – neue Sprachfeatures auf einen Blick

Der C#-8.0-Spickzettel fasst die neuen Features der Sprache zusammen mit Blick auf das aktuelle .NET Core 3.0 bzw. .NET Standard 2.1. Jetzt herunterladen und schneller & effektiver programmieren!

Die Konsequenzen dieser Sachverhalte habe ich im Gespräch schon oft beobachtet. Immer wenn ich einen Programmierer frage, was seine Firma oder sein Team so macht, besteht ein Teil der Antwort in der Beschreibung einer alten Software, die gepflegt werden muss. Manchmal ist diese Software nur ein paar Jahre alt, manchmal geht es um Jahrzehnte, aber es gibt immer dieselben Schwierigkeiten. Da gibt es Code, den man selbst geschrieben hat, aber der mit guten Gründen eigentlich neu gebaut werden sollte. Da gibt es Module, von denen keiner weiß, wie sie genau funktionieren, da der verantwortliche Programmierer längst nicht mehr im Unternehmen ist. Da gibt es plattformspezifische Beschränkungen, die sich bereits im geschäftlichen Teil niederschlagen, aber nur mit großem Aufwand zu beheben sind.

Praktisch alle Unternehmen, die Software erzeugen, verbringen einen großen Teil ihrer Zeit damit, vorangegangene Versionen zu pflegen. Die restliche Zeit kann darauf verwendet werden, neue Funktionen oder neue Versionen der alten Funktionen zu entwickeln. Interessanterweise gibt es dazu allerdings ganz unterschiedliche Ansätze. Am einen Ende des Spektrums gibt es Firmen, die ständig neue Architekturkonzepte entwickeln, mutig Neuimplementationen in Angriff nehmen, auf neueste Plattformen und Sprachen setzen. Da bleibt man am Ball, geht mit der Zeit, investiert in die Technologie. Hin und wieder geht das gar etwas zu weit, wenn sich Ansätze auf Dauer als kurzlebiger herausstellen als man dachte. Entwickler fühlen sich in solchen Firmen geschätzt, da sie regelmäßig ihre Lernfähigkeit und aktuelle Expertise unter Beweis stellen dürfen.

Am anderen Ende des Spektrums finden sich solche Teams, bei denen es in erster Linie um den Erhalt des bereits Erstellten geht. Dort werden Fehler behoben, Workarounds gefunden, Werte bestehender Investitionen maximiert. Entwickler fühlen sich auch in diesen Teams geschätzt, schließlich sind sie die einzigen, die wissen, wie die technischen Systeme funktionieren – kein neu eingestellter Mitarbeiter oder Chef hat eine Chance, auf den Stand eines langjährig erfahrenen Programmierers zu kommen.

Altes auf neuen Wegen mit Blazor

Um diese Betrachtungen mit etwas praktischem Leben zu füllen, möchte ich das Beispiel der aktuellen Technologie Blazor anführen. Dazu habe ich mit mehreren Gruppen von Programmierern Gespräche geführt und höchst unterschiedliche Auffassungen gehört. Nehmen wir einmal ein Team, in dem eine geschäftliche Anwendung entwickelt wurde, mit verschiedenen Modulen für unterschiedliche Teile des Betriebs, großen Mengen an Daten, Anforderungen zur Plattformunterstützung von Windows, Web und Mobilgeräten. Die Software wurde ursprünglich um 2004 mit Windows Forms und C# entwickelt. Als 2007 eine Weblösung notwendig wurde, plante das Team eine große Refaktorisierungskampagne und schaffte den Schritt zu ASP.NET WebForms. Noch während dieser Arbeit wurden Entwickler auf die Anforderungen aufmerksam, die Microsoft mit der Einführung von Silverlight einem breiten Publikum unterbreitete: Datenzugriff sollte mit Hilfe von Diensten abstrahiert werden. Auch diesen Schritt machte das Team mit und baute unabhängige Dienste. Die Komponenten des neuen Systems entwickelten sich über Jahre hinweg weiter und heute existiert eine Angular-Anwendung mit einem .NET Backend. Geplant ist eine noch bessere Aufteilung der Dienste, um einen Umstieg in die Cloud einfacher zu machen.

Konfrontiert mit dem Konzept von Blazor reagierten die Mitarbeiter dieses Teams mit Unverständnis. UI in C# programmieren? – Okay, aber warum? Serverseitiges Blazor erzeugt eine kuriose Systemarchitektur mit einem Fokus auf bidirektionalen Kommunikationsmechanismen, was den Bestrebungen zur Entkopplung leichtgewichtiger Dienste im besten Fall nicht zuträglich ist. Blazor mit WebAssembly verspricht sehr performant zu sein, aber was tut das UI schon, was so viel Leistung erfordert? Geschäftsanwendungen in Angular sind im Allgemeinen performant genug, ebenso solche in React. Außerdem ist das Team natürlich vertraut mit Welt der Pakete für JavaScript, und so lässt die Feststellung nicht lange auf sich warten: Ohne npm wird zunächst alles schwieriger im UI. Vielleicht bleibt Microsoft lange genug bei der Sache, um vergleichbare Infrastruktur selbst zur Verfügung zu stellen oder eine Community aufzubauen, die das tut.

Nun ist es so, dass dieses Team aufgrund der bereits sorgfältig strukturierten Architektur des Systems einen relativ einfachen Weg hin zu Blazor haben könnte. Gerade weil die Mitarbeiter aber seit Jahren ihr Produkt evolutionär entwickelt haben, sehen sie keinen Mehrwert in der neuen Plattform. Da man in der Vergangenheit flexibel war, hängt hier niemand an einer bestimmten Programmiersprache – in den Anfangszeiten war auch mal CoffeeScript im Einsatz, weil damals JavaScript nicht verlockend erschien. Das Problem, auf produktive Art und Weise ein UI für die Plattform HTML/JS zu erzeugen, ist hier längst gelöst. Der neue Vorschlag Blazor wird mit Interesse betrachtet, bietet aber keinen relevanten Vorteil.

Als zweites Beispiel möchte ich ein Team beschreiben, das zur Gruppe der geduldigen Softwarepfleger zählt. Auch hier gibt es eine Software, die auf Windows Forms basiert. Tatsächlich ist diese noch heute im Einsatz, mittlerweile seit 2006. Es gibt fast 200 Module, die unterschiedliche Formatdefinitionen implementieren, sowie Datenaustauschprotokolle und Übersichten. Die Software ist in mehreren großen Firmen im Einsatz und für kundenspezifische Anpassungen sind Kopien des Originalprojekts erzeugt worden, die nun parallel gepflegt werden. Auch eine WebForms-Version der Software ist einmal als Kopie erzeugt worden, im Funktionsumfang drastisch reduziert, aber ausreichend für den Kunden, der diese Anforderung hatte. Für einige Altkunden werden weitere Kopien mitgezogen, da diese zum Teil mit älteren Versionen der Software arbeiten. Die Einstellung zur Weiterentwicklung war in diesem Team lange Zeit die, dass bestehende Systeme beibehalten werden sollten und Geld lieber in die Anpassungsarbeit für einzelne Abnehmer investiert wurde als in Refaktorisierung oder gar Neuentwicklung. Anforderungen gab es viele, aber es wurden Lösungen gefunden – z. B. verwenden einige Kunden die Software über eine Remote-Desktop-Verbindung vom Tablet aus. Leider ist die Konsequenz dieses Ansatzes, dass viele Programmteile extrem schwierig zu warten sind. Beispielsweise gibt es Formulare mit mehreren zehntausend Zeilen Code in Event Handlern. Allein aufgrund der vielen Kopien des Projekts ist man ängstlich, notwendige Schritte einzuleiten.

Auch mit diesem Team habe ich ein Gespräch über Blazor geführt, und die Mitarbeiter zeigten Begeisterung. UI-Code mit C# zu schreiben erscheint diesen Programmierern als natürlicher Weg. Die Idee, Teile des existierenden Codes wiederverwenden zu können, entspricht genau der Haltung, die seit Jahren in ihrem Unternehmen Vorrang hat. Sorgen macht die architekturelle Umstellung, alle Datenzugriffe ohne direkte SQL-Server-Verbindung zu bewältigen. Trotzdem ist das Team sehr an Blazor interessiert, möchte gern einen Umstieg planen und geht davon aus, dass dieser im Vergleich zu anderen Wegen relativ reibungslos verlaufen sollte.

Bemerkenswert, wie unterschiedlich die Auffassungen sein können. Leider vermute ich, dass dieses Team mit seinen Einschätzungen weit neben der Realität liegt. Dabei ist der Denkfehler nicht ungewöhnlich: Wenn auf beiden Plattformen mit C# programmiert werden darf, muss der Umstieg doch einfach sein. Natürlich ist das schon grundsätzlich nicht immer richtig, aber in Fällen wie diesem besonders problematisch. Der Code, der für Windows Forms geschrieben wurde, ist derart eng mit der Plattform gekoppelt, dass er größtenteils nicht in einem anderen Kontext laufen wird. Man hat es außerdem konsistent versäumt, die Software auf einem pflegbaren Stand zu halten. Da gibt es keine Patterns, die zur Trennung von UI, Geschäftslogik, Datenzugriff usw. dienlich sein könnten. Da gibt es keine Planungsmethoden, die Aspekten wie Wartung, Refaktorisierung und Ähnlichem den notwendigen Stellenwert geben.

Einfach mal das Rad neu erfinden

Blazor sollte in diesem Zusammenhang tatsächlich nur als aktuelles Beispiel dienen, allerdings stehe ich selbst der Technologie aus den erklärten Gründen etwas skeptisch gegenüber. Es bleibt abzuwarten, ob Microsoft lange genug darin investiert, um die Plattform als eine echte Konkurrenz zu bestehenden Lösungen zu etablieren. Der Markt ist schwierig zu definieren, also die spezifischen Gruppen von Entwicklern, die tatsächlich von Blazor profitieren können und möchten.

Als Fazit möchte ich allerdings auf meine Einstiegsüberlegungen zurückkommen. Entwickler lernen ständig und kontinuierlich, und das ist gut so. Erfahrene Entwickler schreiben besseren Code und manche Erfahrung lässt sich auch über technische Grenzen hinweg transportieren. Wenn Sie meine Kolumne verfolgen, haben Sie schon den Begriff „Wegwerfbarkeit“ gelesen, den ich als Zielsetzung des Konzepts Microservices definiert habe. Microservices sollen für Entwickler Zukunftssicherheit bieten, da sich zukünftige Wege zu neuen Technologien eher anbieten, wenn die Investitionen in einzelne Systemteile und die damit zusammenhängenden Entscheidungen klein gehalten werden. Aus denselben Gründen lege ich Ihnen auch nahe, wenn es in Ihre Zuständigkeit fällt, Entwicklern den Willen zu lassen, zu gegebenem Anlass das Rad neu zu erfinden. Natürlich sollte das nicht willkürlich geschehen, nicht ohne triftigen Grund oder eine fundierte Teamentscheidung. Ihre Software wird jedoch im Laufe der Zeit besser, wenn Sie nicht zu sehr an den Altlasten festhalten. Das tun wir in anderen Bereichen schließlich auch nicht – um ein neues, besseres Auto zu bauen, muss manchmal eine neue Maschine her, die neue Teile baut. Und in dem Zusammenhang behalten Sie bitte im Kopf, dass Software in der Herstellung eines der billigsten Produkte der Welt ist! Einmal gefertigt kann eine Software beliebig oft ohne Werkstoffkosten verkauft werden. Gerade deswegen ist es schwierig, den richtigen Punkt zur Neuinvestition zu finden – notwendig ist es aber trotzdem!

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. Außerdem ist der Windows Developer weiterhin als Print-Magazin im Abonnement erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -