Code Review auf Java: Worauf man in fremdem Code achten sollte

Warum Code Review nicht über Kritik, sondern über Qualität geht

Stellen Sie sich vor: Sie öffnen einen Pull-Request eines Kollegen. Da sind 500 Zeilen Code, es riecht nach Copy-Paste, und an einer Stelle hat jemand vergessen, eine Ressource zu schließen. Ihre Aufgabe ist es, nicht nur Bugs zu finden, sondern den Code besser zu machen. Code Review auf Java ist keine Polizeiaufsicht, sondern gemeinsame Kreativarbeit. Ein guter Reviewer rettet das Team vor technischen Schulden, ein schlechter demotiviert oder übersieht Sicherheitslücken.

In diesem Artikel erkläre ich, was man im Code Review auf Java prüfen sollte, um keine Zeit mit Kleinigkeiten zu verschwenden, aber nichts Kritisches zu übersehen. Sie erhalten eine fertige Checkliste und Beispiele aus der Praxis.

Architektur und Design: An die Wurzel gehen

Bevor Sie in die Details eintauchen, bewerten Sie das Gesamtbild. Schlechte Architektur lässt sich nicht durch Formatierung heilen.

Verstoß gegen SOLID

Prüfen Sie, ob sich die Klasse nicht in ein „göttliches Objekt" verwandelt hat. Beispiel für einen Verstoß gegen Single Responsibility:

public class OrderService {\n    public void createOrder(Order order) {\n        // Validierung\n        // Rabattberechnung\n        // E-Mail-Versand\n        // Logging\n        // Speichern in der DB\n    }\n}\n

Hier gibt es fünf Gründe für eine Änderung. Richtig wäre, das Logging und den Versand in separate Dienste auszulagern.

Übermäßige Komplexität

Manchmal löst Code eine einfache Aufgabe auf komplizierte Weise. Fragen Sie sich: „Geht es einfacher?" Wenn ja, schreiben Sie es ins Review. Denken Sie an das KISS-Prinzip.

Sicherheit: Lücken, die man nicht übersehen darf

Java Code Review muss die Sicherheitsprüfung einschließen. Auch wenn das Projekt intern ist.

SQL-Injection

Zeichenkettenverkettung ist böse:

// SCHLECHT\nString query = "SELECT * FROM users WHERE name = '" + userName + "'";\nStatement stmt = connection.createStatement();\nResultSet rs = stmt.executeQuery(query);\n

Richtig ist die Verwendung von PreparedStatement:

// GUT\nString query = "SELECT * FROM users WHERE name = ?";\nPreparedStatement pstmt = connection.prepareStatement(query);\npstmt.setString(1, userName);\nResultSet rs = pstmt.executeQuery();\n

Preisgabe sensibler Daten

Prüfen Sie, ob Passwörter, Token oder Kreditkartennummern geloggt werden. Verwenden Sie @ToString.Exclude in Lombok oder explizites Ignorieren.

Unsicherer Objektvergleich

// SCHLECHT (Referenzvergleich)\nif (password == storedPassword) { ... }\n// GUT\nif (password.equals(storedPassword)) { ... }\n

Leistung: Engpässe

Optimieren Sie nicht vorzeitig, aber übersehen Sie auch keine offensichtlichen Bremsen.

Überflüssige Operationen in Schleifen

// SCHLECHT: length() wird jedes Mal aufgerufen\nfor (int i = 0; i < list.size(); i++) { ... }\n// GUT\nint size = list.size();\nfor (int i = 0; i < size; i++) { ... }\n

Verwendung von Streams für einfache Aufgaben

Manchmal ist eine normale Schleife lesbarer und schneller:

// Überflüssig\nlist.stream().filter(x -> x > 5).collect(Collectors.toList());\n// Einfach\nList<Integer> result = new ArrayList<>();\nfor (int x : list) {\n    if (x > 5) result.add(x);\n}\n

Speicherleck

Prüfen Sie, ob vergessen wurde, InputStream, Connection oder Session zu schließen. Verwenden Sie try-with-resources:

try (Connection conn = getConnection();\n     PreparedStatement stmt = conn.prepareStatement(sql)) {\n    // Arbeit\n} catch (SQLException e) {\n    log.error("DB-Fehler", e);\n}\n

Lesbarkeit und Stil: Code wie ein Buch

Code Review Checkliste beinhaltet unbedingt die Lesbarkeit. Code wird einmal geschrieben, aber Dutzende Male gelesen.

Magische Zahlen und Zeichenketten

// SCHLECHT\nif (status == 3) { ... }\n// GUT\nprivate static final int STATUS_COMPLETED = 3;\nif (status == STATUS_COMPLETED) { ... }\n

Lange Me