Vorbereitung auf das Review · Leitfaden 02
So bereiten Sie sich auf ein Architektur- oder Code-Review vor
Die kurze Antwort
Bringen Sie eine Entscheidung, eine klare Systemgrenze und die kleinste Menge an Belegen mit, die die Frage beantworten kann. Ein nützliches Review beginnt mit dem, was das System leisten muss und wo Sie unsicher sind, und untersucht dann die relevante Architektur oder den relevanten Code. Eine Einladung ins Repository allein ist kein Review-Briefing.
Aus der Sorge eine Review-Frage machen
„Ist unsere Architektur gut?“ lässt den Reviewer über Ihre Prioritäten rätseln. Stellen Sie eine Frage, die eine Entscheidung ändern kann: Kann diese Integration die nächste Kundenanforderung tragen, in welchem Zustand hinterlässt eine fehlgeschlagene Zahlung die Bestellung, oder was muss vor einer Migration geklärt werden? Nennen Sie die Systemversion und die Entscheidungsfrist.
Listen Sie auf, was das Review nicht abdeckt. Eine fokussierte Besprechung kann nicht belegen, dass jede Komponente sicher ist, jeder Fehlerfall getestet wurde oder das ganze Produkt startklar ist. Eine umfassendere Absicherung erfordert einen separat vereinbarten Umfang und entsprechende Belege.
Ein kleines Paket an Belegen zusammenstellen
- Eine Systemkarte: Nutzer, Services, Datenspeicher und externe Integrationen, die für die Frage relevant sind.
- Ein repräsentativer Ablauf: der normale Weg, der Fehlerweg und wer die Wiederherstellung übernimmt.
- Rahmenbedingungen: erwartete Last, Antwortzeitziele, Budget, Sensibilität der Daten und Teamkapazität; kennzeichnen Sie Schätzungen als Schätzungen.
- Ausgewählte Belege: relevante Codepfade, Tests, bereinigte Fehlermeldungen oder Diagramme, mit Datum und Version.
- Entscheidungshistorie: geprüfte Alternativen, Annahmen und der Grund für den aktuellen Ansatz.
arc42 grenzt ein System von seinen externen Nutzern und Nachbarsystemen ab und beschreibt dann die Schnittstellen zwischen ihnen. Das ist eine nützliche Struktur für ein Review-Diagramm, auch wenn Sie nicht die vollständige Dokumentationsvorlage verwenden. arc42: Kontextabgrenzung.
Wählen Sie für ein Code-Review die Änderung oder den Pfad, der die Frage betrifft. Die Review-Richtlinien von Google gehen über den Stil hinaus und betrachten Design, beabsichtigtes Verhalten, unnötige Komplexität und Tests. Liefern Sie genug Kontext, damit sich diese Punkte bewerten lassen. Google: Worauf man in einem Code-Review achten sollte.
Auch etwas Unbekanntes ist ein nützlicher Befund. Wenn niemand die aktuelle Spitzenlast kennt oder weiß, ob sich ein Backup wiederherstellen lässt, sagen Sie es. Ein Reviewer kann eine fehlende Messung von einem nachgewiesenen Systemfehler unterscheiden; wird die Lücke stillschweigend mit einer selbstbewussten Schätzung gefüllt, wird das schwieriger.
Zugang und Vorablektüre vor dem Teilen vereinbaren
Beginnen Sie eine Anfrage mit einer nicht vertraulichen Beschreibung. Fügen Sie keine Passwörter, Tokens, Kundendaten oder Inhalte privater Repositories in ein öffentliches Kontaktformular ein. Wenn der Auftrag private Unterlagen erfordert, vereinbaren Sie zuerst Umfang, Zugangsweg und zulässige Nutzung. Bevorzugen Sie die kleinste relevante, geschwärzte Menge an Belegen und, wo angemessen, reinen Lesezugriff.
Fragen Sie, was im Rahmen des Auftrags realistisch gelesen werden kann. Ein großes Repository unmittelbar vor einer Session zu schicken, begründet keine Vereinbarung über ein vollständiges Audit. Bestätigen Sie Vorablektüre, Einrichtung von Zugängen und ein schriftliches Ergebnis ausdrücklich; gehen Sie nicht davon aus, dass sie enthalten sind, nur weil ein Termin vereinbart ist.
Befunde für das Team nutzbar machen
Bitten Sie den Reviewer, beobachtete Fakten, wahrscheinliche Erklärungen und offene Fragen zu trennen. Für jedes wesentliche Problem muss das Team das betroffene Verhalten, die stützenden Belege und die nächste Maßnahme verstehen. Die Priorität sollte die geschäftlichen Folgen und die Sicherheit des Befunds widerspiegeln, nicht wie angesagt eine Ersatztechnologie ist.
- Bestätigen Sie, auf welche Systemversion und welche Belege sich der Befund bezieht.
- Benennen Sie die Person, die den Befund untersucht, akzeptiert oder behebt.
- Legen Sie fest, wie das Team prüft, ob eine Änderung das relevante Problem gelöst hat.
- Halten Sie nicht geprüfte Bereiche und verbleibende Unsicherheit in der Übergabe sichtbar.
Das Architektur- & Code-Review von Robles Consulting ist eine fokussierte Session von 120 Minuten. Eine größere Bewertung mit vereinbarten Belegen und einem schriftlichen Ergebnis gehört in ein Architektur-Audit. Nutzen Sie die Angebotsdetails, um den richtigen Umfang zu wählen, bevor Sie die Verfügbarkeit anfragen.
Nächster Schritt
Den richtigen Umfang finden.
Beschreiben Sie zuerst die Entscheidung und die Systemgrenze. Das Review-Angebot erklärt Vorbereitung und Grenzen; größere Bewertungen werden separat abgegrenzt.