Projekt-Smells: Oder lose Gedanken darüber, wonach man im Code-Entwicklungsprozess streben sollte

Der Autor, Mateusz Gorski, reflektiert über den Wechsel zwischen Entwicklungsteams und die Praktiken, die gut gepflegte Codebasen von schlecht funktionierenden unterscheiden.

Warum dieser Artikel

Nach dem Beitritt zu einem neuen Team erkannte der Autor, dass zuvor als selbstverständlich angesehene Praktiken nicht universell auf alle Projekte anwendbar sind. Anstatt bestehende Ansätze zu verurteilen, untersucht dieser Beitrag „Smells" – Warnsignale, die es wert sind, untersucht zu werden – die auf Entwickler in jeder Karrierephase anwendbar sind.

Tests

Testen erweist sich als die kritischste Praxis. Gut geschriebene Tests dienen als lebende Dokumentation für Neulinge. Der Autor betont beschreibende Testbenennung, wie „test_raises_validation_error_when_incorrect_country_code_provided" anstelle generischer Labels wie „test_fails".

Weitere Testüberlegungen umfassen das Verständnis von Dependency Injection für die Testbarkeit, die Behandlung von Testcode mit denselben Qualitätsstandards wie Produktionscode und das Streben nach umfassender Abdeckung (sogar 100% ist erreichbar). Integrationstests über mehrere Schichten – die Validierung von API-Endpunkten zusammen mit Datenbankergebnissen – verhindert starre Code-Architekturen, die einzelne Funktionen übermäßig testen.

Abhängigkeiten zwischen Modulen

Der Beitrag diskutiert die Dependency Rule: Innere Architekturschichten sollten nicht auf äußere angewiesen sein. Das Vermeiden zirkulärer Importe stärkt die Wartbarkeit. Kapselung auf Modulebene entspricht Prinzipien auf Klassenebene.

Programmierframeworks

Entwickler sollten Designmuster erkennen, die ihre Frameworks auferlegen, und anerkennen, dass der Standard eines Frameworks das Anti-Pattern eines anderen sein kann.

Meetings und SCRUM

Zu viele Meetings verbrauchen Ressourcen. SCRUM sollte Teams ermöglichen, nicht gefangen nehmen. Story-Point-Schätzungen sind nicht universell notwendig.

Fazit

Code dient letztendlich Geschäftszwecken. Bei Reviews müssen Entwickler widerstehen, davon auszugehen, dass ihr Ansatz der einzig gültige ist.