Software verstehen. Zusammenhänge erkennen. Bewusster verändern.
Du kannst guten Code schreiben und trotzdem vor einer Änderung stehen, deren Folgen schwer einzuschätzen sind. Vielleicht fehlt dir ein Zusammenhang. Vielleicht reden zwei Teams über unterschiedliche Dinge. Vielleicht funktioniert die Lösung heute und macht den nächsten Schritt unnötig schwer.
Hier findest du einige Beispiele zu solchen Situationen. Sie verbinden Beispiele aus der Softwareentwicklung mit Ansätzen wie C4, Domain-Driven Design und Systems Thinking. Die Begriffe werden dort erklärt, wo sie helfen. Du kannst bei der Frage einsteigen, die dich gerade beschäftigt.
Wie verstehe ich bestehende Software, bevor ich sie ändere?
Eine kleine Tabellenänderung führt zu einer Verbindung, die im Repository kaum sichtbar war. Was Architecture Recovery leisten kann und wie du herausfindest, welche Informationen du für deinen Eingriff wirklich brauchst.
Bestehende Software verstehen
Wie wird aus einem Architekturdiagramm eine brauchbare Arbeitsgrundlage?
Eine neue Kollegin, eine große Übersicht und eine einfache Frage. Wie du mit C4 und arc42 unterschiedliche Sichten zusammenbringst, ohne jedes Detail in dieselbe Zeichnung zu packen.
Systemmodelle mit C4 und arc42 nutzen
Warum erzeugen erfolgreiche Reparaturen immer wieder neue Arbeit?
Ein Release ist gerettet. Beim nächsten braucht es wieder dieselbe Person. Systems Thinking hilft, Rückkopplungen zu untersuchen und einen kleinen Eingriff so zu planen, dass sich aus seiner Wirkung lernen lässt.
Wiederkehrende Probleme
Wie entscheiden wir zwischen zwei guten Architekturlösungen?
Häufigere Datenimporte oder Ereignisverarbeitung? An einer konkreten Abwägung siehst du, wie Trade-offs, Reversibilität und Architecture Decision Records eine Entscheidung nachvollziehbar machen.
Architekturentscheidungen begründen
Wo braucht ein System klare fachliche Grenzen?
Zwei Teams sprechen vom „aktiven Kunden“ und meinen etwas anderes. Wie DDD, Bounded Contexts und gemeinsame Sprache helfen, Bedeutung und Verantwortung an einer Schnittstelle zu klären.
Systemgrenzen und DDD verstehen
Was muss ich prüfen, wenn KI-generierter Code funktioniert?
Ein Export ist fertig. Im Diff liegen zusätzlich eine Queue und ein neuer Datenspeicher. Wie du Architekturentscheidungen in generiertem Code erkennst und Vorgaben mit passenden Prüfungen verbindest.
KI-Coding auf Architekturfolgen prüfen
Aus einzelnen Erkenntnissen eine Arbeitsweise machen
Zusammenhänge sichtbar machen, Entscheidungen vorbereiten und aus Änderungen lernen: Diese Fähigkeiten stehen auch im Mittelpunkt von THINK FIRST. Wenn du sie an deinem eigenen IT-Alltag weiterentwickeln möchtest, findest du hier die Lernangebote von THINK FIRST.