Nehmen wir an, man arbeitet in einem hypothetischen Unternehmen mit mehreren Entwicklern, die selten an Projekten zusammengearbeitet haben, und der Chef war nicht der Meinung, dass Code-Reviews die Zeit und die Kosten wert sind.
Welche verschiedenen Argumente könnten in diesem Szenario präsentiert werden, um den Nutzen der Codeüberprüfung darzustellen? Welche potenziellen Argumente sprechen hier gegen eine Codeüberprüfung und wie kann dagegen vorgegangen werden?
Antworten:
Wenn Sie sich für solche grundlegenden Dinge rechtfertigen müssen, haben Sie ein größeres Problem.
Sie sind der Experte, Ihr Team sollte entscheiden, welche Praktiken Sie anwenden. Vielleicht sollten Sie anfangen, Ihren Chef von diesem sehr wichtigen Prinzip zu überzeugen.
Ihr Chef soll entscheiden, WAS zu tun ist und was noch wichtiger ist, WARUM . Sie sollten sich der kümmern WIE es bauen
(Das heißt natürlich nicht, dass Sie nicht vorschlagen können, was und warum Sie Dinge in Ihrer Firma tun). Ein großartiger Chef sollte seine Mitarbeiter ermutigen, sich an der Unternehmensstrategie zu beteiligen.
Hier ist jedoch, wie ich Peer-Code-Reviews ansehe:
Da das Programmieren eine sehr intensive intellektuelle Arbeit ist, kann eine Person nicht sicherstellen, dass alles perfekt ist. Daher stellen Sie mit der Codeüberprüfung sicher, dass:
Jeder profitiert direkt davon:
Durch die Codeüberprüfung können sich mehrere Entwickler mit demselben Code vertraut machen. Das ist eine gute Sache. Was passiert, wenn der ursprüngliche Autor entscheidet, aufzuhören oder noch schlimmer zu werden? Ihm passiert etwas Schlimmes. Wenn Code-Überprüfungen regelmäßig durchgeführt werden, können andere schnell übernehmen.
Gleichaltrige können möglicherweise mögliche Fehler oder Leistungsprobleme während der Codeüberprüfung erkennen. Dies reduziert die Qualitätssicherung und den Entwicklungsaufwand. Dies kann die zusätzlichen Kosten für Codeüberprüfungen ausgleichen.
Code Reviews fördern den Wissensaustausch. Gleichaltrige können von besseren oder alternativen Arbeitsmethoden berichten. Ich selbst habe durch Code-Reviews viel von meinen Kollegen gelernt.
Codeüberprüfungen helfen dabei, die vom Team befolgten Codierungsrichtlinien zu verstärken. Wenn das Team keine hat, muss dies korrigiert werden. Code soll einmal geschrieben und mehrmals gelesen werden. Codierungsrichtlinien sind ein Schritt in Richtung lesbaren Codes. Code soll für Gleichaltrige lesbar sein. Was gibt es Schöneres, als Codeüberprüfungen durchzuführen, um die Lesbarkeit zu gewährleisten?
Viele gute Antworten hier. Einige Dinge, die ich hinzufügen würde:
Wenn Sie Code jemand anderem erklären müssen, stellt der Entwickler im Verlauf der Erklärung möglicherweise plötzlich fest, dass er einen Fehler hat. Ich habe immer wieder gesehen, dass der Entwickler in seinen Tracks stehen bleibt und "Oh, warte, das ist falsch" sagt, bevor der Rezensent die Sache gut genug verstanden hat, um den Fehler zu erkennen.
Wenn Sie wissen, dass Ihr Code von einer anderen Person überprüft wird, erhalten Sie mehr Anreize für die Verwendung von Codierungsstandards (was die Wartung erleichtert) oder weniger "Cowboy" -Methoden, die niemand außer Ihnen (und manchmal auch nicht Sie selbst) jemals verstehen wird. Sie möchten sich nicht schämen, wenn Sie Ihren Code jemand anderem zeigen, damit Sie ihn besser bearbeiten können. Aufgrund des Peinlichkeitsfaktors bleibt weniger Code mit folgenden Kommentaren: "Ich weiß nicht, warum das funktioniert, aber spiele nicht damit herum." in der Codebasis.
Entwickler, die eine umfassendere Überwachung oder Schulung benötigen, können leicht identifiziert werden. Also sind die absolut inkompetent. Je früher Sie Leistungsprobleme finden und beheben können, desto besser ist das gesamte Team und desto höher ist die Qualität der Anwendung. Es ist gut, diese Informationen herauszufinden, bevor Sie den neuen Mann, der eine Schulung benötigt, dem schwierigsten und kritischsten Teil Ihrer Bewerbung zuordnen.
Manchmal geht es nur darum, eine falsche Wahrnehmung zu korrigieren, die es erspart, den gleichen Fehler an einer Reihe von anderen Orten zu machen. Zum Beispiel haben wir kürzlich einige SQL-Anweisungen auf komplexe Berichte überprüft und festgestellt, dass einige unserer neuen Entwickler das gleiche Missverständnis darüber hatten, wo eine bestimmte Information in der Datenbank zu finden ist (zugegebenermaßen schien der Ort, den sie ausgewählt haben, logisch, was für uns ein Problem beim Datenbankdesign ist müssen auch beheben), das wäre entscheidend für das korrekte Schreiben aller Berichte. Indem das Problem gefunden und in den ersten Berichten behoben wurde, konnte derselbe Fehler in den übrigen Berichten vermieden werden. Und etwas, an das sich die älteren (in der Zeit arbeitenden, nicht älteren) Entwickler so gewöhnt hatten, dass sie nicht dachten, es wäre erklärungsbedürftig, kam heraus.
Junioren können aus dem komplexeren Code lernen, den Senioren geschrieben haben (die zum Beispiel die Fehlerbehebung und Randfälle besser verstehen), und Senioren können aus den neuen Techniken lernen, die Junioren anwenden, denen sie noch nicht ausgesetzt waren.
Manchmal stellen Mitarbeiter, die an verschiedenen, aber verwandten Teilen der Anwendung arbeiten, fest, dass sie in zwei verschiedene und sich gegenseitig ausschließende Richtungen gehen. Hoppla, jetzt einfacher zu reparieren.
Es ist nicht so einfach, hartcodierte Werte einzugeben, die sich im Laufe der Zeit ändern werden, um die Sache jetzt zum Laufen zu bringen. Dies verhindert viele zukünftige Fehler, die sich beispielsweise zu Beginn eines jeden Geschäftsjahres ändern.
Manchmal war ich nicht sicher, wie ich etwas machen sollte, und habe eine neue Technik gelernt, die genau das war, was ich wollte, wenn ich den Code eines anderen überprüfte.
Wenn Sie wissen, wie die anderen Mitglieder Ihres Teams denken (welche Codeüberprüfung hilft Ihnen, dieses Verständnis zu erlangen), können Sie Probleme später leichter beheben, da Sie zunächst verstehen, wie Joe auf diese Art und Weise vorgegangen wäre Problem.
Finden Sie neben dem von den anderen erwähnten Wissensaustausch Beispiele für Fehler, die bei einer Codeüberprüfung gefunden worden wären, und messen Sie, wie lange die Behebung gedauert hat. Dazu gehört auch der Zeitaufwand für die Erforschung des Problems und die Veröffentlichung der gepatchten Version sowie der Fehlerbehebung tatsächliche Zeit zur Behebung des Fehlers.
Nehmen Sie diese Kosten, die wahrscheinlich mindestens ein paar Tage in Anspruch nehmen werden, und stellen Sie sie der Zeit gegenüber, die Sie für eine Codeüberprüfung und das Eingreifen in die Ergebnisse aufgewendet hätten.
Dies zeigt Ihrem Chef, dass Codeüberprüfungen die Kosten wert sind.
Code Reviews können:
Nachteile
Wenn das zutrifft, haben wir anscheinend immer zwei- oder dreimal Zeit, um Dinge für denselben Kunden zu erledigen, aber wir haben nie genug Zeit, um es gleich beim ersten Mal richtig zu machen.
Wenn Sie auf ein Dokument verweisen müssen, ist der geschätzte "Code Complete" genau das Richtige für Sie. Darin beschreibt das Buch, wie viele Fehler bei Unit-Tests gegen Peer-Review-Tests festgestellt wurden. Es ist erstaunlich. Unit-Tests, wenn mir das Gedächtnis recht ist, fangen nur ~ 30% aller Bugs ein, während formelle Peer-Reviews ~ 70% einfangen.
Nehmen Sie diese Informationen, zeigen Sie ihn im Buch und appellieren Sie an seine finanzielle Seite. Es dauert viel länger und ist viel teurer, Fehler durchzulassen, als sie frühzeitig zu erkennen.
Wie wäre es mit einer Demo (ein einwöchiges Projekt vom Typ "Mickey Mouse"), das parallel von zwei Teams ausgeführt wird, wobei eines die Codeüberprüfung verwendet, das andere nicht.
Am Ende der Woche, um die Qualität der Arbeit jedes Teams zu beurteilen, bin ich mir ziemlich sicher, dass die Code-Reviewer als besser abschneiden werden.
Von Steve Mcconnels Construx Der Business Case für bessere Software-Praktiken und die Low Hanging Fruit (LHF) von Software Software Development sprechen dies an. Aus letzterer Liste "LHF, die vom oberen Management nicht widerstanden werden" Inspektionen.
Konzentrieren Sie sich bei der Präsentation auf das Gesamtbild.
Nennen Sie die Vorteile (besserer Code, weniger Fehler, weniger Neuschreibungen usw.) und erwähnen Sie die Codeüberprüfung als eine der von Ihnen empfohlenen Techniken.
Ich würde es zu einem Teil eines Gesamtbildes des Software-Handwerks machen
Seien Sie bereit, selbst viel zu tun, um diese Grundsätze zu fördern.
Am allermeisten erwarten Sie nicht, dass die Überredung eine "Ein-Treffen-und-erledigt" -Sache ist.
Sie sollten den Fall im Laufe der Zeit mit Ruhe und konsequent bauen. Wenn Sie sich am meisten über Fehler ärgern, die durch bessere Techniken behoben worden wären, ist es oft die schlechteste Zeit, um Ihre Sache zu erledigen, da Sie mit größerer Wahrscheinlichkeit übermäßig emotional und weniger rational sind. Das mag etwas kontraintuitiv erscheinen, aber das habe ich in über 30 Jahren Programmieren gelernt. Offensichtlich ymmv.