Sollten wir versuchen, unseren gesamten Code zu überprüfen?


18

Wir ändern derzeit den Entwicklungsprozess und fragen uns, ob wir versuchen sollten, 100% unserer Commits von Fachleuten zu überprüfen.

Welche Erfahrungen haben Sie mit Code-Überprüfungen gemacht?

  • Verbringst du "viel" Zeit mit ihnen (sagen wir 1/2 Stunde pro Tag) oder überfliegst du sie nur für maximal 5/10 Minuten?
  • Haben Sie eine feste Zeit pro Tag / Woche / Sprint / Projekt?
  • Ist es Ihrer Meinung nach am wichtigsten, dass 100% des Codes einer Peer-Review unterzogen werden sollen oder dass 100% nicht erforderlich sind?

Versuchen Sie, 80% des Codes mit 20% des Aufwands zu berühren. Investieren Sie in die besten automatisierten Tools, die Sie für Geld kaufen können.
Job

2
Automatisierte Tools sind großartig, aber nutzlos, es sei denn, Sie haben Zeit und Ressourcen, um alle Tests auf dem neuesten Stand zu halten.
Kieren Johnstone

Antworten:


19

Wir haben in jeder Geschichte eine Aufgabe zur Überprüfung des Codes. Jemand, der idealerweise nicht an der Entwicklung dieser Story beteiligt ist, überprüft alle mit dieser Story verbundenen Codeänderungen. Es läuft gut.

Viel Zeit? Nicht sehr viel, hängt davon ab, wie viel Code vorhanden ist - wir suchen nach offensichtlichen Fehlern, Tippfehlern, grundlegenden Überprüfungen der Logik, nicht erfassten Ausnahmen usw.

Es ist ein Qualitätsschritt, der Fehler findet, daher hat er einen gewissen Wert. Das Zuteilen von Zeit ist möglicherweise nicht die beste Methode. Wie wäre es, wenn etwas ziemlich komplex ist, sollte es einer Codeüberprüfung unterzogen werden?

Übrigens ist es wichtig, dass jemand anderes die Codeüberprüfung durchführt.


3
"Übrigens ist es wichtig, dass jemand anderes den Code überprüft.", Impliziert die Frage, dass dieselbe Person, die den Code schreibt, ihn überprüfen sollte? Wenn ja wo? Ich möchte das beheben :)
Simeon

4
Nein, das tut es nicht, ich war umfassend und sagte, es sei wichtig
Kieren Johnstone

5
@Simeon Es ist eigentlich ein furchterregender Irrtum, dass der Besitzer seinen eigenen Code überprüfen kann. Es untergräbt die gesamte Operation
Tom Squires

5
@ TomSquires: Genau. Wenn Sie lange Zeit mit einem Teil des Codes gearbeitet haben, können Sie gegenüber ansonsten offensichtlichen Fehlern "blind" werden, weil Sie ihn als das ansehen, was er sein soll, anstatt als das, was er ist. Diese Probleme sind für jemanden, der den Code noch nie gesehen hat, leichter zu erkennen. Autoren haben das gleiche Problem, und genau wie Bücher ohne Korrekturlesen nicht veröffentlicht werden, sollte Code nicht ohne Überprüfung veröffentlicht werden. Das Durchführen von Codeüberprüfungen bietet auch andere Vorteile, z. B. ist es gut für den Wissenstransfer zwischen den Mitgliedern Ihres Teams.
Hammar

@ Hammar - natürlich ist es eine Herausforderung, jemanden zu finden, der den Code nicht geschrieben hat und der die Zeit hat, sich so gut damit vertraut zu machen, dass er ihn hilfreich durchsehen kann
Peter Ajtai,

12

Ein wichtigeres Problem, das davon abhängt, wie viel über Ihren Code von Überprüfungen abgedeckt wird, ist, wie effektiv die Überprüfungen sind. Wenn Ihre Bewertungen nur wenige oder gar keine Probleme entdecken, ist es sinnlos, eine vollständige Abdeckung zu erreichen.

Arbeiten Sie zuerst daran, Ihre Bewertungen effektiver zu gestalten, und legen Sie dann die Berichterstattung fest.

Überprüfungen sollten nicht nur am Code, sondern auch am Design durchgeführt werden.



Bewertungen sind auch kein Ersatz für Tests und Tools:

  • Bewertungen können Trockenlaufcode
  • Bewertungen können Code-Analyse enthalten
  • Überprüfungen prüfen die Wiederverwendung und Lesbarkeit
  • Überprüfungen können einige Aspekte der Effizienz untersuchen. Dies ersetzt jedoch nicht die tatsächliche Messung der Laufzeit und das Auffinden von Engpässen
  • Es gibt Tools zur statischen Code-Analyse
  • Es gibt Tools zum Testen von Codierungskonventionen. Verschwenden Sie keine Überprüfungszeit damit
  • Unit-, System- und Integrationstests als Wet-Run-Code
  • Unit-, System- und Integrationstests können automatisch wiederholt werden, Code Reviews sind in der Regel einmalig
  • Unit-Tests sollten eine hohe Codeabdeckung aufweisen und sowohl Haupterfolgsszenarien als auch Endbedingungen testen. Code-Überprüfungen können dies nur teilweise
  • Integrationstests testen die Fähigkeit von Einheiten oder Systemen, zusammenzuarbeiten. Die Codeüberprüfung kann dies nicht ersetzen
  • Systemtests testen die Funktionalität eines gesamten Systems, Code Review kann dies nicht ersetzen



Wenden Sie eine voreingestellte Zeit pro Monat (oder pro Sprint) für Überprüfungen an. Wählen Sie den Code, den Sie am nächsten dedizierten Slot überprüfen möchten, mit einer Heuristik wie:

  • Code, der möglicherweise einen unbekannten Fehler enthält, der gemeldet wurde
  • In diesem Code wurden kürzlich Fehler identifiziert
  • Code mit Leistungsproblemen (Engpässe)
  • Code von neuen Entwicklern geschrieben
  • Legacy-Code, der kürzlich von einer Person aktualisiert wurde, die mit dem Code noch nicht vertraut war
  • Code in neuen Bereichen
  • Vorhandener Code, über den sich neue Entwickler informieren sollen
  • Code, der komplexe Probleme löst
  • Code, der von Analysetools als komplex identifiziert wurde

Und denken Sie daran, Sie überprüfen Code (oder Design oder Tests) und nicht Autoren.



Ich empfehle folgende Lesematerialien:

Selektive Überprüfung ohne Hausaufgaben Die am
besten gehüteten Geheimnisse der Peer-Code-Überprüfung


5

Es hängt davon ab, ob.

Es hängt davon ab, was Ihre Software tut:

  • Wenn es einen elektronischen Schrittmacher oder ein Space Shuttle steuert, dann auf jeden Fall ja.

  • Wenn es ein Wegwerfprototyp ist, dann wahrscheinlich nein.

Es hängt auch davon ab, wie gut Sie mit Ressourcen ausgestattet sind, wie erfahren Ihre Entwickler sind und wonach Sie in Codeüberprüfungen suchen. (Denken Sie daran, dass der durchschnittliche Entwickler, der den Code eines anderen überprüft, wahrscheinlich Stilprobleme bemerken und subtile algorithmische Fehler übersehen wird. Dies gilt insbesondere, da die Überprüfung von Code eine gewisse Belastung darstellt.)

Mein Rat wäre, Ihren Code-Überprüfungsaufwand für Code zu sparen, bei dem die Korrektheit von entscheidender Bedeutung ist und die Kosten für unentdeckte Fehler hoch sind.


5

Zunächst müssen Sie die folgende Frage beantworten: Warum überprüfen Sie den Code?

Mit dieser Antwort können Sie herausfinden, welcher Code überprüft werden muss.

Einige Codeüberprüfungen führen genau das aus, was das Testen getan hat oder hätte. Wenn dies das Ziel Ihrer Bewertungen ist, ist es eine gute Idee, sich 100% zu nähern, wenn Sie nur wenige Tests haben. Wenn Sie jedoch Test-Tools dies tun lassen, muss der gesamte Code nicht mehr überprüft werden.

Die meisten guten Überprüfungen scheinen darauf ausgerichtet zu sein, Wissen auszutauschen und die Fähigkeiten der Entwickler in der Überprüfung zu verbessern (entweder derjenige, der den Code geschrieben hat, oder derjenige, der den Code überprüft). Aus diesem Grund ist es wahrscheinlich zu viel des Guten, wenn Sie sicherstellen, dass Sie 100% des Codes überprüfen.


3

In einer perfekten Welt würde alles explizit vom Autor gelesen und von mindestens einer anderen Person begutachtet, von den Anforderungsspezifikationen über Benutzerhandbücher bis hin zu den Testfällen. Aber Überprüfungen, selbst einfache Schecks, kosten Zeit und Geld. Dies bedeutet, dass Sie auswählen müssen, was Sie überprüfen und wann Sie es überprüfen sollten.

Ich empfehle, die zu überprüfenden Elemente zu priorisieren, auszuwählen, wie Sie sie überprüfen möchten, und zu versuchen, so viel wie möglich mit der entsprechenden Detailstufe zu überprüfen. Die Priorisierung kann auf der Art des Artefakts basieren, z. B. dass Anforderungen überprüft werden müssen, Design- und Produktionscode überprüft werden sollten und Testfälle überprüft werden können. Darin können Sie auch festlegen, dass Komponenten mit hohem Risiko oder hohem Wert eine Priorität in der Überprüfung oder vielleicht eine formellere Überprüfung erhalten.

Was die Zeit anbelangt, geht alles auf die Priorität der Komponente zurück. Es gab Zeiten, in denen ich 10 bis 15 Minuten lang nachgesehen habe, und andere Male, in denen mehrere Personen den Code einzeln gelesen haben, gingen sie in einen Raum, um einen formelleren Inspektionsprozess durchzuführen, der 30 bis 45 Minuten dauert (abhängig von der Größe von) das Modul).

Letztendlich ist es ein Gleichgewicht zwischen Zeit, Kosten, Umfang und Qualität. Sie können nicht alle haben, also müssen Sie optimieren, wo Sie können.


3

Wenn Sie vorhaben, überhaupt Überprüfungen durchzuführen, sollten Sie einige gemeinsame Richtlinien zum Überprüfungsumfang und -ziel festlegen, um sicherzustellen, dass Überprüfungen keine unnötigen Reibungen zwischen den Teammitgliedern verursachen.

Kohärente Teams bauen bessere Projekte auf. Menschen könnten ihre Beziehung wegen Unsinns oder wegen Perfektion verlieren. Es gibt immer jemanden, der sich über dieses oder jenes beschwert und andere nervt, nur weil er so ist ...


2

Ich reserviere eine Stunde pro Tag für Peer Reviews, benötige diese aber nicht immer. Unsere Code-Basis teilen sich ein paar Dutzend Produkte. Wir sind der Meinung, dass eine geringfügige Änderung des Codes, die nur für ein Produkt gilt, ohne Überprüfung eingecheckt werden kann. Für komplexere Änderungen an einem Produkt ist eine Überprüfung erforderlich. Dies kann jedoch so informell sein, als würde ein Kollege an Ihren Schreibtisch gerufen, um eine erneute Überprüfung durchzuführen. Änderungen am gemeinsam genutzten Code erfordern eine formellere Überprüfung, einschließlich der Entwickler anderer Produkte. Ich denke, unsere Politik ist im Vergleich zu anderen Unternehmen, für die ich gearbeitet habe, ziemlich ausgewogen.

Ich verbringe mehr Zeit pro Tag mit Überprüfungen als einige meiner Kollegen mit weniger zentralen Rollen, halte dies jedoch nicht für unangemessen viel Zeit, da ich vor der Überprüfungsrichtlinie ohne weiteres mehr Zeit damit verschwenden könnte, die Fehler eines Entwicklers aufzuspüren auf ein anderes Produkt eingeführt.


Ist das ein Durchschnitt? Eine komplexe Überprüfung auf eine Stunde zu beschränken, scheint seltsam, und wenn es nicht so viel zu überprüfen gibt. Nun, ich kann nicht sehen, wie eine Stunde pro Tag funktionieren würde.
Kieren Johnstone

Das ist keine Grenze. Ich stelle die Zeit danach ein, wie lange es gedauert hat, nicht umgekehrt. Ich kann in der Regel 2 Bewertungen in einer Stunde fertig bekommen. Wenn es länger dauert, sind Ihre Check-Ins zu groß, Sie erhalten nicht genügend Entwurfsprüfung vor der Übergabe, oder Ihre Tools zur Codeüberprüfung sind zu umständlich. Code Reviews sind ein Scheck, kein Redesign.
Karl Bielefeldt

2

Wir haben 100% -Code-Tests durchgeführt. Dies ist weitaus billiger als das Testen, insbesondere das Testen der Codeabdeckung zu 100%. Wir verbringen nicht zu viel Zeit mit ihnen, und das Überprüfen von mehr als einer Stunde pro Tag wird weniger produktiv. (30 Minuten sind nicht viel).

Machen Sie sich während des Vorgangs Notizen. Was hast du gefunden? Was hat QA später gefunden? Was haben Ihre Kunden gefunden? Warum sind dir diese Käfer entkommen?


7
Wie ist das Überprüfen billiger als das automatisierte Testen? Angenommen, Sie schreiben einen Test einmal, überprüfen einen Test einmal und verfügen über eine stabile Testsuite, dann sollten Sie viel weniger Zeit und Geld für die Durchführung von Tests aufwenden, als für die Durchführung von Überprüfungen (über die gesamte Laufzeit des Projekts) erforderlich ist. Das Ziel einer 100% igen Codeabdeckung ist auch eine Verschwendung von Ressourcen, was möglicherweise der Grund für den höheren Zeit- / Kostenaufwand beim Testen ist. Ich stelle auch die 30 Minuten in Überprüfungen in Frage - wir können ein Modul 30 Minuten lang überprüfen, aber es ist die Vorbereitungszeit, um den Code zunächst zu lesen, seine Rolle im System zu verstehen und ihn zu kommentieren.
Thomas Owens

Die Behauptungen von @MSalters sind keine Seltenheit, auch wenn ich skeptisch bin, dass es nur 30 Minuten dauert. Ich habe nur von einem Ort gelesen, an dem Inspektionen kostengünstiger waren als automatisierte Komponententests, und das war die NASA. In diesem Fall ließen sie den Unit-Test schließlich ganz fallen, weil es billiger war, den Code manuell zu überprüfen. Natürlich hatte die NASA immer noch ein Verhältnis von Testern zu Entwicklern von 12: 1, so dass sie auch viele andere Tests durchführten ...
Michael,

2
@ Thomas Owens: Unit-Tests finden einfache Fehler. Die teuren Fehler sind solche, bei denen mehrere Einheiten auf unerwartete Weise kombiniert werden. Eine andere Art von Bugs sind verpasste Eckfälle. Ein Entwickler, der einen Fall verpasst hat, schreibt auch keinen Komponententest, aber ein zweiter Satz Augen erkennt ihn.
MSalters

@MSalters Deshalb schreiben Sie automatisierte Integrations- und Systemtests sowie Unit-Tests. Die einzigen Tests, die möglicherweise manuell durchgeführt werden müssen, sind Abnahmetests. Eine Überprüfung der Tests beim Erstellen würde dazu beitragen, dass die kritischsten Fälle getestet werden.
Thomas Owens

2

Regelmäßige Codeüberprüfungen, hauptsächlich zur Teambildung und zum Austausch von Ideen zur Implementierung. So können Sie viel von Ihren Mitarbeitern lernen.


Dies weist nur auf einige Vorteile hin. Halten Sie es für wichtig, Fehler zu finden? Wenn ja, wie viel?
JeffO

Natürlich ist es wichtig, Fehler zu finden, aber der größere Vorteil ist das langfristige Wissen, das aus den Code-Überprüfungen gewonnen wurde. Möglicherweise wurde ein Fehler durch einen schlechten Ansatz verursacht, der in Zukunft verhindert werden kann
Coder

2

Für jeden Check-In benötigen wir eine Peer-Code-Überprüfung. Wenn kein Peer verfügbar ist, veranlassen wir eine Überprüfung nach dem Check-in. Der Prüfer wird im Check-in-Kommentar zur Quellcodeverwaltung vermerkt.

Diese nehmen nicht viel Zeit in Anspruch, und da sie zwischen Gleichaltrigen durchgeführt werden, haben sie keinen toxischen Erwachsenen-Kind-Aspekt.


2

Code Review ist, IMO, erforderlich. Sie sind 99.999 ...% der Zeit werden nicht immer richtig sein, deshalb müssen Sie sicherstellen, dass es richtig ist. Habe ich eine festgelegte Zeit? Nein, aber ich nehme mir die Zeit, um meinen Code zu überprüfen. Normalerweise muss ein Kollege dasselbe tun.


1

Codeüberprüfungen mögen entmutigend erscheinen, aber sie sind ein wertvolles Werkzeug, wenn sie ordnungsgemäß durchgeführt werden. Sie werden Ihre erste Verteidigungslinie gegen Design- und Implementierungsfehler sein. Wenn Sie nicht für jedes Feature, das Sie implementiert haben, Codeüberprüfungen durchführen, sollten Sie ASAP starten.

Es empfiehlt sich, 5-10% Ihrer geschätzten Gesamtentwicklungszeit für die Durchführung und Beantwortung der Codeüberprüfung zu verwenden.

Wir haben ein Whitepaper zur Durchführung effektiver Codeüberprüfungen, die Ihnen dabei helfen können, den richtigen Weg zu finden. Es ist eine Schritt-für-Schritt-Anleitung, in der häufig auftretende Probleme und deren Behebung erläutert werden. Sie können es von unserer Website herunterladen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.