Um es kurz zu machen: Wir haben eine Anwendung mit einer monolithischen Architektur übernommen und damit eine technische Schuld übernommen, die in jeder Phase ihrer Entwicklung Probleme mit sich brachte. Das ist eine ziemlich häufige Situation und ein banales Thema in der IT-Welt, aber ich dachte, ich schreibe ein paar Worte darüber, wie wir das angegangen sind, da ich nicht viel Erfahrung mit solchen Projekten habe.

Ein Dutzend Jahre altes Projekt, das sich immer noch an WinForms und alle Versionen von MVC, das veraltete .NET Framework, Knockoutjs oder die jQuery-Bibliothek erinnert. Fasziniert? Ich lade Sie ein, weiter zu lesen, wo ich Sie, lieber Leser, auf ein Abenteuer mitnehmen werde, an dem Sie teilgenommen haben, sind oder werden (falls Sie diesen aufregenden Weg als Programmierer gewählt haben, natürlich). Um Ihnen Zeit zu sparen, werde ich die Punkte, die ich besprechen möchte, näher erläutern:

1. Brownfield-Projekt - oder warum es meiner Meinung nach besser ist, mit dieser Art von Projekt zu beginnen.

2. Achillessehne in einer Legacy-Anwendung. Tatsächlich wird es mehrere von ihnen geben.

3. Inkrementelles Refactoring - das heißt, wie man eine Revolution in der Architektur vollzieht und das Ausfallrisiko reduziert.

‍

1. Brownfield-Projekt

‍Im ersten Punkt möchte ich auf einen Aspekt eingehen, der bei dieser Art von Projekten oft unterschätzt wird - das sind historische Daten. Im Gegensatz zu den vielersehnten und erträumten Greenfield-Projekten haben wir hier den Vorteil, dass wir Informationen darüber haben, wie Benutzer unsere Anwendung verwenden. Dies gibt uns eine große Menge an Wissen, das wir beim Wiederaufbau und der Optimierung der Prozesse im System verwenden können. Der zweite Vorteil besteht darin, dass eine Anwendung, die in der Produktion „aufgewärmt“ ist, ein ausgereiftes Produkt ist, das seit vielen Jahren gemeinsam mit dem Unternehmen entwickelt wird. Geschäftskenntnisse oder Geschäftsanforderungen sind zu Beginn der Entwicklung einer Anwendung oder neuer Funktionen nicht immer klar. Je nach Art des Projekts müssen wir die richtige Taktik anwenden. In unserem Fall hatten wir einen guten Start, weil wir über historische Informationen verfügten, die uns halfen, die Bewerbung auf den richtigen Weg zu bringen. Für junge Teams ist dies eine großartige Gelegenheit, die Grundlagen der Programmierung und die Kunst des Sammelns und Verarbeitens von Daten zu erlernen. Die Kenntnis bestimmter Anwendungsfälle erleichtert es, architektonische Entscheidungen zu treffen. Vielleicht gibt es eine weitere Gelegenheit, ein paar Worte über die zweite Art von Projekten zu schreiben — Greenfield-Projekte und den Lean-Startup-Ansatz.

‍

2. Achillessehne.

Unsere Anwendung hatte einige unverzeihliche Sünden, wenn es um die breite Entwicklung guter Software und moderner Cloud-Native-Trends ging. Eine davon war die allgegenwärtige und allwissende Session und der Cache. Mein Rat? Wenn du eine implementierte Sitzung und API siehst, die mit dem Frontend kommuniziert und du nichts dagegen tun kannst: Run! Halb scherzhaft, halb ernst. Cache und Sitzung haben uns viele Probleme bereitet und oft dazu geführt, dass tiefgründiges Debuggen erforderlich war. Es gibt auch Pluspunkte - wir haben gelernt, wie man debuggt und unsere Umgebung - Rider - sehr gut kennengelernt. Wie komme ich aus einer solchen Situation heraus, ohne uns für mehrere Jahre im Keller einzusperren, um die Anwendung neu zu schreiben? Unser Ansatz bestand darin, „Sitzungen“ systematisch in der Datenbank zu speichern. Am Ende dieses Abschnitts rate ich Ihnen, in die Erweiterung Ihres Wissens über designgetriebene Entwicklung zu investieren, insbesondere zum Thema begrenzte Kontexte. Unser Erbe umfasste zwei Anwendungen, die aus geschäftlicher Sicht nichts oder nur sehr wenig miteinander zu tun hatten. Eine solche Abkürzung von zwei Anwendungen in einer einzigen Lösung zeigt entweder Faulheit der Entwickler, mangelnde Kompetenz oder kurze Fristen. Zusammengefasst: Wer hochwertige Software liefern will, braucht dafür Zeit.

‍

3. Inkrementelles Refactoring.‍

Persönlich bin ich kein Fan davon, Anwendungen von Grund auf neu zu schreiben. In unserem Fall war dies unmöglich, da die Anwendung verwendet wurde und wir nur über begrenzte Ressourcen verfügten. Andererseits glaube ich an agile Programmierung, mit der Sie in relativ kurzer Zeit etwas liefern können, das dem Unternehmen einen Mehrwert bringt. Wir haben damit begonnen, das System zu analysieren und die technischen Schulden beim Namen zu nennen. Wir schätzten, dass wir in einem pessimistischen Fall etwa ein Jahr brauchen würden, um diese Anwendung auf den Markt zu bringen. Soweit es mich betraf, „nein“. Inspiriert von dem Buch Lean Startup haben wir uns entschlossen, die von Benutzern am häufigsten verwendeten Funktionen als MVP zu verwenden. In 3 Monaten haben wir eine in React geschriebene SPA-App verschenkt. Natürlich mussten wir technische Schulden auf uns nehmen, was suboptimale Abfragen (das N+1-Problem), die Verwendung einer „Antikorruptionsebene“ und einige zusätzliche „Workarounds“ beinhaltete. Wir waren uns der Schulden bewusst, die wir hatten, und zahlten sie systematisch in jeder möglichen Wiederholung ab.

Unsere Reise ist noch nicht vorbei, aber wir bewegen uns konsequent auf unser Ziel zu. Kurz gesagt, aber ich hoffe, ich habe Sie, lieber Leser, dazu inspiriert, nicht die Motivation zu verlieren, wenn Sie eine Bewerbung erben, die sich als „großer Schlammball“ herausstellt. Wie Sie an diese Art von Projekt herangehen, wird von Ihrer Reife als Programmierer zeugen.

Piotr Czyz
@_piotr