Technical Debt in Android-Projekten

Technical Debt bedeutet, dass du heute eine technische Abkürzung nimmst und dafür später Wartungsaufwand bezahlst. In Android-Projekten passiert das oft unter echtem Druck: ein Release steht an, ein Bug betrifft viele Nutzer, eine Compose-UI muss schnell fertig werden, oder eine API ist noch nicht stabil. Entscheidend ist nicht, jede Abkürzung zu vermeiden. Entscheidend ist, sie zu erkennen, ihren Preis zu verstehen und sauber festzuhalten, warum sie vorerst akzeptabel ist oder wann sie nachgearbeitet werden muss.

Was ist das?

Technical Debt ist eine Metapher für technische Schulden. Du bekommst kurzfristig Geschwindigkeit, nimmst aber langfristig Kosten in Kauf. Diese Kosten zeigen sich als schwer verständlicher Code, fragile Tests, doppelte Logik, langsame Builds, riskante Releases oder kleine Änderungen, die unerwartet viele Dateien betreffen.

Wichtig ist die Unterscheidung: Technical Debt ist nicht einfach jeder Fehler und nicht jeder unschöne Code. Eine bewusste Abkürzung kann sinnvoll sein, wenn sie transparent ist. Beispiel: Du baust für einen Prototypen eine lokale Liste direkt im ViewModel, statt sofort Repository, Datenquelle und Cache-Schicht aufzubauen. Wenn klar ist, dass der Prototyp verworfen oder später erweitert wird, kann das angemessen sein. Wenn diese Lösung aber ungeprüft in die Produktiv-App wandert, wird daraus ein Wartungsproblem.

Im Android-Kontext betrifft Technical Debt oft Architekturgrenzen. Moderne Android-Entwicklung mit Kotlin, Jetpack, Compose, Coroutines und Architecture Components lebt davon, dass Zuständigkeiten klar bleiben. UI-Code sollte UI-Zustand anzeigen, ViewModels sollten Logik für den Bildschirm bündeln, Repositories sollten Datenquellen kapseln, und Tests sollten kritisches Verhalten absichern. Technical Debt entsteht, wenn diese Grenzen aus Zeitgründen verwischt werden und niemand festhält, warum.

Das mentale Modell für Einsteiger ist einfach: Eine Abkürzung ist wie ein geliehener Baustein. Du darfst ihn verwenden, aber du musst wissen, wo er liegt, warum er dort liegt und was passiert, wenn du später darauf weiterbaust. Je mehr Features du auf einer unklaren Stelle stapelst, desto teurer wird die Korrektur.

Wie funktioniert es?

Technical Debt entsteht meistens nicht in einem einzelnen großen Moment. Sie wächst durch viele kleine Entscheidungen. Eine Abfrage wird schnell direkt in einer Composable-Funktion eingebaut. Ein Fehlerzustand wird nicht modelliert, weil die Demo nur den Erfolgsfall zeigt. Ein Repository gibt rohe DTOs weiter, weil das Mapping gerade lästig wirkt. Ein Test wird übersprungen, weil der Fix dringend ist. Jede Entscheidung kann lokal nachvollziehbar sein. Das Risiko entsteht, wenn diese Entscheidungen unsichtbar bleiben.

In der täglichen Android-Arbeit gibt es typische Formen:

Architektur-Schulden

Architektur-Schulden entstehen, wenn Zuständigkeiten nicht sauber getrennt sind. Ein häufiger Fall ist Geschäftslogik in der UI. Compose macht es leicht, schnell sichtbare Ergebnisse zu bauen. Wenn du aber Formatierung, Datenfilterung, Netzwerkentscheidungen und Fehlerbehandlung direkt in Composables packst, wird die UI schwer testbar. Außerdem wird jede Design-Änderung riskanter, weil sie ungewollt Logik berühren kann.

Der Android Architecture Guide betont, dass eine App von klaren Schichten profitiert. Diese Schichten sind kein Selbstzweck. Sie helfen dir, Änderungen zu begrenzen. Wenn ein API-Endpunkt wechselt, sollte nicht jede Composable-Funktion angepasst werden müssen. Wenn du diese Trennung bewusst verschiebst, solltest du das sichtbar machen.

Test-Schulden

Test-Schulden entstehen, wenn kritisches Verhalten nicht automatisiert geprüft wird. Nicht jeder Button braucht sofort einen großen UI-Test. Aber wenn Login, Zahlungsstatus, Offline-Verhalten oder Datenmigrationen ohne Tests bleiben, zahlst du bei jeder Änderung mit Unsicherheit. In Android-Projekten ist das besonders spürbar, weil UI, Lifecycle, Persistenz und Netzwerk schnell zusammenspielen.

Ein typisches Zeichen für Test-Schulden ist dieser Satz: “Bitte ändere dort nichts, das ist empfindlich.” Empfindlich bedeutet oft: Niemand weiß sicher, was kaputtgeht. Tests sind dann nicht nur Qualitätswerkzeug, sondern Dokumentation des erwarteten Verhaltens.

Release-Schulden

Release-Schulden entstehen, wenn du kurzfristig manuelle Schritte akzeptierst. Vielleicht muss vor jedem Release eine Konstante angepasst werden. Vielleicht steht eine wichtige ProGuard- oder R8-Regel nur in einem Chat. Vielleicht ist nicht klar, welche Feature-Flags aktiv sein sollen. Solche Schulden sind gefährlich, weil sie oft erst unter Zeitdruck auffallen.

Bei Android kommt dazu, dass viele Varianten existieren können: Debug, Release, unterschiedliche Build Flavors, verschiedene API-Level und Geräteklassen. Was auf deinem Gerät funktioniert, kann im Release-Build anders aussehen. Wenn du hier Abkürzungen nimmst, brauchst du klare Notizen und möglichst bald eine Automatisierung.

Wartungs-Schulden

Wartungs-Schulden sind die Summe aus kleinen Reibungen: veraltete Dependencies, uneinheitliche Namensgebung, kopierte Hilfsfunktionen, unklare Modulgrenzen oder lange Klassen. Sie blockieren dich selten sofort. Aber sie verlangsamen jedes neue Feature. Für Junior-Devs ist das oft schwer zu erkennen, weil der Code noch “funktioniert”. Wartbarkeit ist jedoch mehr als Laufzeitverhalten. Wartbarer Code lässt sich ändern, erklären, testen und zurückbauen.

Ein gutes Team behandelt Technical Debt deshalb nicht als moralisches Urteil. Es fragt nüchtern: Was kostet uns diese Stelle heute? Was kostet sie in drei Monaten? Wer ist betroffen? Gibt es einen klaren Plan?

In der Praxis

Stell dir vor, du baust eine einfache Aufgabenliste in Compose. Für die erste Version schreibst du die Filterlogik direkt in die Composable-Funktion, weil du schnell zeigen willst, dass erledigte Aufgaben ausgeblendet werden können.

@Composable
fun TaskListScreen(
    tasks: List<Task>,
    showDone: Boolean
) {
    val visibleTasks = tasks.filter { task ->
        showDone || !task.isDone
    }

    LazyColumn {
        items(visibleTasks) { task ->
            Text(text = task.title)
        }
    }
}

Für eine kleine Demo ist das vertretbar. Die Logik ist kurz, rein lokal und leicht zu lesen. In einer wachsenden App kann daraus aber Debt werden. Sobald mehrere Screens dieselbe Filterung brauchen, sobald Sortierung dazukommt oder sobald Tests für die Filterregeln wichtig werden, gehört diese Entscheidung nicht mehr still in die UI.

Eine bessere produktive Variante wäre, den UI-Zustand im ViewModel vorzubereiten und die Composable nur anzeigen zu lassen, was sie bekommt.

data class TaskListUiState(
    val visibleTasks: List<TaskUiItem>,
    val showDone: Boolean,
    val isLoading: Boolean,
    val errorMessage: String?
)

class TaskListViewModel(
    private val repository: TaskRepository
) : ViewModel() {

    private val showDone = MutableStateFlow(false)

    val uiState: StateFlow<TaskListUiState> =
        combine(repository.tasks, showDone) { tasks, showDone ->
            TaskListUiState(
                visibleTasks = tasks
                    .filter { showDone || !it.isDone }
                    .map { TaskUiItem(id = it.id, title = it.title) },
                showDone = showDone,
                isLoading = false,
                errorMessage = null
            )
        }.stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5_000),
            initialValue = TaskListUiState(
                visibleTasks = emptyList(),
                showDone = false,
                isLoading = true,
                errorMessage = null
            )
        )

    fun setShowDone(value: Boolean) {
        showDone.value = value
    }
}

Diese Version ist nicht automatisch immer besser. Sie ist ausführlicher und bringt mehr Struktur mit. Der Punkt ist der Tradeoff: Wenn die App wächst, hilft diese Struktur bei Tests, Wiederverwendung und Wartung. Wenn du nur eine Lernübung baust, kann sie zu viel sein. Technical Debt erkennst du also nicht nur am Code, sondern am Kontext.

Eine praktische Regel lautet: Wenn eine Abkürzung eine Architekturregel verletzt, notiere den Grund und den Auslöser für die Nacharbeit. Der Auslöser muss konkret sein. Nicht “später verbessern”, sondern zum Beispiel: “In ein Repository verschieben, sobald ein zweiter Screen dieselben Daten braucht” oder “Test ergänzen, bevor der Fehlerzustand geändert wird”.

So kann eine kurze Notiz in einem Issue aussehen:

Titel: Filterlogik aus TaskListScreen herausziehen

Kontext:
Für den Prototypen wird die Filterung direkt im Screen berechnet,
damit die Compose-Ansicht schnell testbar bleibt.

Risiko:
Bei weiterer Filter- oder Sortierlogik wird der Screen schwerer
zu testen und die Logik kann in anderen Screens kopiert werden.

Nacharbeit:
In ViewModel oder Use-Case verschieben, sobald ein zweiter Screen
dieselbe Filterregel nutzt oder Sortierung ergänzt wird.

Diese Art Dokumentation schützt dich vor zwei typischen Fehlern. Der erste Fehler ist Perfektionismus: Du versuchst, jede mögliche spätere Anforderung schon heute abzudecken. Dadurch wird der Code schwerer, bevor das Problem wirklich existiert. Der zweite Fehler ist Verdrängung: Du baust schnell etwas ein und hoffst, dass niemand die Stelle wieder anfassen muss. Beide Extreme kosten Qualität.

Eine weitere Stolperfalle ist falsche Priorisierung. Nicht jede technische Schuld ist gleich dringend. Eine duplizierte Formatierungsfunktion in zwei kleinen Screens ist meist weniger kritisch als ein ungetesteter Datenverlust bei einer Migration. Bewerte Debt nach Risiko, Häufigkeit und Änderungsnähe. Frag dich: Wie oft berühren wir diesen Code? Was passiert bei einem Fehler? Blockiert die Stelle neue Arbeit? Gibt es Nutzerwirkung?

Im Code-Review kannst du Technical Debt sachlich ansprechen. Statt “Das ist schlecht” schreibst du besser: “Diese Logik liegt aktuell in der Composable. Für den Release ist das nachvollziehbar. Bitte ein Issue anlegen, weil dieselbe Regel voraussichtlich im Detail-Screen gebraucht wird.” So bleibt der Review konkret und lösungsorientiert.

Auch Tests helfen dir beim Erkennen. Wenn du eine kleine Änderung machst und dafür viele manuelle Klickpfade prüfen musst, ist das ein Signal. Wenn du eine Funktion nicht isoliert testen kannst, weil sie direkt Android-Framework, UI und Netzwerk mischt, ist das ebenfalls ein Signal. Nutze solche Reibung nicht nur als Ärgernis, sondern als Hinweis auf Wartungskosten.

Fazit

Technical Debt gehört zu echter Android-Entwicklung, aber sie darf nicht unsichtbar werden. Du solltest Abkürzungen bewusst wählen, den Tradeoff benennen und eine klare Nacharbeitsbedingung festhalten. Prüfe dein Verständnis praktisch: Nimm einen eigenen Screen, suche eine Stelle mit schneller Lösung, formuliere Risiko und Nacharbeit in drei Sätzen, und bespreche sie im Code-Review oder sichere das Verhalten mit einem kleinen Test ab.