Code-Review-Tools und Methoden: Wie prüfen wir den von der Agentur übergebenen Code?

Schaut bei SAST-Tools nicht nur auf Coding-Standards, sondern vor allem auf Sicherheitsregeln. SQL-Injections, IDOR-Lücken und fehlende Eingabevalidierungen werden von Scannern sehr zuverlässig gefunden. Und prüft unbedingt die Test Coverage: Wenn die Agentur keine Unit-Tests geschrieben hat, wird jedes Refactoring später zur reinen Hölle.

Wir haben letztes Jahr ein mobiles Backend für 40.000 USD übernommen. Die automatischen Scanner waren alle grün, die Syntax war top. Zwei Wochen nach dem Go-live ist die Datenbank komplett in die Knie gegangen; die Agentur hatte in der relationalen DB weder Foreign Keys noch Indizes gesetzt. Sowas sieht kein automatisiertes Tool.

Wir haben bei der Übergabe 2.500 USD für ein 15-stündiges Deep-Dive-Review durch einen externen Senior-Architekten investiert. Der hat direkt 4 fatale Architekturfehler gefunden, die uns jede Skalierung blockiert hätten, plus 8 offene Berechtigungslücken. Das Geld hat sich mehr als gelohnt.

Lasst euch bei Agenturarbeiten nicht zu sehr von den Reports automatischer Tools blenden. Agenturen zerlegen Funktionen manchmal nur deshalb in zig Teile, damit die Analysetools keine Warnungen ausspucken und der Code nach außen hin sauber wirkt – aber die Business-Logik ist der reinste Spaghetti-Code. Solche Tools bestätigen nicht, ob der Code korrekt funktioniert, sondern nur, dass die Syntaxregeln eingehalten wurden.

Was ihr direkt morgen als Erstes machen könnt: Schaut euch die Versionshistorie (git log) des Repos an. Hat die Agentur die ganze Arbeit in den letzten 3 Tagen panisch reingepusht, oder lief das über 4 Monate hinweg mit regelmäßigen Commits und aussagekräftigen Messages? Eine saubere Versionsdisziplin sagt extrem viel über die innere Qualität des Codes aus.

Checkliste bei Agentur-Übergaben: 1) Wurden API-Keys externer Dienste hardcoded im Code vergessen? 2) Passen die Lizenzen der genutzten Open-Source-Bibliotheken zu eurer kommerziellen Nutzung? 3) Funktionieren Deployment und lokales Setup anhand einer einzigen, lückenlosen Dokumentation reibungslos?

schaut auf jeden fall nach ob tests geschrieben wurden und agenturen lassen unit tesst meistens weg mit der ausrede keine zeit gehabt und später änderst du eine zeile code und die ganze architektur bricht zusammen.

habt ein wenig Geduld mit eurem neuen Senior. fremden Code zu übernehmen ist für Entwwickler so ziemlich die frustrierendste Aufgabe der Welt. ehrlich gesagt automatische Tools helfen da zumindest, Diskussionen zu versachlichen und auf objektive Metriken zu stützen, statt es persönlich werden zu lassen.

Notiert, danke.

Mich interessiert das auch.

Bleibe dran.

Gut gemacht. Die Antwort hängt stark von der Branche ab, es gibt keine allgemeine Regel.

Nur als Notiz, könnte nützlich sein.

der billige Weg stellt sich oft im Nachhinein als teuer heraus. ehrlich gesagt schreibe bei Entscheidungen auch das Worst-Case-Szenario auf nicht nur das Beste.

wenn man versucht alles gleichzeitig zu ändern, etabliert sich nichts richtig. wenn ihr das Ergebnis hier postet, hilft es auch anderen.

Nach diesem Erlebnis hat sich meine Sichtweise geändert. Code ohne Installationsanleitung gehört dir nicht, auch wenn du ihn in den Händen hältst.

Wenn ihr das Ergebnis hier postet hilft es auch anderen.

Ich stimme zu.

Das hört man oft, aber bei uns war es nie so. Der Zahlungsplan sollte an die Projektphasen gekoppelt sein, nicht an den Kalender.

An deiner Stelle würde ich so vorgehen.

Ich habe diesen Weg schon hinter mir, ich erzähl mal. Ein wöchentlicher schriftlicher Fortschrittsbericht ist viel nützlicher als ständiges Nachfragen nach dem Status.

Bei uns ist es genauso. Wer bei code review tools hetzt, stolpert alle an derselben Stelle.

Beginnt mit einem kleinen Test, bindet nicht gleich alles fest. An deiner Stelle würde ich so vorgehen.