Wie etabliert man eine Code-Review-Kultur? Meine Beobachtungen aus zehn Jahren

stimme der kleinen-häppchen-regel zu, aber praktisch ist das schwer. manchmal ist die änderung naturgemäß groß.

unsere lösung war: bevor wir die große änderung schicken, schreiben wir den ansatz auf einer seite und teilen das. fünf minuten lesen verhindern eine stundenlange review-debatte.

das schlimmste ist, wenn man nach 500 zeilen code erfährt, dass der ansatz falsch war. an dem punkt will niemand mehr zurückrudern und die schlechte entscheidung landet in der produktion.

Darf ich als Anfänger auch was sagen?

Für mich ist das Schwerste nicht, die Kommentare nicht persönlich zu nehmen. Wenn ich einen Kommentar nicht verstehe, traue ich mich nicht nachzufragen, weil ich dumm wirken könnte. Dann rate ich und korrigiere falsch.

Keine Ahnung, ob das nur bei mir so ist, aber vielleicht geht es anderen auch so.

Das ist nicht nur bei dir so, das ist weit verbreitet und es ist unsere Aufgabe, das zu ändern, nicht deine.

Bei uns haben zwei Dinge geholfen. Erstens: Beim Kommentieren auch die Begründung mitschreiben. Statt "Ändere das hier" lieber sagen "Das gibt in diesem Fall einen Fehler, deshalb ist es besser, wenn es so aussieht". Wenn die Begründung da ist, sinkt das Bedürfnis, Fragen zu stellen.

Zweitens: Wenn es mehr als zwei Runden Schriftverkehr gibt, das Gespräch in den Chat verlegen. Ein 15-minütiges Gespräch ist schneller als 15 Kommentare und viel weniger zermürbend.

Und noch was: Es gibt keine dummen Fragen. Drei andere im Team fragen sich dasselbe, trauen sich aber nicht. Wenn du fragst, tust du allen vier einen Gefallen.

Stil-Debatten dem Tool zu überlassen, ist der größte Gewinn allein schon. Ist in einer Woche eingerichtet und spart jahrelang Zeit.

Warnung vom Projektmanagement: Plant die Review-Zeit im Plan ein.

Bei uns lief das so: Wir haben Code Reviews lange nicht als Teil der Arbeit betrachtet, im Plan stand nur die Entwicklungszeit. Ergebnis: Jedes Review wurde als "Ding, das den Job bremst" gesehen und nur pro forma gemacht.

Seit wir es im Plan haben, sabotiert niemand mehr die Reviews, weil es nicht mehr das ist, was verzögert, sondern der Plan selbst.

Das habe ich auch erlebt.

Genau so ist es. halt wenn du das nicht von Anfang an schriftlich festhältst gibt es später Streit.

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

Ich stimme voll und ganz zu. Nur weil alle es tun, heißt es nicht, dass es richtig ist.

Schreibt mir, wenn ihr Fragen habt, ich antworte so gut ich kann.

Bei mir war es genau umgekehrt, deshalb schreibe ich das. Entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht.

Wenn ihr das Ergebnis hier postet hilft es auch anderen.

Ich möchte kurz warnen. Schaut zuerst, welche Daten ihr bei der Entscheidungsfindung zur Hand habt.

Kein Prozess ohne Dokumentation verbessert sich, weil man nicht weiß was man verbessern soll. Wenn es jemand anders macht, würde mich das auch interessieren.

Bleibe dran.

Bei uns ist es genauso.

Gespeichert.

Ich fasse das Thema mal zusammen da es mehrere unterschiedliche Antworten gab. naja beginnt mit einem kleinen Test, bindet nicht gleich alles fest.

An deiner Stelle würde ich so vorgehen.

Entschuldigung, aber das gilt nicht in jedem Fall. Lösungen die im kleinen Maßstab funktionieren brechen bei Wachstum zusammen, das habe ich spät gelernt.

Korrigiert mich, falls ich falsch liege.

So klar geschriebene Texte sind selten. Scheut euch nicht zu fragen, wer nicht fragt, zahlt am Ende mehr.

Wenn der Umfang wächst, müssen entweder Zeit oder Budget wachsen. Eine dritte Option gibt es nicht. Wenn es jemand anders macht, würde mich das auch interessieren.

ein Thema, das gearde aktuell ist.

Notiert, danke.