Engineering- und Research-Projekt
Leitfrage
Wie können wir eine fremde Codebasis so analysieren, dass aus technischen Signalen und nachvollziehbarer Evidence belastbare Informationen für Übernahme, Weiterentwicklung und Refactoring entstehen?
Die entscheidende Frage bei einer Softwareübernahme ist nicht „ist dieser Code gut oder schlecht?" — das führt zu einer Qualitätsdebatte statt zu einer Entscheidung. Gefragt ist: Können wir dieses System verantwortbar übernehmen, welche Risiken bestehen, welche Maßnahmen sind erforderlich, mit welchem Aufwand?
Coverage, Komplexität und Issue-Zahlen sagen etwas über den Code aus, aber nichts darüber, was eine Übernahme kostet. Ein Projekt mit guten Metriken kann eine undokumentierte Abhängigkeit haben, die jede Änderung teuer macht.
Ein erfahrener Engineer liefert gute Antworten — die Begründung bleibt aber oft implizit, und der Aufwand wiederholt sich bei jedem Projekt.
Ein Modell, das die Codebasis liest und ein Urteil ausgibt, kann seine Aussagen nicht auf überprüfbare Fakten zurückführen. Im Übernahmekontext ist der Code zusätzlich meist vertraulich.
Zwischen einem technischen Befund und dem Satz „dieser Befund verursacht Aufwand X und Risiko Y" liegt Arbeit, die heute meist gar nicht oder nur im Kopf einzelner Personen stattfindet.
Eigene Einschätzung, hergeleitet in der Projektbeschreibung — keine Marktstudie.
Ein Werkzeug und die Untersuchung drumherum. Das Werkzeug ist echt und die Qualitätsmaßstäbe sind real; ein Geschäftsmodell gibt es nicht. Die Arbeit verfolgt vier Ziele:
Von der Codebasis zur Aussage. Der Marker zeigt, bis wohin das Modell heute trägt; was darunter steht, ist Konzept.
AST- und Symbolanalyse über Spoon, OpenAPI-Parsing mit $ref-Auflösung. Lokal, ohne Netzwerkzugriff.
Bewerteter Befund mit Evidence; eine externe AI erhält ausschließlich ein pseudonymisiertes Exportmodell — nie Quellcode.
Wie viel Unsicherheit verträgt eine Aufwandsspanne, bevor sie nutzlos wird? Offen.
Alle 8 Stufen einzeln, mit Stand und Belegen: Handoff Audit im Detail
Jeder Eintrag mit dem, was er behauptet, was das belegt und wo die Grenze liegt. Nichts davon ist als fertig dargestellt, was bislang nur konzeptionell vorgesehen ist.
Lokale Analyse von Java-/Spring-Repositories und OpenAPI-Spezifikationen, ohne Netzwerkzugriff.
Festgehaltene Erkenntnisse aus abgeschlossenen Umsetzungsschritten, jeweils mit Beleg.
Bewertete Befunde mit Evidence, Kategorie und betroffener Fläche.
Technische und methodische Fragestellungen rund um evidence-basiertes Assessment.
Fachbeiträge aus realer Arbeit, nicht aus Themenplanung.
Beiträge entstehen aus Entwicklung und Experimenten. Was sich nicht belegen lässt, wird nicht geschrieben — veröffentlicht ist bislang keiner.
Evidence vorhanden Package-Grenzen, Architekturregeln und das Egress-Modell belegen die Trennung strukturell.
Evidence teilweise Problem und Abgrenzung dokumentiert, keine Validierung an einem Realprojekt.
Alle geplanten Themen mit ihrer Belegsituation: Insights
