Warum Ihr Team Code-Reviews durchführen sollte

Das Problem Ihr Projekt hat eine gute Testabdeckung, sagen wir 85%. Ihr nächtlicher Build meldet eine breite Palette von Metriken, die alle über den von Ihnen akzeptierten Werten liegen. Ihr Team besteht aus gut motivierten Mitarbeitern, die alle bereit sind, die neuesten Frameworks und Techniken zu erlernen. Und Sie haben Scrum, Agile, Kanban oder einen anderen neueren/agilen Softwareprozess eingeführt. Aber in letzter Zeit haben Sie festgestellt, dass die Implementierung einfacher neuer Funktionen immer mehr Zeit in Anspruch nimmt. Dass sich trotz Ihrer Testabdeckung Fehler in Ihrem Produktionscode eingeschlichen haben, deren Behebung Tage dauern kann. Und dass sich die Lösung der Probleme, die höchste Priorität haben, manchmal verzögert, weil das spezifische Wissen bei einer einzigen Person liegt, die nur eine Aufgabe auf einmal erledigen kann. Was ist hier los? Automatisierte Tests und Metriken sind sicherlich nützlich, aber sie erfassen nicht alles. Es ist zum Beispiel durchaus möglich, sinnlose Unit-Tests durchzuführen, die 100% Ihres Codes abdecken. Sie können Code mit großartigen Metriken schreiben, der aber von Ihren Kollegen nicht verstanden wird, weil Methoden- oder Variablennamen schlecht gewählt sind. Vielleicht haben Sie Code geschrieben, während ein Kollege bereits etwas Ähnliches geschrieben hat, und so eine Gelegenheit zur Wiederverwendung verpasst. Und zu guter Letzt: Während es viele Tools zur Messung der Qualität von Java-Code gibt, ist die Auswahl an Tools für Nicht-Java-Code viel begrenzter. Denken Sie an JSF oder JSP-Seiten oder neue Sprachen, für die die Tools noch nicht genügend Zeit hatten, sich zu entwickeln. Lösung: Code-Überprüfungen! Code wird nicht nur für Computer geschrieben, sondern auch für Menschen. Warum also nicht auch Menschen am Prozess der Codequalität teilhaben lassen? Ihr Kollege kann sofort sehen, ob Ihr Code schwer verständlich ist oder nicht. Er kann die Codierungsstandards in den Bereichen überprüfen, in denen noch Tools fehlen. Und das ist noch nicht alles:

• Er könnte Fehler in Ihrem Code entdecken
• Vielleicht haben Sie eine funktionale Anforderung falsch interpretiert oder übersehen
• Ihr Kollege kennt vielleicht eine tolle Bibliothek eines Drittanbieters, die Sie hätten verwenden können

Und wenn Sie Ihre Kollegen den Code der anderen lesen lassen, wird das Wissen über die Codebasis im gesamten Team verbreitet. Und durch die Diskussion von Verbesserungsvorschlägen für den überprüften Code wird auch das allgemeine Programmierwissen im Team verbreitet. Tipps zur Durchführung Meiner Erfahrung nach gibt es ein paar Dinge, die bei der Integration von Code-Reviews in Ihren Softwareentwicklungsprozess gut funktionieren: Veranstalten Sie zunächst eine Brainstorming-Sitzung für Ihr gesamtes Team und einigen Sie sich auf eine Reihe von Review-Kriterien. Indem Sie sich als Team auf eine Reihe von Review-Kriterien einigen, vermeiden Sie spätere Diskussionen. Denken Sie an Dinge wie:

• beschreibende Variablen- und Methodennamen
• aussagekräftige Einheitstests
• Konformität mit Gui-Standards
• nicht funktionale Anforderungen wie Leistung oder Sicherheit

Achten Sie bei der Zuweisung von Überprüfungen darauf, dass sie einem beliebigen Kollegen zugewiesen werden. Schließlich haben Sie sich auf eine Reihe von Standards für die Überprüfung geeinigt, so dass ein jüngerer Kollege Ihren Code genauso gut überprüfen kann wie ein älterer. Außerdem haben verschiedene Leute unterschiedliche Standpunkte, so dass es gut ist, wenn viele verschiedene Kollegen Ihren Code überprüfen.Achten Sie auf die Integration mit Ihrem Bug-Tracking-Tool. Code-Reviews werden viel einfacher, wenn Commits von einem Bug-Report oder einer Feature-Anfrage zurückverfolgt werden können. Jira hat beispielsweise eine gute Integration mit Crucible, die es Ihnen ermöglicht, Teammitgliedern direkt von einem Jira-Problem aus Reviews zuzuweisen. Alternativen Der größte Nachteil von Code-Reviews ist, dass sie zusätzliche Zeit in Anspruch nehmen. Ich persönlich bin der Meinung, dass sich diese Zeitinvestition mit Zinsen auszahlt. Wenn Sie jedoch Ihren Vorgesetzten oder Ihre Kollegen nicht davon überzeugen können, die zusätzliche Zeit zur Verfügung zu stellen, könnten selektive Überprüfungen eine gute Alternative sein. Sie könnten zum Beispiel die Commit-E-Mails der anderen abonnieren und diese überprüfen. Wenn Zeit jedoch kein Thema ist, könnte eine Alternative, die noch ein bisschen weiter geht, die Paarprogrammierung sein.