Code Review: Erfolgreiche Erfahrung

Im Internet gibt es eine Menge Informationen über Codeüberprüfungen:

• Wie sich eine Überprüfung des Codes einer anderen Person auf die Unternehmenskultur auswirkt
• Regulatorische Sicherheitsüberprüfungen
• gekürzte Handbücher
• lange Listen von Empfehlungen
• Codeüberprüfung aus zwischenmenschlicher Sicht
• Warum brauche ich eine Codeüberprüfung?
• bewährte Methoden
• mehr über bewährte Methoden
• Statistik: Wie viel Codeüberprüfung hilft, Fehler zu erkennen
• Beispiele für Fehler bei der Codeüberprüfung

Ja, natürlich gibt es Bücher zu diesem Thema. Mit einem Wort, dieser Artikel beschreibt, wie die Codeüberprüfung von Palantir organisiert wird. In Organisationen, deren Kultur eine solche Begutachtung durch Fachkollegen nicht akzeptiert, kann es nützlich sein, zuerst den brillanten Aufsatz von Karl E. Wiegers, Die Code-Revision mit menschlichem Antlitz, zu lesen und dann zu versuchen, diesem Leitfaden zu folgen.

Dieser Text stammt aus Empfehlungen zur Qualitätsverbesserung, die auf der Arbeit mit Baseline basieren , unserem Tool zur Qualitätskontrolle von Java-Code. Es werden folgende Themen behandelt:

• Warum, was und wann versuchen wir, eine Codeüberprüfung zu erreichen?
  
• Code zur Überprüfung vorbereiten
  
• Ausführung der Codeüberprüfung
  
• Beispiele für die Codeüberprüfung
  

Übersetzt nach Alconost


XKCD Comic 'Code Quality', kopiert unter CC BY-NC 2.5 Lizenz

Motivation

Wir beschäftigen uns mit Code Review (RC), um die Qualität des Codes zu verbessern, und möchten daher die Team- und Unternehmenskultur positiv beeinflussen. Zum Beispiel:

• Die Autoren des Kodex sind motiviert, weil sie wissen, dass ihr Prüferteam ihre Änderungswünsche berücksichtigen wird: Der Autor versucht, die Rauheit zu beseitigen, den Aktionsplan zu befolgen und das gesamte Commit im Allgemeinen zu verbessern. Wenn Kollegen Ihre Professionalität beim Schreiben von Code anerkennen, ist dies für viele Programmierer eine Gelegenheit, stolz auf sich zu sein.
  
• Der Austausch von Wissen hilft dem Entwicklungsteam auf verschiedene Weise:
  

- Im Rahmen des RK wird klar angegeben, welcher Teil der Funktionalität hinzugefügt / geändert / gelöscht wurde, damit sich die Teammitglieder in Zukunft auf die bereits geleistete Arbeit verlassen können.

- Der Autor des Codes kann eine Technik oder einen Algorithmus verwenden, anhand derer die Prüfer selbst etwas lernen. Insgesamt hilft eine Codeüberprüfung dabei , die Messlatte für Qualität im gesamten Unternehmen höher zu legen .

- Die Prüfer wissen möglicherweise etwas über Programmiertechniken oder die Codebasis selbst, um die vorgenommenen Änderungen zu verbessern oder zu konsolidieren. Zum Beispiel kann jemand gleichzeitig genau die gleiche Gelegenheit entwickeln oder modifizieren.

- Positiver Kontakt und Kommunikation stärken die sozialen Bindungen zwischen den Teammitgliedern.

• Aufgrund der Konsistenz in der Codebasis ist der Code selbst viel einfacher zu lesen und zu verstehen. Es ist einfacher, Fehler zu vermeiden und die Zusammenarbeit zwischen etablierten und nomadischen Programmierern zu fördern.
  
• Für den Autor des Codes ist es schwierig, die Lesbarkeit seiner eigenen Kreation zu beurteilen, und der Rezensent ist einfach, weil er nicht sieht, in welchem ​​Kontext dieser Code steht. Von Menschen lesbarer Code ist einfacher wiederzuverwenden, weist weniger Fehler auf und ist langlebiger.
  
• Zufällige Fehler (z. B. Tippfehler) sowie strukturelle Fehler (z. B. nicht ausführbarer Code, Fehler in Logik oder Algorithmen, Leistungs- und Architekturprobleme) sind für einen wählerischen Prüfer, der den Code von der Seite betrachtet, häufig viel einfacher zu erkennen. Untersuchungen zufolge wirkt sich bereits eine kurze und inoffizielle Codeüberprüfung erheblich auf die Qualität des Codes und das Auftreten von Fehlern aus .
  
• Compliance-Anforderungen und gesetzliche Rahmenbedingungen erfordern häufig obligatorische Überprüfungen. Eine Codeüberprüfung ist eine gute Möglichkeit, um häufig auftretende Sicherheitsprobleme zu vermeiden. Wenn die Sicherheitsanforderungen in dieser Umgebung oder in Bezug auf diese Gelegenheit erhöht werden, wird die Überprüfung von Satrapen der Regulierungsbehörden empfohlen (oder sogar angefordert) (ein gutes Beispiel ist der OWASP- Leitfaden).

Worauf zu achten ist

Es gibt keine klare Antwort auf diese Frage, und jedes Entwicklungsteam muss sich auf seinen eigenen Ansatz einigen. Einige Teams ziehen es vor, nach Änderungen am Hauptentwicklungszweig zu suchen, während andere den „Trivialitätsschwellenwert“ berücksichtigen, ab dem eine Überprüfung erforderlich ist. In diesem Fall muss ein Gleichgewicht zwischen der effizienten Nutzung der Zeit des Programmierers (sowohl des Autors als auch des Codeprüfers) und der Aufrechterhaltung der Codequalität hergestellt werden. In einigen strengen Kontexten ist es manchmal erforderlich, alles, auch die trivialsten Änderungen, im Code zu überprüfen.

Die Regeln für die Codeüberprüfung sind für alle gleich: Selbst wenn Sie der älteste Entwickler im Team sind, bedeutet dies nicht, dass für Ihren Code keine Überprüfung erforderlich ist. Selbst wenn (manchmal) der Code perfekt ist, eröffnet die Überprüfung Möglichkeiten für Mentoring und Zusammenarbeit und hilft zumindest dabei, die Codebasis aus verschiedenen Blickwinkeln zu betrachten.

Wann zu überprüfen

Eine Codeüberprüfung sollte nach erfolgreichem Abschluss der automatischen Überprüfungen (Tests, Ausführung, andere Phasen der kontinuierlichen Integration), jedoch vor der Zusammenführung des neuen Codes mit dem Haupt-Repository-Zweig erfolgen. Normalerweise greifen wir nicht auf eine formelle Überprüfung der gesamten Änderungen zurück, die seit der letzten Veröffentlichung am Code vorgenommen wurden.

Versuchen Sie bei komplexen Änderungen, die als einzelne Einheit zum Hauptzweig des Codes hinzugefügt werden sollten, aber so umfangreich sind, dass sie nicht in einer Prüfung behandelt werden können, eine schrittweise Überprüfung. Wir erstellen das primäre Feature / Big-Feature-Zweig und eine Reihe von sekundären (z. B. Feature / Big-Feature-API, Feature / Big-Feature-Test usw.), von denen jedes eine Teilmenge der gemeinsamen Funktionalität und jeden solchen Zweig kapselt gegen den Hauptzweig von Feature / Big-Feature geprüft. Nachdem alle sekundären Zweige zu Feature / Big-Feature zusammengeführt wurden, erstellen Sie eine Codeüberprüfung, um diese in den Hauptzweig einzufügen.

Code zur Überprüfung vorbereiten

Der Autor des Codes ist verpflichtet, den Code für die Überprüfung in verdaulicher Form bereitzustellen, um den Überprüfern keine zusätzliche Zeit zu nehmen und sie nicht zu demotivieren:

• Umfang und Größe . Änderungen sollten sich auf einen engen, genau definierten und autarken Bereich beziehen, der vollständig von der Überprüfung abgedeckt wird. Beispielsweise können Änderungen im Zusammenhang mit der Implementierung einer Funktion oder einer Fehlerbehebung stehen. Kurze Änderungen sind langen vorzuziehen. Wenn die Überprüfung Material enthält, das Änderungen in mehr als ~ 5 Dateien enthält, oder die Aufzeichnung länger als 1-2 Tage dauert oder die Überprüfung selbst mehr als 20 Minuten dauern kann, versuchen Sie, das Material in mehrere in sich geschlossene Fragmente zu zerlegen und jedes einzeln zu überprüfen. Ein Entwickler kann beispielsweise eine Änderung einreichen, die die API für eine neue Funktion in Bezug auf Schnittstellen und Dokumentation definiert, und dann eine zweite Änderung hinzufügen, die die Implementierungen für diese Schnittstellen beschreibt.
  
• Sie müssen nur vollständige, unabhängig getestete (diff verwenden) und unabhängig getestete Materialien senden. Um dem Prüfer Zeit zu sparen, testen Sie die übermittelten Änderungen (d. H. Führen Sie die Testsuite aus) und stellen Sie sicher, dass der Code alle Assemblys sowie alle Tests und alle Phasen der Qualitätskontrolle sowohl lokal als auch auf Servern für die kontinuierliche Integration besteht, und wählen Sie erst dann aus Rezensenten .
  
• Refactoring-Änderungen sollten sich nicht auf das Verhalten auswirken und umgekehrt. Änderungen, die sich auf das Verhalten auswirken, sollten keine Umgestaltung oder Neuformatierung des Codes beinhalten. Dafür gibt es eine Reihe guter Gründe:
  

- Änderungen im Zusammenhang mit dem Refactoring wirken sich normalerweise auf viele Codezeilen in vielen Dateien aus. Daher wird dieser Code nicht so sorgfältig geprüft . Ungeplante Verhaltensänderungen können in die Codebasis gelangen, und niemand wird es bemerken.

- Wesentliche Änderungen im Zusammenhang mit Refactoring verletzen die Mechanismen der Bewegung, Auswahl und anderer "Magie", die mit der Quellcodeverwaltung verbunden sind. Es ist sehr schwierig, eine solche Verhaltensänderung rückgängig zu machen, die nach Abschluss des Refactorings vorgenommen wurde, das das gesamte Repository abdeckte.

- Die teure Arbeitszeit, die eine Person mit der Überprüfung von Code verbringt, sollte zur Überprüfung der Programmlogik und nicht zur Diskussion über Stil, Syntax oder Formatierung des Codes verwendet werden. Wir bevorzugen es, solche Probleme mit automatisierten Tools zu lösen, insbesondere Checkstyle , TSLint , Baseline , Prettier usw.

Nachrichten festschreiben

Das Folgende ist ein Beispiel für eine kompetente Festschreibungsnachricht, die gemäß dem weit verbreiteten Standard entworfen wurde:

 ( 80 )    ,  ,   .   72 .          ,    —   .   ,       (   );     ,  rebase,    .  -   : « »,   « »   « ».      -,  , ,  git merge  git revert.      .    . 

Versuchen Sie, die während des Commits vorgenommenen Änderungen zu beschreiben und wie genau diese Änderungen vorgenommen werden:

 > .   .    . > .  jcsv-     IntelliJ 

Suche nach Rezensenten

Normalerweise sucht der Autor eines Commits nach einem oder zwei Reviewern, die mit der Codebasis vertraut sind. In dieser Funktion sind häufig der Projektmanager oder der leitende Ingenieur tätig. Es ist ratsam, dass der Projektbesitzer sein eigenes Projekt abonniert, um Benachrichtigungen über neue Codeüberprüfungen zu erhalten. Bei Teilnahme von drei oder mehr Gutachtern erweist sich eine Codeüberprüfung häufig als unproduktiv oder kontraproduktiv, da verschiedene Gutachter möglicherweise widersprüchliche Änderungen vorschlagen. Dies kann auf grundsätzliche Meinungsverschiedenheiten über die korrekte Implementierung hinweisen. Solche Probleme sollten nicht während der Codeüberprüfung gelöst werden, sondern bei einem erweiterten Meeting, an dem alle interessierten Parteien persönlich oder in einem Videokonferenzmodus teilnehmen.

Ausführung der Codeüberprüfung

Eine Codeüberprüfung ist ein Synchronisationspunkt zwischen verschiedenen Teammitgliedern, sodass möglicherweise die Arbeit eingestellt werden kann. Daher sollte die Codeüberprüfung betriebsbereit sein (etwa mehrere Stunden, nicht Tage), und Teammitglieder und Führungskräfte sollten sich darüber im Klaren sein, wie viel Zeit für die Überprüfung erforderlich ist, und die ihr zugewiesene Zeit entsprechend priorisieren. Wenn Sie den Eindruck haben, dass Sie keine Zeit haben, die Überprüfung rechtzeitig abzuschließen, teilen Sie dies dem Autor des Commits unverzüglich mit, damit er einen Ersatz für Sie finden kann.

Die Überprüfung sollte ziemlich gründlich sein, damit der Prüfer die Änderung einem anderen Entwickler mit ausreichenden Details erklären kann. Wir werden also sicherstellen, dass die Details der Codebasis mindestens zwei und nicht einem bekannt sind.

Als Prüfer müssen Sie die Code-Qualitätsstandards einhalten und auf einem hohen Niveau halten. Eine Codeüberprüfung ist eher eine Kunst als eine Wissenschaft. Dies kann nur in der Praxis gelernt werden. Ein erfahrener Prüfer sollte zuerst versuchen, weniger erfahrene Kollegen ändern zu lassen und sie als erste bewerten zu lassen. Wenn der Autor die oben genannten Regeln befolgt hat (insbesondere diejenigen, die sich auf Selbsttests und vorläufige Codeausführung beziehen), sollte der Prüfer bei der Überprüfung Folgendes beachten:

Zweck

• Erreicht der Code das vom Autor festgelegte Ziel? Jede Änderung muss einen bestimmten Grund haben (neue Funktion, Refactoring, Fehlerbehebung usw.). Führt uns der vorgeschlagene Code wirklich zu diesem Ziel?
  
• Fragen stellen. Funktionen und Klassen müssen begründet sein. Wenn ihre Zuordnung zum Prüfer nicht klar ist, bedeutet dies möglicherweise, dass der Code neu geschrieben oder durch Kommentare oder Tests unterstützt werden sollte.
  

Implementierung

• Überlegen Sie, wie Sie dieses Problem lösen würden. Wenn nicht, warum dann? Behandelt Ihr Code mehr (Grenz-) Fälle? Vielleicht ist es kürzer / einfacher / sauberer / schneller / sicherer und funktionell nicht schlechter? Vielleicht haben Sie eine tiefe Regelmäßigkeit festgestellt, die vom vorhandenen Code nicht abgedeckt wird?
  
• Sehen Sie das Potenzial, nützliche Abstraktionen zu erstellen? Wenn der Code teilweise dupliziert wird, bedeutet dies häufig, dass ein abstrakteres oder allgemeineres Element der Funktion daraus extrahiert werden kann, das dann in anderen Kontexten wiederverwendet werden kann.
  
• Denken Sie wie ein Gegner, bleiben Sie aber nett. Versuchen Sie, Autoren zu „fangen“, die Abstriche machen oder bestimmte Fälle verpassen, indem Sie problematische Konfigurationen / Eingabedaten auslösen, die ihren Code beschädigen.
  
• Denken Sie an Bibliotheken oder vorgefertigten Arbeitscode. Wenn jemand die vorhandene Funktionalität erneut implementiert, liegt dies nicht nur daran, dass er nicht über die Existenz einer vorgefertigten Lösung Bescheid weiß. Manchmal wird Code oder Funktionalität absichtlich neu erfunden - zum Beispiel, um Abhängigkeiten zu vermeiden. In diesem Fall sollte dies im Code deutlich kommentiert werden. Ist diese Funktionalität bereits in einer vorhandenen Bibliothek verfügbar?
  
• Passt die Änderung zu den Standardmustern? In den vorhandenen Codebasen werden Regelmäßigkeiten häufig in Bezug auf Namenskonventionen, Zerlegung der Programmlogik, Definitionen von Datentypen usw. verfolgt. Es ist normalerweise wünschenswert, dass alle Änderungen in Übereinstimmung mit vorhandenen Mustern implementiert werden.
  
• Werden während einer Änderung Abhängigkeiten hinzugefügt, die während der Kompilierung oder zur Laufzeit (insbesondere zwischen Teilprojekten) auftreten? Wir bemühen uns um die schwache Kohärenz des Codes unserer Produkte, dh wir versuchen, ein Minimum an Abhängigkeiten zuzulassen. Änderungen in Bezug auf Abhängigkeiten und das Build-System sollten besonders sorgfältig geprüft werden.
  

Lesbarkeit und Stil

• Überlegen Sie, wie Sie diesen Code lesen. Können Sie seine Konzepte schnell genug verstehen? Ist es vernünftig angelegt, ist es einfach, die Namen von Variablen und Methoden im Auge zu behalten? Kann ich Code über mehrere Dateien oder Funktionen verfolgen? Wurden Sie jemals von inkonsistenten Namen gestört?
  
• Entspricht der Code bekannten Programmier- und Stilrichtlinien? Bricht der Code nach Stil, API-Namenskonventionen usw. aus dem gesamten Projekt aus? Wie oben erwähnt, versuchen wir, Stilstreitigkeiten mit automatischen Tools zu lösen.
  
• Hat der Code Aufgabenlisten (TODOs)? Aufgabenlisten sammeln sich einfach im Code an und werden schließlich zu Ballast. Weisen Sie den Autor zu, ein Ticket an GitHub Issues oder JIRA zu senden, und fügen Sie TODO eine Aufgabennummer hinzu. Die vorgeschlagene Änderung sollte keinen kommentierten Code enthalten.
  

Usability-Unterstützung

• Lesen Sie die Tests. Wenn der Code keine Tests enthält, diese aber vorhanden sein sollten, bitten Sie den Autor, einige zu schreiben. Wirklich ungetestete Features sind selten und nicht getestete Feature-Implementierungen - leider oft. Überprüfen Sie die Tests selbst: Decken sie interessante Fälle ab? Ist es bequem, sie zu lesen? Verringert sich die Gesamttestabdeckung nach diesem Test? Überlegen Sie, wie dieser Code fehlschlagen könnte. Testdesignstandards und Kerncode unterscheiden sich häufig, aber auch Teststandards sind wichtig.
  
• Besteht bei der Überprüfung dieses Fragments die Gefahr, dass Testcode, Einlaufcode oder Integrationstests beschädigt werden? Oft wird eine solche Überprüfung nicht vor dem Festschreiben / Zusammenführen durchgeführt, aber wenn solche Fälle vernachlässigt werden, leidet jeder. Beachten Sie Folgendes: Löschen von Testdienstprogrammen oder -modi, Ändern der Konfiguration, Änderungen im Layout / in der Struktur des Artefakts.
  
• Verstößt diese Änderung gegen die Abwärtskompatibilität? Wenn ja, ist es möglich, diese Änderung an der Version zu diesem Zeitpunkt vorzunehmen, oder sollte sie auf eine spätere Version verschoben werden? Zu den Verstößen können Änderungen an der Datenbank oder ihrem Schema, Änderungen an öffentlichen APIs, Änderungen am Aufgabenablauf auf Benutzerebene usw. gehören.
  
• Benötigt dieser Code Integrationstests? Manchmal kann der Code nur mit Komponententests nicht ordnungsgemäß überprüft werden, insbesondere wenn er mit externen Systemen oder Konfigurationen interagiert.
  
• Hinterlassen Sie Feedback zur Dokumentation für diesen Code, Kommentare und Commit-Nachrichten. Umfangreiche Kommentare verstopfen den Code und bedeuten, dass Commit-Nachrichten diejenigen verwirren, die später mit dem Code arbeiten müssen. Dies ist nicht immer der Fall, aber Qualitätskommentare und Commit-Nachrichten im Laufe der Zeit werden Ihnen sicherlich gute Dienste leisten. (Denken Sie daran, als Sie einen wunderschönen oder nur schrecklichen Kommentar oder eine Commit-Nachricht gesehen haben.)
  
• Wurde die externe Dokumentation aktualisiert? Wenn README, CHANGELOG oder andere Dokumentationen für Ihr Projekt verwaltet werden, werden sie aktualisiert, um die vorgenommenen Änderungen widerzuspiegeln? Veraltete Dokumentationen sind möglicherweise schädlicher als gar keine und es wird teurer sein, Fehler in Zukunft zu beheben, als jetzt Änderungen vorzunehmen.
  

Vergessen Sie nicht, den prägnanten / lesbaren / effizienten / schönen Code zu loben. Im Gegenteil, die Ablehnung oder Ablehnung eines zur Überprüfung vorgeschlagenen Codes ist nicht unhöflich. Wenn die Änderung übermäßig oder unbedeutend ist, lehnen Sie sie ab und erläutern Sie den Grund. Wenn Ihnen die Änderung aufgrund eines oder mehrerer schwerwiegender Fehler nicht akzeptabel erscheint, lehnen Sie sie erneut mit gutem Grund ab. Manchmal ist das beste Ergebnis einer Codeüberprüfung, zu sagen: "Machen wir es ganz anders" oder "Lass es uns überhaupt nicht machen".

Respekt Peer Review. Obwohl die Position des Gegners solide ist, haben Sie diese Gelegenheit nicht erkannt und können nicht alles für ihn entscheiden. Wenn Sie keine Peer-Review-Meinung zum Kodex erhalten können, vereinbaren Sie eine Echtzeit-Konsultation und hören Sie sich die Meinung einer dritten Person an.

Sicherheit

Stellen Sie sicher, dass alle API-Endpunkte gemäß den im Rest der Codebasis festgelegten Regeln ausreichend autorisiert und authentifiziert sind. Suchen Sie nach anderen häufigen Fehlern, z. B. schwache Konfiguration, böswillige Benutzereingaben, fehlende Protokolleinträge usw. Zeigen Sie im Zweifelsfall den von Experten geprüften Code einem Sicherheitsexperten.

Kommentare: prägnant, höflich, Anreiz

Die Überprüfung sollte präzise und neutral erfolgen. Kritisieren Sie den Code, nicht den Autor. Wenn etwas nicht klar ist - bitten Sie um Klarstellung und gehen Sie nicht davon aus, dass das Ganze in der Unwissenheit des Autors liegt. Vermeiden Sie Possessivpronomen, insbesondere bei Werturteilen: " Mein Code hat vor Ihren Änderungen funktioniert", " Ihre Methode weist einen Fehler auf" usw. Hacken Sie nicht die Schulter ab: "Es wird überhaupt nicht funktionieren", "Das Ergebnis ist immer falsch."

Versuchen Sie, zwischen Empfehlungen (z. B. „Empfehlung: Extrahieren Sie die Methode, dies macht den Code klarer“), notwendigen Änderungen (z. B. „ Override hinzufügen “) und Meinungen zu unterscheiden, die einer Klärung oder Diskussion bedürfen (z. B. „Stimmt dieses Verhalten? ? Wenn ja, fügen Sie bitte einen Kommentar hinzu, der die Logik erklärt. ”) Versuchen Sie, Links oder Zeiger auf eine detaillierte Beschreibung des Problems zu setzen.

Wenn Sie die Codeüberprüfung abgeschlossen haben, geben Sie an, wie detailliert die Reaktion auf Ihre Kommentare ist, die Sie vom Autor erwarten. Möchten Sie die Überprüfung wiederholen, nachdem die Änderungen vorgenommen wurden, z. B.: „Sie können den Code nach diesen geringfügigen Korrekturen sicher in den Hauptzweig hochladen“ oder „Bitte beachten Sie meine Kommentare und lass es mich wissen, wenn ich den Code wieder sehen kann. “

Antwort überprüfen

Die Codeüberprüfung soll insbesondere die vom Autor vorgeschlagene Anforderung von Änderungen verbessern. Nehmen Sie daher die Empfehlungen des Prüfers nicht in Frage, nehmen Sie sie ernst, auch wenn Sie ihnen nicht zustimmen. Reagieren Sie auf jeden Kommentar, auch auf das übliche "ACK" (genehmigt) oder "erledigt" (erledigt). Erklären Sie, warum Sie diese oder jene Entscheidung getroffen haben, warum Sie bestimmte Funktionen in Ihrem Code haben usw. Wenn Sie mit dem Prüfer keine gemeinsame Meinung erzielen können, vereinbaren Sie eine Beratung in Echtzeit und hören Sie sich die Meinung eines externen Spezialisten an.

Korrekturen sollten in derselben Verzweigung, jedoch in einem separaten Commit behoben werden. Wenn Sie die Commits in der Überprüfungsphase zusammenhalten, ist es für den Überprüfer schwieriger, die Änderungen zu verfolgen.

Die Code-Zusammenführungsrichtlinie ist für verschiedene Teams unterschiedlich. In einigen Unternehmen vertraut das Zusammenführen von Code nur dem Projektbesitzer, in anderen kann ein Teilnehmer dies tun, nachdem sein Code überprüft und genehmigt wurde.

Überprüfung des Tête-à-Tête-Codes

Asynchrone diff-ähnliche Tools wie Reviewable, Gerrit oder GitHub eignen sich in der Regel hervorragend für Codeüberprüfungen. Wenn es sich um eine komplexe Überprüfung oder eine Überprüfung handelt, deren Teilnehmer sich in Bezug auf Erfahrung oder Professionalität stark unterscheiden, kann es effektiver sein, eine Überprüfung persönlich durchzuführen - entweder zusammen vor einem Monitor oder Projektor oder remote über Videokonferenzen oder Tools zur Bildschirmfreigabe.

Beispiele

In den folgenden Beispielen werden Überprüfungskommentare in Listen mit eingegeben

 //R: ... 

Inkonsistente Benennung

 class MyClass { private int countTotalPageVisits; //R:    private int uniqueUsersCount; } 

Inkonsistente Methodensignaturen

 interface MyInterface { /**  {@link Optional#empty},  s   . */ public Optional<String> extractString(String s); /**  null,  {@code s}   . */ //R:    :    // Optional<> public String rewriteString(String s); } 

Bibliotheksnutzung

 //R:     MapJoiner   Guava String joinAndConcatenate(Map<String, String> map, String keyValueSeparator, String keySeparator); 

Persönliche Vorlieben

 int dayCount; //R: :   numFoo   fooCount;   ,          

Bugs

 //R:    numIterations+1 –    ? //    –     numIterations? for (int i = 0; i <= numIterations; ++i) { ... } 

Architektonische Überlegungen

 otherService.call(); //R: ,      OtherService.    ? 

Über den Übersetzer

Der Artikel wurde von Alconost übersetzt.

Alconost lokalisiert Spiele , Anwendungen und Websites in 70 Sprachen. Muttersprachliche Übersetzer, Sprachtests, Cloud-Plattform mit API, kontinuierliche Lokalisierung, Projektmanager rund um die Uhr, jedes Format von Zeichenfolgenressourcen.

Wir machen auch Werbe- und Schulungsvideos - für Websites, die verkaufen, Image, Werbung, Schulung, Teaser, Expliner, Trailer für Google Play und den App Store.

Weitere Details