In den zwei vorherigen Teilen unserer Serie sprachen wir über die ersten Schritte im Entwicklerberuf und darüber, was man zu Beginn der Karriere wirklich lernen sollte.
Jetzt kommen wir zu dem Moment, vor dem sich fast jeder Junior fürchtet.
Das erste Code Review. Die ersten Kommentare zum Code. Die ersten Korrekturen.
Und der erste Gedanke: „Habe ich diesen Code wirklich SO schlecht geschrieben?“
Beruhige dich.
Jeder von uns ist da irgendwann durchgegangen.
Code Review ist keine Prüfung
Das ist wohl das größte Missverständnis unter angehenden Entwicklern.
Viele Juniors nehmen Kommentare zu ihrem Code sehr persönlich. Es entsteht Stress. Unsicherheit. Manchmal sogar Frustration.
Dabei ist das Ziel eines Code Reviews nicht, jemandem zu beweisen, dass er einen Fehler gemacht hat. Im Gegenteil. Es ist eines der wichtigsten Elemente des Prozesses, um gute Software zu erstellen.
Durch Code Reviews:
- reduzieren wir das Risiko von Fehlern,
- verbessern wir die Lesbarkeit des Codes,
- lernen wir voneinander,
- achten wir auf die Konsistenz des gesamten Projekts,
- geben wir Wissen zwischen Teammitgliedern weiter.
Die besten Teams sehen Code Reviews nicht als Kontrolle. Sie betrachten sie als täglichen Wissensaustausch.
„Du hast 37 Kommentare“
Klingt bedrohlich? Am Anfang schon.
Ein erster Pull Request sieht oft genau so aus:
- Kommentar.
- Änderung.
- Noch ein Kommentar.
- Weitere Änderung.
Nach einer Stunde hat man das Gefühl, der ganze Code sei Müll. Das ist normal.
Merke dir nur eins: Ein Senior ändert den Code nicht, um seine Überlegenheit zu zeigen. Er tut es, weil du in ein paar Monaten erheblich besseren Code schreiben wirst.
Und genau darum geht es.
Ein guter Senior sagt nicht nur „schlecht"
Die besten Entwickler, mit denen wir gearbeitet haben, erklärten immer:
- warum etwas anders gemacht werden sollte,
- welche Konsequenzen die aktuelle Lösung haben wird,
- welche Alternativen es gibt,
- welche Lösung in ein oder zwei Jahren leichter zu warten sein wird.
Das ist ein großer Unterschied.
Man kann sagen: „Das ist schlecht."
Oder man kann sagen: „Das funktioniert, aber wenn wir in sechs Monaten dieses Modul weiterentwickeln, wird es in dieser Struktur deutlich einfacher zu warten sein."
Im zweiten Fall lernst du etwas viel Wertvolleres als nur die Korrektur. Du lernst eine Denkweise.
Clean Code bedeutet nicht schöner Code
Das ist ein Begriff, der sehr oft falsch verstanden wird.
Clean Code bedeutet nicht, dass der Code spektakulär aussieht. Es geht nicht um die Anzahl leerer Zeilen. Es geht nicht um die Länge einer Funktion. Es geht nicht einmal um bestimmte Muster.
Es geht um etwas viel Einfacheres – der Code sollte lesbar sein.
Wenn du in sechs Monaten dein eigenes Projekt öffnest und dich nicht mehr erinnerst, was du gemeint hast...
...dann war der Code wahrscheinlich nicht ausreichend lesbar.
Es gibt ein Sprichwort: Code schreiben wir für Menschen. Der Compiler prüft nur die Syntax.
Und daran ist viel Wahrheit.
Verliebe dich nicht in deinen eigenen Code
Das ist eine der wichtigsten Lektionen.
Code ist kein Kunstwerk. Er ist kein Gemälde. Er ist keine Skulptur.
Er ist ein Werkzeug zur Lösung eines konkreten Problems.
Wenn jemand eine bessere Lösung vorschlägt...
...sollte man sie in Betracht ziehen.
Nicht, weil die Person mehr Autorität hat. Sondern weil die Lösung vielleicht wirklich besser ist.
Am meisten lernen diejenigen Entwickler, die sagen können: „Du hast recht. Machen wir es anders."
„Bei mir funktioniert's"
Okay. Wir müssen schließlich zu diesem bekannten Satz kommen. Jedes Software‑House hat seine Version dieses Witzes...
Stell dir die Situation vor.
Der Tester meldet einen Fehler.
Der Entwickler antwortet: „Bei mir funktioniert's."
Der Tester prüft noch einmal. – Es funktioniert nicht.
Der Project Manager schaut. – Es funktioniert nicht.
Auch der Kunde prüft. – Es funktioniert nicht.
Aber... beim Autor des Codes funktioniert es weiterhin.
Klingt bekannt?
Meistens liegt das Problem nicht am Code selbst.
Es kann viele Ursachen geben:
- andere Datenversion,
- andere Umgebung,
- Cache,
- Konfiguration,
- Berechtigungen,
- Browser,
- Betriebssystem,
- ein Fall, den vorher niemand vorhergesehen hat.
Deshalb hört ein professioneller Entwickler nicht bei dem Satz auf: „Bei mir funktioniert's."
Er stellt die nächste Frage.
Warum funktioniert es bei mir, aber anderswo nicht?
Und genau dann beginnt das echte Debugging.
„Das ist nur eine kleine Änderung"
Das ist ein weiterer Satz, der in den meisten Software‑Häusern ein leichtes Schmunzeln hervorruft.
Der Kunde sagt: „Das ist nur eine kleine Korrektur."
Der Entwickler weiß bereits, dass er gleich eine Datei öffnet, die seit sechs Jahren niemand mehr angefasst hat.
Und diese „kleine Korrektur" stellt sich als Änderung in fünf Modulen, drei Integrationen und zwei Datenbanken heraus.
Deshalb gehen erfahrene Entwickler dem Wort „nur" sehr vorsichtig gegenüber.
Die bekanntesten Sprüche aus der Branche
Jeder Beruf hat seine Redewendungen. Entwickler auch.
Einige davon kennt wohl jeder:
- „Bei mir funktioniert's."
- „Das dauert nur fünf Minuten."
- „Das ist kein Bug. Das ist ein Feature."
- „Ich habe ja nichts geändert."
- „Auf Produktion ist es zusammengebrochen."
- „Nur noch ein Deploy."
- „Das ist bestimmt der Cache."
- „Schnelle Korrektur vor dem Wochenende."
- „Das sollte funktionieren."
Und wohl das Gefährlichste: „Wir pushen das freitags nach 16:00 auf Produktion."
Wenn du in der IT arbeitest...
...hast du dabei wahrscheinlich gerade gelächelt.
Der Entwickler arbeitet nicht allein
Das ist ein Thema, das oft übersehen wird. In Wirklichkeit sind die meisten Projekte Teamarbeit.
Der Entwickler arbeitet zusammen mit:
- UX-Designern,
- UI-Designern,
- Project Managern,
- Testern,
- DevOps,
- Administratoren,
- Analysten,
- Kunden.
Deshalb sind genauso wichtig wie Technologiekenntnisse:
- Kommunikation,
- Zuhörfähigkeit,
- Wissensweitergabe,
- Verantwortungsbewusstsein,
- gegenseitiger Respekt.
Der beste Code rettet ein Projekt nicht, wenn das Team nicht zusammenarbeiten kann.
Glossar
Code Review
Prozess, bei dem andere Entwickler den Code vor dem Deployment prüfen. Ziel ist die Verbesserung der Codequalität, das Auffinden von Fehlern und das Teilen von Wissen.
Pull Request (PR)
Vorschlag, Änderungen in ein Projekt einzubringen. Genau in diesem Schritt findet meist das Code Review statt.
Clean Code
Ansatz beim Schreiben von Code, dessen Hauptziel Lesbarkeit, Einfachheit und Wartbarkeit ist, nicht die Anzahl der verwendeten Designmuster.
Debugging (Fehlersuche)
Prozess zum Finden und Beheben von Ursachen für Fehler in einer Anwendung.
Cache
Mechanismus zur temporären Speicherung von Daten, um die Performance zu erhöhen. Kann auch Quelle vieler rätselhafter Probleme beim Testen sein.
Zusammenfassung
Je länger wir als Entwickler arbeiten, desto mehr kommen wir zu einer Erkenntnis: Die besten Developer sind nicht diejenigen, die am wenigsten Fehler machen.
Die besten Developer können:
- Ursachen von Problemen schneller finden,
- Schlüsse ziehen,
- von anderen lernen,
- konstruktive Kritik annehmen,
- ihr Handwerk stetig verbessern.
Code Review ist also kein Hindernis. Es ist eine der wertvollsten Lektionen, die man am Anfang seiner Karriere erhalten kann.
Im letzten Teil unserer Serie sprechen wir darüber, wie der Weg vom Junior zum Senior aussieht. Wir erklären, warum ein Senior Developer nicht nur jemand mit zehn Jahren Erfahrung ist, sondern jemand, der Verantwortung für ein Projekt übernehmen kann, geschäftlich denkt und anderen Teammitgliedern hilft, sich weiterzuentwickeln.
