Code-Reviews mit fünf Warums

Uns wird gesagt, dass wir Code-Reviews organisieren sollten, weil Code-Reviews gut für unsere Code-Basis sind. Wir sind diesem Rat gefolgt und haben es geschafft, eine prächtige Fassade zu bauen. Wir führen Codeüberprüfungen durch und verbessern unsere Codebasis. Von außen sieht alles super aus und es mag stimmen, dass wir Fortschritte machen.

Wir schöpfen jedoch noch nicht das volle Potenzial von Code-Reviews aus.

Code-Reviews sind Zeitverschwendung

Die traditionellen Code-Reviews haben zwei Hauptprobleme:

• Die Codebasis ist zu groß . Da eine herkömmliche Überprüfung normalerweise vor oder nach einem Meilenstein organisiert wird, ist die überprüfte Codebasis so groß, dass niemand sie in angemessener Zeit durchlesen kann. Außerdem müssen wir, wenn wir ehrlich sind, zugeben, dass niemand viel Zeit damit verbringen möchte, große Code-Blöcke durchzulesen, selbst wenn es einem erlaubt wäre (und das ist nicht oft der Fall). Aus diesem Grund sind die meisten Kommentare ziemlich wertlos.
• Das Feedback kommt immer zu spät . Wenn eine Codeüberprüfung kein kontinuierlicher Prozess ist, der in unsere tägliche Arbeit integriert ist, wurde viel Code geschrieben, bevor die Codebasis überprüft wird. Mit anderen Worten, wenn wir etwas Kritisches im Code finden, ist die Wahrscheinlichkeit groß, dass derselbe Fehler mehr als einmal gemacht wird. Wir sind am Arsch. Wir haben kritische Probleme in unserer Codebasis und oft wird uns nicht genug Zeit gegeben, sie zu beheben.

Herkömmliche Code-Reviews sind Zeitverschwendung. Es macht absolut keinen Sinn, das gesamte Team in einen Besprechungsraum zu schleppen, um über verspätete und nutzlose Bewertungsnotizen zu diskutieren. Es wäre viel produktiver, uns unsere Codebasis verbessern zu lassen, anstatt uns in ein Meeting zu schleppen, dessen einziger Zweck darin besteht, den Eindruck zu erwecken, dass uns die Qualität unseres Codes am Herzen liegt.

Zum Glück für uns ist nicht alle Hoffnung verloren.

Form folgt Funktion

Es gibt ein Sprichwort, das besagt, dass der Weg zur Hölle mit guten Absichten gepflastert ist. Die Absicht hinter den traditionellen Code-Reviews ist gut, aber die Ausführung verursacht mehr Probleme als sie löst. Anstatt sich auf belastende Prozesse zu verlassen, sollten wir darauf abzielen, den Code-Review zu einem Teil unserer täglichen Arbeit zu machen.

Wir können Paarprogrammierung verwenden und den Inhalt jedes Commits überprüfen. Diese Techniken lösen die meisten Probleme des traditionellen Code-Review-Prozesses, da sie Flexibilität und sofortiges Feedback bieten, das nicht vorhanden ist, wenn wir uns für den traditionellen Weg entscheiden. Allerdings habe ich mich gefragt, ob wir noch etwas tun können.

Es gibt zwei Gründe, warum wir Codeüberprüfungen durchführen:

• Wir möchten unsere Codebasis sauber halten und so viel beschissenen Code wie möglich eliminieren.
• Wir möchten Wissen mit Ihren Teammitgliedern teilen.

Die fünf Warums sind eine Problemlösungstechnik, die verwendet wird, um die Grundursache eines Problems zu ermitteln. Die Hauptidee besteht darin, die Frage „Warum“ so lange zu stellen, bis die Grundursache des Problems identifiziert ist. Was hat das also mit Code-Reviews zu tun?

Diese Technik hilft uns, den Grund zu identifizieren, warum der überprüfte Code so implementiert wird, wie er ist. Diese Informationen sind wichtig, weil sie uns helfen, die aktuelle Implementierung gegen ihre Absicht zu bewerten. Das hilft uns, uns auf die Funktion des Codes statt auf seine Form zu konzentrieren. Um die Dinge klar zu stellen:Die Form ist wichtig, aber sie folgt der Funktion; nicht umgekehrt.

Als Bonus geben wir die versteckten Informationen an die anderen Mitglieder unseres Teams weiter.

Vom Urteil zur Verbesserung

Die Idee, die Fünf-Warum-Technik anzuwenden, ist für einen erfahrenen Softwareentwickler wahrscheinlich nicht neu. Es ist eine Technik, die wir bereits in unserer täglichen Arbeit anwenden sollten. Es hat jedoch einen unerwarteten Vorteil.

Herkömmliche Code-Reviews können unangenehme Situationen sein, die unnötige Spannungen zwischen unseren Teammitgliedern verursachen können. Einige von uns neigen dazu, jedes Feedback persönlich zu nehmen, und einige von uns sind weniger gut darin, konstruktives Feedback zu geben. Das ist nicht professionell, aber sehr menschlich.

Die Fünf-Warum-Technik ist eine clevere Möglichkeit, den Softwareentwickler, der den überprüften Code implementiert hat, als aktiven Teilnehmer in den Überprüfungsprozess einzubeziehen. Das reduziert Stress, weil es unserem Mitentwickler das Gefühl gibt, dass wir versuchen, seine Entscheidungen zu verstehen, anstatt sie nur zu beurteilen.

Das ist riesig profitieren, weil wir uns jetzt auf unser gemeinsames Ziel konzentrieren und unsere Codebasis kontinuierlich verbessern können.