Code Review Basics

Code Reviews sind ein Werkzeug, mit dem du Android-Code vor dem Merge fachlich prüfst: Funktioniert das Verhalten, ist der Code wartbar, sind Tests sinnvoll, und entsteht für Nutzerinnen und Nutzer kein unnötiges Risiko? Für Lernende ist das wichtig, weil du dabei nicht nur Fehler findest, sondern auch lernst, wie gute Kotlin-, Jetpack- und Compose-Entscheidungen im Alltag aussehen.

Was ist das?

Code Review Basics bedeuten: Du prüfst eine Änderung systematisch, bevor sie Teil des Hauptbranches wird. Dabei geht es nicht darum, jede persönliche Vorliebe durchzusetzen. Ein Review soll klären, ob der Code korrekt ist, ob er zur bestehenden Architektur passt, ob er gut gelesen und geändert werden kann und ob die App dadurch stabiler oder zumindest nicht schlechter wird.

Im Android-Kontext betrifft das viele Ebenen. Eine kleine Änderung in einer Composable kann das UI-Verhalten beeinflussen. Eine Anpassung im ViewModel kann den State-Fluss verändern. Ein neuer Repository-Aufruf kann Threading, Fehlerbehandlung, Offline-Verhalten oder Tests berühren. Deshalb reicht es nicht, nur nach Formatierung oder Variablennamen zu suchen. Du prüfst zuerst die Absicht der Änderung: Welches Problem soll gelöst werden? Danach prüfst du die Umsetzung: Belegt der Code diese Absicht nachvollziehbar?

Das mentale Modell ist einfach: Ein Pull Request ist eine Behauptung. Er behauptet, dass ein bestimmtes Verhalten nun korrekt implementiert ist. Dein Review sucht Belege für diese Behauptung. Diese Belege können Tests, klare Zustandsmodelle, verständlicher Code, saubere Fehlerpfade, Screenshots, manuelle Testhinweise oder ein überschaubarer Diff sein. Je größer die Änderung, desto stärker sollten die Belege sein.

Gutes Feedback ist dabei konkret. Statt „das ist unübersichtlich“ schreibst du besser: „Die Fehlerbehandlung liegt hier in der Composable. Kannst du sie ins ViewModel verschieben, damit UI und Geschäftslogik getrennt bleiben?“ So bleibt dein Kommentar prüfbar und lösungsorientiert.

Wie funktioniert es?

Ein Review funktioniert am besten in Schichten. Zuerst prüfst du Verhalten und Nutzerwirkung. Danach schaust du auf Architektur, Tests, Lesbarkeit und Wartbarkeit. Diese Reihenfolge schützt dich vor einem häufigen Fehler: Du verbringst viel Zeit mit Stilfragen, während ein echter Logikfehler unbemerkt bleibt.

Bei Verhalten fragst du: Was ändert sich für die Person, die die App nutzt? Werden Ladezustände, Fehlerzustände und leere Zustände richtig behandelt? Gibt es Auswirkungen auf Navigation, Berechtigungen, Barrierefreiheit oder Performance? In Compose heißt das zum Beispiel: Wird UI aus State abgeleitet, oder werden Seiteneffekte an einer Stelle ausgelöst, die bei Recomposition mehrfach laufen kann?

Bei Architektur prüfst du, ob Verantwortlichkeiten getrennt bleiben. Moderne Android-Apps profitieren davon, wenn UI, State-Handling, Datenzugriff und Geschäftsregeln nicht vermischt werden. Das bedeutet nicht, dass jede Änderung viele Schichten braucht. Es bedeutet, dass du erkennst, wo Code künftig geändert oder getestet werden muss. Ein ViewModel sollte UI-State vorbereiten, ein Repository sollte Datenzugriff kapseln, und eine Composable sollte möglichst beschreiben, wie der aktuelle State dargestellt wird.

Tests sind ein weiterer Review-Anker. Du musst nicht für jede Zeile einen Test verlangen. Du solltest aber fragen, ob der wichtigste neue Pfad abgesichert ist. Wenn eine Funktion Preise berechnet, Login-Regeln ändert oder Fehlerzustände behandelt, ist ein Unit-Test oft angemessen. Wenn ein UI-Zustand kritisch ist, kann ein Compose-Test oder ein Screenshot im Review helfen. Androids Testing-Grundlagen betonen nicht zufällig, dass Tests Vertrauen in Verhalten schaffen. Im Review übersetzt du das in eine praktische Frage: Welche Art von Fehler würde diese Änderung wahrscheinlich verursachen, und gibt es dagegen einen Beleg?

Lesbarkeit ist ebenfalls fachlich relevant. Wartbarer Code ist Code, den du in drei Monaten noch ändern kannst, ohne erst die gesamte App neu zu verstehen. Gute Namen, kleine Funktionen, klare State-Modelle und einfache Kontrollflüsse sind kein Schmuck. Sie reduzieren Fehlerkosten. Ein Review darf deshalb Lesbarkeit ansprechen, sollte aber zwischen Muss und Geschmack unterscheiden. „Bitte benenne x um“ ist schwächer als „isAllowed ist hier unklar, weil nicht erkennbar ist, ob es um Login, Netzwerk oder Feature-Freigabe geht.“

In der Praxis

Stell dir vor, ein Pull Request fügt einer Profilseite einen Ladezustand hinzu. Die Composable zeigt bisher direkt den Namen an. Neu kommt ein ProfileUiState, der zwischen Laden, Inhalt und Fehler unterscheidet. Ein guter Review schaut nicht nur, ob der Code kompiliert. Du prüfst, ob alle Zustände sichtbar abgebildet sind, ob das ViewModel den State kontrolliert und ob ein Test mindestens den wichtigsten Übergang absichert.

sealed interface ProfileUiState {
    data object Loading : ProfileUiState
    data class Content(val name: String) : ProfileUiState
    data class Error(val message: String) : ProfileUiState
}

@Composable
fun ProfileScreen(
    state: ProfileUiState,
    onRetry: () -> Unit
) {
    when (state) {
        ProfileUiState.Loading -> CircularProgressIndicator()
        is ProfileUiState.Content -> Text(text = state.name)
        is ProfileUiState.Error -> Button(onClick = onRetry) {
            Text(text = state.message)
        }
    }
}

In einem Review könntest du hier mehrere sinnvolle Punkte prüfen. Ist die Fehlermeldung für Nutzer verständlich, oder wird eine technische Exception angezeigt? Ist onRetry stabil angebunden und testbar? Wird der State im ViewModel erzeugt, statt Netzwerklogik in die Composable zu ziehen? Gibt es einen Test, der sicherstellt, dass bei einem Repository-Fehler wirklich ProfileUiState.Error entsteht?

Eine praktische Entscheidungsregel lautet: Kommentiere zuerst alles, was Verhalten, Datenverlust, Abstürze, Sicherheit, Datenschutz, Tests oder Architektur betrifft. Danach kommen Lesbarkeit und Vereinfachung. Reine Stilfragen solltest du nur ansprechen, wenn sie im Projektstandard verankert sind oder die Verständlichkeit wirklich stören. Nutze für Kleinigkeiten Formulierungen wie „nit:“ oder „optional:“, damit dein Gegenüber erkennt, dass der Merge nicht daran hängen muss.

Eine typische Stolperfalle ist das Review als persönliche Bewertung. Gerade als Anfänger fühlt sich Feedback schnell wie Kritik an deiner Fähigkeit an. Technisch ist ein Review aber ein Qualitätsprozess für den Code, nicht für deinen Wert als Entwickler. Wenn du Reviews gibst, formuliere daher beobachtbar: „Dieser Flow kann mehrfach gesammelt werden, wenn die Composable neu gestartet wird.“ Wenn du Reviews bekommst, frage nach dem Risiko: „Welcher Fehler kann dadurch auftreten?“ So wird die Diskussion fachlich.

Eine zweite Stolperfalle ist ein zu großer Pull Request. Wenn ein Diff Datenmodell, Navigation, UI, Tests und Refactoring gleichzeitig ändert, wird Review-Qualität schlechter. Teile Änderungen lieber so, dass jede Review-Runde eine klare Frage beantwortet: erst Modell, dann Verhalten, dann UI. Das macht Feedback präziser und reduziert Nacharbeit.

Fazit

Code Review Basics helfen dir, Android-Code nicht nur nach Geschmack, sondern nach Wirkung zu bewerten: korrektes Verhalten, passende Tests, klare Architektur, lesbare Umsetzung und geringe Risiken für Nutzer. Übe das aktiv, indem du bei deinem nächsten Pull Request eine kurze Checkliste verwendest: Was ändert sich im Verhalten, wie ist es getestet, welche Schicht trägt welche Verantwortung, und welche Stelle wird in sechs Monaten schwer zu ändern sein? Öffne den Debugger, lies die Tests, starte die betroffene App-Stelle und schreibe Feedback so, dass dein Gegenüber direkt handeln kann.