Code Forensic und nachvollziehbare Befunde
Code Forensic: Was eine Codeanalyse belegen kann
Was Code Forensic belegen kann: Versionsstand, Änderungshistorie, Abhängigkeiten, reproduzierbare Prüfungen und Grenzen der Untersuchung.
Mit Code Forensic meine ich hier eine nachvollziehbare technische Untersuchung bestehender Software. Sie verbindet Quellcode, Änderungshistorie, Abhängigkeiten und vereinbarte Projektdaten, um konkrete Fragen zu beantworten. Entscheidend ist, wie ein Befund zustande kommt und welche Schlussfolgerung er tatsächlich trägt.
Wenn du auf dieser Grundlage über eine Modernisierung oder Stabilisierung entscheidest, reicht mir eine Liste von Werkzeugwarnungen nicht aus. Ich möchte den untersuchten Stand, den Prüfweg und die Bedeutung für das System erkennen können. Genauso sichtbar müssen die Grenzen bleiben. Ein auffälliger Codeabschnitt ist zunächst ein Anlass, genauer hinzuschauen.
Den untersuchten Stand eindeutig festhalten
Am Anfang steht die Frage, welche Version überhaupt untersucht wird. Der aktuelle Entwicklungsstand, die zuletzt ausgelieferte Version und ein fehlerhafter Release können sich unterscheiden. Ein Befund zum falschen Stand hilft bei der Ursachenklärung kaum weiter.
Ich würde deshalb Repository, konkrete Revision und den Zusammenhang mit dem betrachteten Release festhalten. Dazu kommen relevante Konfigurationen und die Versionen der eingesetzten Analysewerkzeuge. Bei einem späteren Vergleich muss erkennbar sein, ob sich das System oder nur die Prüfung verändert hat.
Ein Branchname allein genügt mir dafür nicht. Er kann nach weiteren Änderungen auf einen anderen Commit zeigen. Für die technische Zuordnung verwende ich einen konkreten Commit und dokumentiere, auf welchen Datenstand sich die Aussage bezieht. (Git-Referenzen und Revisionen)
Das betrifft auch zusätzliche Unterlagen. Ein Testbericht oder Fehlerprotokoll muss dem untersuchten Stand zugeordnet werden können. Wenn diese Verbindung fehlt, bleibt die Aussage darüber entsprechend begrenzt.
Eine Beobachtung ist noch keine Ursache
Nehmen wir als fiktives Beispiel einen Importprozess. Im Code ist keine erkennbare Absicherung gegen die wiederholte Verarbeitung derselben Nachricht vorhanden. Gleichzeitig gibt es einen Bericht über doppelte Datensätze.
Das sind zwei Beobachtungen, die zusammenpassen können. Ob der beschriebene Fehler dadurch entstanden ist, muss aber weiter geprüft werden. Vielleicht verhindert ein vorgelagerter Dienst die Wiederholung. Vielleicht greift eine Datenbankregel. Vielleicht beschreibt der Fehlerbericht einen anderen Verarbeitungsweg.
Ich würde den Befund deshalb präzise formulieren: Welche Stelle wurde geprüft, welche Absicherung ist dort vorhanden und welche ist im untersuchten Umfang nicht erkennbar? Dann folgt die mögliche Auswirkung unter benannten Bedingungen. Erst mit weiteren Nachweisen lässt sich eine Ursache zuordnen.
Diese Trennung ist für Entscheidungen wichtig. Eine bestätigte Fehlerursache verlangt einen anderen nächsten Schritt als eine plausible Erklärung oder eine offene Frage zu einem fremden System.
Die Historie liefert Zusammenhänge
Änderungshistorie kann zeigen, welche Bereiche häufig gemeinsam angepasst wurden oder nach einem Release weitere Korrekturen brauchten. Das hilft, eine vertiefte Untersuchung einzugrenzen. Aus der Zahl der Änderungen allein würde ich keine Qualitätsbewertung ableiten.
Auch eine Zuordnung von Codezeilen zu einem Commit hat einen begrenzten Aussageumfang. Sie zeigt zunächst, welche Revision die jeweilige Zeile zuletzt verändert hat. Sie erklärt weder die damalige Entscheidung noch die gesamte Entstehungsgeschichte. (Git-Dokumentation zu blame)
Deshalb gehören Architekturwissen und Gespräche mit dem Team dazu. Eine auffällige Änderung kann beispielsweise eine fachliche Anforderung, eine Umstellung der Schnittstelle oder eine notwendige Korrektur gewesen sein. Der Zusammenhang entscheidet darüber, welche Bedeutung das Muster bekommt.
Eine technische Untersuchung sollte dem Team helfen, Risiken zu verstehen. Für eine Bewertung der Leistung einzelner Personen ist eine solche Kennzahl für mich keine ausreichende Grundlage.
Werkzeugbefunde im System prüfen
Statische Analyse, Tests und die Prüfung von Abhängigkeiten betrachten unterschiedliche Teile einer Software. Ich würde ihre Ergebnisse gemeinsam einordnen und jeweils angeben, was geprüft wurde. Dass ein Werkzeug ausgeführt wurde, beantwortet für mich noch nicht, ob die konkrete Untersuchungsfrage ausreichend geprüft ist.
Bei Tests interessiert mich, welches Verhalten sie tatsächlich absichern. Eine hohe Abdeckung allein belegt keine hohe Codequalität. Deshalb gehört zu einer wichtigen Aussage auch die Frage, ob passende Eingaben, Fehlerpfade und Erwartungen geprüft werden. (Microsoft zu Testqualität)
Für Abhängigkeiten reicht es ebenfalls nicht, nur die unmittelbar eingebundenen Bibliotheken anzuschauen. In einer .NET-Anwendung können diese weitere Pakete einbinden. Welche Versionen dadurch tatsächlich verwendet werden, gehört in die Untersuchung. (Microsoft zu direkten und transitiven Paketen)
Ein gemeldeter Risikohinweis braucht anschließend einen Systembezug. Relevant sind die betroffene Komponente, ihr Einsatz und die mögliche Auswirkung. Was davon noch ungeprüft ist, muss im Ergebnis stehen bleiben.
Einen Befund für andere nachvollziehbar machen
Ein guter Befund lässt sich mit den vereinbarten Daten und dem dokumentierten Prüfweg nachvollziehen. Dafür brauche ich keine möglichst umfangreiche Sammlung von Screenshots. Ich brauche eine klare Verbindung zwischen Frage, Beobachtung und Schlussfolgerung.
Vor der Untersuchung sollten deshalb diese Informationen bereitstehen: betroffene Repositories und Releases, relevante Architekturunterlagen, Build- und Testkonfigurationen, bekannte Fehlerbilder und die zuständigen Ansprechpersonen. Zugriffsrechte und Vertraulichkeit werden vorher abgestimmt. Im Bericht sollten keine Geheimnisse oder unnötigen personenbezogenen Daten landen.
Für jeden priorisierten Befund halte ich die verwendete Quelle, den Versionsstand, die Prüfung, die beobachtete Abweichung und die Aussagegrenze fest. Daraus lässt sich ein nächster Schritt ableiten: ein reproduzierbarer Test, eine zusätzliche Prüfung oder eine abgegrenzte Änderung.
Wenn die Ursache mit den verfügbaren Daten offenbleibt, gehört genau das ins Ergebnis. Eine Repository-Analyse belegt das beobachtete Verhalten einer laufenden Umgebung nicht automatisch. Laufzeituntersuchungen müssen als eigener Umfang vereinbart werden.
Welche Fragen dein Bericht beantworten sollte
- Auf welche Version und welche Daten bezieht sich der Befund?
- Was wurde beobachtet, und wie lässt es sich nachvollziehen?
- Welche Erklärung ist belegt, welche bleibt eine Hypothese?
- Unter welchen Bedingungen entsteht daraus ein relevantes Risiko?
- Welche Informationen fehlen noch für eine Entscheidung?
- Welcher nächste Schritt ist begründet, und wie wird sein Ergebnis geprüft?
Diese Fragen bestimmen auch mein Forensic Code Assessment. Technologien, Untersuchungsfragen und Analysetiefe werden vorab abgeglichen. Die Untersuchung liefert eine technische Entscheidungsgrundlage; eine spätere Umsetzung ist gesondert zu vereinbaren.
Für eine Geschäftsentscheidung möchte ich am Ende sehen, welche Aussage ausreichend getragen ist und wo eine weitere Prüfung nötig wird. Dann lässt sich begründen, warum ein Bereich zuerst stabilisiert, eine Änderung abgesichert oder eine Annahme vor einer größeren Investition noch untersucht werden sollte.