Heutzutage verwenden viele Leute Codeüberprüfungen in der Entwicklung. Die Übung ist nützlich, notwendig. Selbst wenn Sie keine Überprüfung durchführen, wissen Sie wahrscheinlich, was es ist.

Auf dem Markt gibt es eine Reihe von Tools zur Codeüberprüfung mit vorgefertigten Verwendungsszenarien, Empfehlungen und Regeln. GitHub, Phabricator, FishEye / Crucible, GitLab, Bitbucket, Upsource - die Liste geht weiter und weiter. Bei Badoo haben wir auch einmal mit ihnen zusammengearbeitet: In meinem vorherigen Artikel habe ich unsere Geschichte über Codeüberprüfungen erzählt und wie wir auf die Erfindung unserer eigenen „Fahrrad“ - Codeisok- Lösungen gekommen sind.

Es gibt viele Informationen. Sie können eine Reihe von Artikeln über Codeüberprüfungen mit realen Beispielen, Vorgehensweisen und Ansätzen googeln , die darüber sprechen, wie gut, wie schlecht, wie und wie - Sie müssen nicht, was Sie berücksichtigen müssen und was nicht usw. Im Allgemeinen wird das Thema "bis auf die Knochen gesaugt".

Deshalb wird der andere Teil des Eisbergs möglicherweise nicht bemerkt.

Ich hoffe, dass Sie die Dinge, die ich in diesem Artikel beschreiben werde, ernst nehmen, in einigen Fällen absichtlich übertreiben. Eine Überprüfung erfordert wie jeder andere Prozess eine sorgfältige und bewusste Implementierung, während der Ansatz „Wir werden, wenn auch nur alle anderen“ nicht nur scheitern, sondern sogar schaden kann.

Nach dem Lesen dieser Einführung haben Sie möglicherweise eine Frage: Was ist an der Codeüberprüfung kompliziert? Der Punkt ist unbedeutend. Darüber hinaus bieten die meisten der oben aufgeführten Tools sofort eine Flussüberprüfung an (sofort einsatzbereit: Festlegen, Festschreiben / Starten - und los geht's!).

Die Praxis zeigt jedoch, dass nicht alles so offensichtlich ist, wie es auf den ersten Blick scheint. Einschließlich aufgrund der imaginären Einfachheit des Prozesses. Wenn alles läuft, besteht die Gefahr, dass sich der Manager beruhigt und nicht mehr in den Prozess eintaucht und ihn an die Entwickler weitergibt. Und sie werden entweder dem Prozess folgen oder etwas anderes tun, um die Probleme zu lösen, die durch den Überprüfungsprozess gelöst werden sollen. Dem Manager ist möglicherweise nicht bewusst, dass etwas schief geht, da er keine Regeln festlegt oder Regeln auferlegt. Während es für ein Unternehmen sehr wichtig ist, Probleme so schnell wie möglich zu lösen, ohne Zeit für ungeplante Aktivitäten zu verschwenden.

Es war einmal, als ich in einem anderen Unternehmen arbeitete, war ich tief versenkt von dem Gespräch über Codeüberprüfungen mit einem der führenden Entwickler. Es war viel . Vielleicht ist einer der Leser mit ihm vertraut (p1lot, hallo :)). Derzeit arbeitet er mit uns bei Badoo, was großartig ist.

PILOT sagte dann: "Das Schwierigste für mich im Überprüfungsprozess ist es, die fertige und korrekt funktionierende Aufgabe weiter zu kompromittieren und zu überspringen, selbst wenn ich einen anderen Weg kenne, sie zu lösen, und selbst wenn mir meine Methode besser gefällt." Meiner Meinung nach ist dies ein Schlüsselgedanke. Und die Hauptbotschaft meines ganzen Artikels dreht sich irgendwie um dieses Postulat.

Warum brauche ich einen Codeüberprüfungsprozess?

Haben Sie eine Bewertung in Ihrem Unternehmen? Machst du es richtig Ich habe einen Test, der Sie daran zweifeln lässt.

Sie müssen nur drei Fragen beantworten:

1. Wie lange dauert eine Codeüberprüfung für eine durchschnittliche Aufgabe (sphärisch im Vakuum)?
   
2. Wie minimieren Sie die Überprüfungszeit?
   
3. Wie stellen Sie fest, ob eine Überprüfung einer bestimmten Aufgabe korrekt durchgeführt wurde?
   

Wenn Sie keine klaren Antworten auf einige (oder alle) Fragen haben, wenn Sie an Ihren Antworten zweifeln, dann wage ich anzunehmen, dass etwas schief geht.

Wenn Sie nicht wissen, wie lange die Überprüfung dauern wird, und sie nicht ständig minimieren, wie planen Sie dann? Ist es möglich, dass der Darsteller, der die Rezension vier Stunden lang durchgeführt hat, diesmal nicht die Hälfte Tee getrunken hat? Kann man sicher sein, dass die Zeit für das Teetrinken nicht von Aufgabe zu Aufgabe zunimmt? Oder sieht sich der Prüfer den Code überhaupt nicht an, sondern klickt einfach auf „Code ist OK“?

Und selbst wenn die Überprüfung in gutem Glauben erfolgt, wie können wir sicherstellen, dass sich mit dem Wachstum der Codebasis und des Unternehmens die Zeit für die Erledigung der Aufgaben nicht verlängert? Schließlich erwartet das Management in der Regel, dass Prozesse beschleunigt und nicht verlangsamt werden.

Wenn die Antwort auf die dritte Frage nicht sofort in den Sinn kommt, ist es sinnvoll, noch eine Frage zu stellen. Wissen Sie, warum Sie diesen Prozess wirklich brauchen? Weil "ist so üblich für alle großen Jungs"? Vielleicht brauchst du ihn überhaupt nicht?

Wenn Sie Ihre Leads und Entwickler nach der „richtigen“ Codeüberprüfung fragen, werden Sie sehr überrascht sein, wie unterschiedlich die Dinge sind, die Sie hören. Die Antworten können je nach persönlicher Erfahrung, Überzeugung, persönlichem Vertrauen in die Richtigkeit oder Unrichtigkeit der Dinge und sogar je nach verwendetem Technologie-Stack und Entwicklungssprache variieren.

Erinnern Sie sich an die vorgefertigten Tools für die Codeüberprüfung, die ihre eigenen Ansätze und Abläufe bieten? Ich frage mich zum Beispiel, wie die Entwickler dieser Tools die Frage beantworten würden. Korrelieren ihre Antworten zur „Richtigkeit“ der Überprüfung mit den Antworten Ihrer Mitarbeiter? Nicht sicher. Manchmal beobachte ich leider, wie jemand zu Hause Überprüfungswerkzeuge implementiert, ohne eine Minute lang daran zu zweifeln, dass sie notwendig sind. Entweder machen die Leute es "zur Show" oder um zu berichten, dass "sie die Codeüberprüfung implementiert haben, ist alles in Ordnung." Und am Ende vergessen sie es.


Ich möchte kein Cap sein, aber trotzdem. Achten Sie bei der Kommunikation mit Mitarbeitern auf Antworten wie "Weil es so etabliert ist" oder "Dies ist die beste Vorgehensweise, jeder tut es". Sie selbst sind sich bewusst, dass Sie einen Prozess nicht gedankenlos implementieren müssen, ohne zu verstehen, warum er benötigt wird. Jeder Prozess sollte gerechtfertigt und (falls erforderlich) implementiert werden, angepasst an die Anforderungen des Unternehmens und des Projekts sowie an Probleme, die wirklich existieren und die Sie wirklich lösen möchten. Frachtkult in einem Unternehmen mit einer guten Ingenieurkultur gehört nicht dazu.

Dementsprechend ist es für den Manager wichtig, den Menschen die „richtige“ Codeüberprüfung zu vermitteln, die genau in seinem Projekt erforderlich ist. Und vorher sollten natürlich die Kriterien der „Korrektheit“ für Sie selbst formuliert werden, die richtigen Werkzeuge auswählen und die entsprechenden Regeln festlegen. Und es gibt schon fast die Kontrolle.

Schlechte Codeüberprüfung

Was ist der richtige Prozess? Lass es uns richtig machen. Im Folgenden finden Sie viele meiner persönlichen Überlegungen. Für diejenigen, die es kaum erwarten können, herauszufinden, was ich all dies schreibe, schlage ich vor, sofort zum Teil "Gute Codeüberprüfung" zu gehen.

Ich danke denen, die geblieben sind, und schlage dennoch vor, die Richtigkeit der Überprüfung selbst zu bestimmen, basierend auf den Anforderungen Ihres Projekts, und alles sorgfältig zu prüfen. Und ich versuche nur, Ihnen dabei zu helfen.

Um wichtige und notwendige Dinge in jedem Prozess für sich selbst hervorzuheben, kann es nützlich sein, zunächst offensichtlich unnötige Dinge abzuschneiden, die der Ingenieurkultur schaden. Also lass es uns tun.

Wissensaustausch

Auf die Frage "Warum brauche ich einen Codeüberprüfungsprozess?" Ich habe die Antwort " Wissen teilen " oft gehört. In der Tat eine nützliche und notwendige Sache. Und viele sind sich einig, dass es wichtig ist, einen Prozess im Team für den Austausch von Wissen und Know-how zu haben. Aber sind Sie sicher, dass die Codeüberprüfung dafür geeignet ist?


Ich habe wiederholt Leute gefragt, was sie unter "Wissensaustausch" verstehen. Und als Antwort hörte ich verschiedene Dinge.

Erstens ist dies eine Demonstration für die Neuankömmlinge (im Team oder in der betroffenen Komponente) der akzeptierten Regeln und Praktiken: So ist es für uns üblich, dies zu tun, und wir tun es nicht, deshalb und deshalb.

Zweitens ist dies ein frischer Blick eines Anfängers (wieder in einem Team oder einer betroffenen Komponente), wie gewöhnliche Dinge gemacht werden. Plötzlich werden sie ineffizient erledigt, und wird eine neue Person helfen, dies zu entdecken?

Drittens ist dies nur eine Einführung in einen Teil des Codes. Wenn der Prüfer in Zukunft mit der Notwendigkeit konfrontiert wird, diesen Teil des Codes zu ändern, wird dies für ihn viel einfacher.

Lassen Sie uns alle Punkte durchgehen und versuchen, zu bewerten, wie relevant sie für den Überprüfungsprozess sind.

Codeüberprüfung als Trainingswerkzeug für Anfänger

In diesem Fall handelt es sich hauptsächlich um ein solches Szenario: Ein Anfänger erhält eine Aufgabe, er führt sie aus, und dann zeigt ein erfahrenes Teammitglied (Eigentümer der Komponente) die Fehler an, die er gemacht hat. Der Prozess ist wichtig und notwendig, ich behaupte nicht - Anfänger müssen irgendwie die im Team akzeptierten Regeln zeigen.

Aber seien wir ehrlich: Ist es nicht zu spät? Wäre es nicht richtiger, den Anfänger über diese Regeln zu informieren, bevor er zum Code zugelassen wird? Immerhin ist der Preis eines Fehlers sehr hoch - selten arbeiten Anfänger sofort so, wie Sie es brauchen. Die Aufgabe wird also zurückkommen und zur Überarbeitung zurückkommen. Das Produkt wird dem Benutzer also später als möglich zur Verfügung stehen.

Es stellt sich heraus, dass wir in einem Prozess, dessen Dauer schwer zu bewerten ist, einen weiteren hinzufügen, dessen Zeitkosten noch weniger vorhersehbar sind. Dadurch erhöhen wir den Zeitaufwand für die Zustellung der Aufgabe an den Benutzer um einen noch unbekannteren Betrag.

Natürlich hat manchmal die Ausbildung von Anfängern durch Arbeitsprozesse ein Existenzrecht. Aber manchmal denken wir nicht an die Mängel der Ansätze, die zur Gewohnheit geworden sind. Und hier einen Fehler zu machen ist nicht nur einfach, sondern auch sehr einfach.

Wenn das Unternehmen beispielsweise nicht über einen optimierten Schulungs- und Coachingprozess verfügt , muss der Manager einen Neuling „ins Wasser werfen“. Gleichzeitig hat letzterer keine Wahl: Sie müssen entweder "schwimmen" oder die Firma verlassen. Jemand lernt wirklich aus solchen Situationen und jemand steht nicht auf. Ich denke, viele sind auf ihrem beruflichen Weg auf ähnliche Probleme gestoßen. Meine Botschaft ist, dass die wertvollste Zeit aufgrund dieses Phänomens nicht optimal verbracht werden kann. Neben der Anpassung eines neuen Mitarbeiters in einem Team ist dies möglicherweise nicht optimal. Nur weil niemand die Hände hatte, um einen effektiven Prozess zur Einführung neuer Mitarbeiter in das Team zu organisieren, und der Manager dachte, dass der Neuankömmling in der Phase der Codeüberprüfung alles lernen würde. Tatsächlich sind dies jedoch zwei verschiedene Prozesse, die sehr notwendig und wichtig sind.

Selbst unter den Bedingungen, dass die Regeln dem Anfänger ursprünglich erklärt wurden und das Unternehmen über andere Schulungsprozesse verfügt, muss der Anpassungsprozess des Anfängers natürlich irgendwie gesteuert werden. Eine Überprüfung ist ein Prozess, der helfen kann. Aber Kontrolle und Training sind zwei verschiedene Dinge, oder? Darüber hinaus brauchen alle Mitglieder des Teams Kontrolle und nicht nur Anfänger. Schließlich können wir alle Fehler machen, die Vereinbarungen vergessen und irgendwie den Teil des Systems beeinflussen, den das gesamte Team besitzt (in diesem Fall den Code).

Welche Schlussfolgerung kann gezogen werden? Der oben beschriebene Prozess zielt darauf ab, ein anderes Ziel zu erreichen: nicht zum Training, sondern zur Kontrolle. Und diese Kontrolle ist nicht nur für Anfänger, sondern für das gesamte Team notwendig.

All dies lässt sich leicht in der folgenden These formulieren: "Eine Codeüberprüfung ist erforderlich, um die Einhaltung von Vereinbarungen und allgemeinen Regeln durch alle Teammitglieder zu überwachen ." Und die Ausbildung von Anfängern ist in diesem Fall nichts anderes als eine künstliche Substitution eines Ziels, das die Menschen nur verwirrt und den Prozess in eine andere Richtung lenkt.

Aber selbst mit dieser Schlussfolgerung, die anscheinend richtig formuliert wurde, kann Brennholz gebrochen werden. Eine Codeüberprüfung ist eine Phase, die beginnt, wenn der Code bereits geschrieben ist. Und es kann vorkommen, dass Code, der ohne Befolgung der allgemeinen Regeln geschrieben wurde, sehr teuer ist, um ihn an das allgemeine Muster anzupassen. Unsere Aufgabe ist es, den Auftragnehmer so früh wie möglich darüber zu informieren, dass ein Fehler aufgetreten ist. Daher argumentiere ich, dass Codeüberprüfungen manchmal nicht der am besten geeignete Prozess zur Überwachung der Einhaltung allgemeiner Regeln sind. In vielen Fällen können und sollten Konformitätsprüfungen auf frühere Phasen übertragen werden.

Sie können beispielsweise die Formatierung des Codes in den Hooks des Versionskontrollsystems überprüfen (sowie die Verwendung sicherer Klassen, Vorkehrungen für den Speicherort von Dateien in den entsprechenden Ordnern, die Verwendung externer Abhängigkeiten und Bibliotheken von Drittanbietern usw.). Dies minimiert den Zeitaufwand für die Codeüberprüfung.

Lassen Sie uns eine Analogie ziehen, um das Gespräch über das Training von Anfängern im Prozess der Codeüberprüfung fortzusetzen. Angenommen, Sie stellen eine Art Produkt her, zum Beispiel Kuchen. Angenommen, Sie haben eine Kuchenbestellung für eine VIP-Hochzeit erhalten. Vertrauen Sie die „Überprüfung“ des fertigen Kuchens dem Neuling an? Sind Sie bereit, dass der neue Konditor bei dieser Hochzeit die Verantwortung für die Schande oder den Erfolg der gesamten Bäckerei übernimmt? Oder möchten Sie, dass er sich zu diesem Zeitpunkt mit den vom Team festgelegten Regeln vertraut macht (wie man Kuchen backt, Sahne zubereitet und auf Preiselbeeren auf Cognac besteht)? Offensichtlich sind sowohl der Prozess der Einführung des Anfängers in die Regeln als auch die Kontrolle seinerseits in dieser Phase ziemlich seltsame Dinge: Der Kuchen wurde bereits gebacken. Warum können wir also mit Funktionen und Code anders handeln? Oder bringen die Funktionen, die wir einführen, weder Scham noch den Erfolg unseres Teams in den Augen von Benutzern und Kunden?

Sie können Einwände erheben und sagen, dass wir nicht jeden Tag Aufgaben „für wichtige Personen“ vorbereiten und dass es durchaus möglich ist, dass Anfänger mit einer nicht sehr dringenden oder nicht sehr wichtigen Aufgabe betraut werden. Und du wirst recht haben.

Aber erstens, was lernt ein Anfänger aus trivialen Aufgaben, bei denen es nur wenige Codeänderungen gibt (und diese Änderungen sind nicht an kritischen Stellen und für Unternehmen wahrscheinlich nicht so wichtig, da die Aufgabe dringend ist)? Wie kann er lernen, Kuchen zu backen, wenn er die ganze Zeit die Sahne peitscht? Der Übergang von einfach zu komplex ist natürlich erforderlich. Dies ist jedoch erforderlich, um den Prozess sorgfältig zu steuern. Anfänger müssen unterrichtet werden und dürfen nicht alleine aufhören zu lernen.

Und zweitens kann selbst ein scheinbar nützlicher und korrekter Ansatz einem Unternehmen schaden. Dies zu verstehen ist sehr einfach, indem man die Methode verwendet , um den Punkt der Absurdität auf den Punkt zu bringen, um die Schlussfolgerung so einfach und verständlich wie möglich zu machen.

Stellen Sie sich vor, wir erklären offen, dass die Aufgaben, die uns der Produktmanager gibt, für die Schulung von Neuankömmlingen erforderlich sind. Warum? Und das Gleiche wie bei der Codeüberprüfung: Schließlich vertrauen wir Anfängern einige einfache und nicht dringende Aufgaben an, damit sie lernen, wie es bei uns üblich ist.

Was kann das am Ende bewirken? Ein eifriger Künstler, der seinen Job treu macht und glaubt, dass alles, was er tut, so gut wie möglich gemacht werden sollte, wird den Lernprozess übernehmen. Er kann die Aufgabe festlegen, mehrere Implementierungen anstelle einer durchzuführen, damit er dem Lernenden später die Nachteile und Vorteile verschiedener Ansätze aufzeigen kann. Er kann Vorträge halten und die Ansätze und Best Practices im Unternehmen und darüber hinaus vergleichen. Er kann viel mehr tun, um den Anfänger zu erziehen. Infolgedessen erhöht sich der Zeitaufwand für die Erledigung der Aufgabe, da wir uns statt der Entwicklung auf das Training konzentrieren .

Im Falle einer Codeüberprüfung initiiert ein solch eifriger Mitarbeiter eine lange Diskussion in den Kommentaren zur Überprüfung über die Vorteile und Gefahren bestimmter Implementierungen, veröffentlicht Codeteile mit Stapelüberlauf, zeigt, dass andere Ideen in anderen Köpfen enthalten sind, und gibt Links zu Artikeln und Büchern, die der Schüler verwenden sollte Lesen Sie, um zu verstehen, dass die Implementierung nicht perfekt ist.

Dies ist ein normaler Lernprozess, der existieren kann, aber korrekt durchgeführt werden muss. Und es lohnt sich bei weitem nicht, es in den Prozess der Lösung eines Geschäftsproblems zu integrieren. Weil dies zwei verschiedene Prozesse sind. Lassen Sie den Anfänger die verschiedenen Bestandteile des Kuchens machen, lassen Sie ihn mehrere Optionen machen, lassen Sie etwas ruinieren und werfen Sie es weg. Lassen Sie sich von einem erfahrenen Menschen zeigen, wie man alte Rezepte verhält und nacherzählt. Es ist jedoch keine gute Idee, „in der Produktion“ zu lernen, wie Ihr Produkt für Kunden hergestellt wird. Und wenn Sie sich bereits dafür entschieden haben, führen Sie den Neuankömmling am Griff vorbei, damit er während seines Trainings nicht in den Produktionsprozess eingreifen kann.

Wenn Ihr Unternehmen keine Institution, keine Schule, keine technische Schule oder eine andere Bildungseinrichtung ist, liegt die Ausbildung nicht in Ihrer direkten Verantwortung. Das Unternehmen hat Sie beauftragt, andere Probleme zu lösen und andere Ergebnisse zu erzielen.

Aus diesem Grund fügen wir Codeisok keine Funktionen zum Hochladen von Bildern, Tippen und Hervorheben des Codes in Kommentaren hinzu, obwohl es viele Anfragen nach solchen Funktionen gab und gibt. Wir fördern die Idee, dass Code Review kein persönlicher Blog, kein Messenger und kein Schulungsdienst ist. Ein Werkzeug wird für ein anderes benötigt. Um auf die Fehler im Code hinzuweisen, ist ein Kommentar im Klartext mehr als ausreichend.

Codeüberprüfung als neuer Blick auf den Code

Lass uns weitermachen. Das folgende Szenario des „Erfahrungsaustauschs“ ist das folgende: Wir tun etwas im Team, beachten interne Vereinbarungen und unsere Augen sind verschwommen, und dann kam eine neue Person (von einem anderen Unternehmen oder einer anderen Komponente) - und vielleicht sieht er Fehler in unserem Organisation der Arbeit.

Die Idee ist gut, es klingt vernünftig. Was ist, wenn wir etwas falsch machen?

Aber noch einmal zurück zum Leben der Aufgabe und dem Beginn der Codeüberprüfungsphase. Ist es zu spät Der Kuchen ist bereits gebacken, die Kuchen sind mit Sahne bestrichen, die Rosen sind geklebt. Der Preis des Fehlers ist sehr hoch. Und dann finden wir heraus, dass in einer anderen Bäckerei in den Kuchen Soda, mit Zitronensaft gelöscht, für Pracht hinzugefügt wird. Na und? Was zu tun ist? Umgestalten?

Offensichtlich nicht, weil: 1) wir immer auf Soda verzichteten und das Ergebnis nicht schlecht war; 2) Es ist möglich, dass Kunden Kuchen von uns und nicht von einer anderen Bäckerei nehmen, weil sie den Geschmack von Soda nicht mögen. 3) Der Kuchen ist fertig, die Hochzeit ist heute Abend und wir haben keine Zeit, einen neuen Kuchen zu backen.

Warum ist das alles? Es ist notwendig, Erfahrungen auszutauschen. Ein frischer Look ist erforderlich. Aber es scheint mir in einem anderen Stadium. Zum Beispiel können Sie vor dem Backen von Kuchen bei einem Anfänger nachfragen: „Und wie haben Sie das vorher gemacht? Warum ist diese Methode besser? " Und wahrscheinlich lohnt es sich, ein paar Kuchen auf alte und neue Weise zu backen, um unseren Stammkunden zu versuchen, ihre Meinung zu erfahren.

Die gedankenlose Implementierung der in Artikeln oder Berichten enthaltenen Best Practices kann dem Unternehmen und dem Produkt schaden. "Soda wird Kuchen von allen großen Spielern hinzugefügt:" Bugle "," Tracebook "," Rile.ru "," Yumdeks ". Jeder macht es. " Na und? Sollte Petya aus diesem Grund sofort ein Remake einer bereits fertig gestellten Aufgabe in Angriff nehmen?

Ich bin sicher nicht. Wenn Sie vor der Lösung des Problems zunächst nicht einverstanden waren, dass „Soda in den Kuchen enthalten ist“, ist es sehr kurzsichtig, die Hinzufügung in der Phase der Codeüberprüfung zu fordern. Ihr Unternehmen hat nicht das Ziel, "Soda in Kuchen zu haben". Wenn sich Ihre Kuchen bereits gut verkaufen, spielt es keine Rolle, ob sie Soda haben oder nicht.

Sie müssen verstehen, dass der Erfahrungsaustausch ein weiterer Prozess ist, der in keiner Weise an eine Codeüberprüfung gebunden ist. Es kann früher, später oder parallel dazu auftreten, aber es ist anders. Sie können gegenseitige Meisterkurse mit Wettbewerbern vereinbaren. Einige versuchen, ein supergeheimes Rezept und eine hochmoderne Technik zum Schlagen von Sahne mit einem Perforator zu stehlen. Jemand versucht, die Ideen anderer Leute auszuspionieren und ihre Prozesse mit ihrer Hilfe zu verbessern. Es ist jedoch seltsam, dies auf einem funktionierenden Förderband zu tun, wenn Ihr Produkt fast fertig ist und der Preis für die Umstellung sehr hoch ist.

Immerhin sprechen wir über die Überprüfungsphase. Eine Codeüberprüfung, die bereits geschrieben wurde und für den nächsten Schritt bereit ist. Dieser Code wartet darauf, dass der Prüfer auf die Schaltfläche "Code ist OK" klickt. Und Ihre Kunden sind überhaupt nicht darauf vorbereitet, dass Sie mit einem neuen Koch einen gebackenen Kuchen zubereiten, um ihm zu zeigen, wie Sie Kuchen backen und auf seine Kritik hören.

Codeüberprüfung als Einführung in einen Code

Vielleicht scheint dies der vernünftigste und verständlichste Teil zu sein, dem viele zustimmen. Das Szenario hier wird wie folgt verstanden: Ein Programmierer hat den Aufgabencode geschrieben, der Rest hat ihn angeschaut, studiert und jetzt wissen sie, wie man damit arbeitet. Auf diese Weise reduzieren wir das Risiko eines Busfaktors : Wenn der Entwickler das Unternehmen verlässt, können andere erfolgreich mit seinem Code arbeiten. Und wir sind auch bereit für die Tatsache, dass dieser Code das nächste Mal von jemand anderem „berührt“ werden kann. In diesem Fall weiß er bereits, wie man damit arbeitet.

Lassen Sie uns darüber nachdenken, ob dies wirklich wie beabsichtigt funktioniert und ob es den Menschen wirklich hilft, Kompetenzen und Wissen über bestimmte Abschnitte des Codes auszutauschen.


Betrachten wir die Situation mit den Augen der Person, die den Code geschrieben hat. , ?

, - (, , , ). , ? , . , , , .

, , , , . . , ?

, - . , - . , : , . , , , , .

, . , - ? — . , , .

, , , - . , . , , . , , , . . , - : , , .

? , , — . .

best practices « -» « , ». Na und? Best practices , , . , ? . , - , .

best practices, , . . — - , / — . « », « », « — , DI». ? ?

, , . , , — , .

, -, «», , - . ? - , , , . , . , .

-, « » «» , . -, . , , - , : ? . , , ( : , ).

, , . , , ( , ?).

— . , , . . ? bus factor , , - , .

, , , : , ?

— , , ?
— .
— ?
— .

. , ? , , , ? , , , — ?

, , , , , ?

, , , . , , .

, . , , , ( ), , ( , , , — , . .). , .

— , , , . ( , , . .) . — — .

Code review

« ?» . , , .

: - , , - , , . git blame , , , , , .

, , — , , , ( ) — . , , . . , ?


. ?

, , , . , , , . , - ( , ). , , — , , , .

, , . ? , .

, , , . , . , ? .

, , — , . ( )?

« - - » . , . .

: . .

, , . , . , .

, , — . , .

— . , . , . , .

, , :

? , , ? ? , , ? - , ? ? ? Usw.

, . , . , .

, , . , , , . , , , .

, best practices, . , , , , . . , , . , .

,

. , , . - , , - .

, , . , API- . , bus factor, .

, . .

- ? , . , . null , « ». .

, . , ? ?

-

Diese Phase der Überprüfung ist ebenfalls sehr wichtig, da sie darauf abzielt, die berüchtigte Codeunterstützung zu verbessern.

Viele Menschen verstehen, was der Begriff Code-Wartbarkeit bedeutet, aber nicht jeder kann erklären, was er ist. Und wenn ja, wie kann dann die Aufgabe dem Team zugewiesen werden, um diese Wartbarkeit aufrechtzuerhalten? Daher glaube ich, dass ein Entwickler, der darüber nachdenkt, wie sein Code getestet wird, geschweige denn seinen eigenen Code testet und einen Autotest schreibt, um das Testen zu automatisieren, natürlich danach strebt, sicherzustellen, dass sein Code die meisten Kriterien für die Wartbarkeit des Codes erfüllt. In der Tat ist es ohne dies fast unmöglich, einen Autotest zu schreiben.

Die allgemeine Empfehlung für jede Codeänderung kann auch die korrekte Zerlegung von Aufgaben sein . Je weniger Code durch die Pipeline aller Prozesse von der Idee bis zur Produktion fließt, desto einfacher ist es, diesen Code auf Konformität zu überprüfen, zu testen, mit dem Code anderer Aufgaben zu kombinieren und hochzuladen. Eine Codeüberprüfung ist keine Ausnahme. Eine Aufgabe mit einer großen Anzahl geänderter Zeilen in vielen Dateien ist sehr schwer zu lesen und zu verstehen (und Abhängigkeiten zu berücksichtigen). Das Risiko und die Kosten für die Behebung von Fehlern können sehr hoch sein.

Fazit

Das ist in der Tat alles. Diese vier Punkte sind genau die Dinge, die in der Überprüfungsphase überprüft werden müssen. Sie sind leicht zu formalisieren und den Darstellern leicht zu vermitteln, was bedeutet, dass es nicht schwierig ist, Überprüfungskriterien zu formulieren und die Dauer vorherzusagen. Automatisierung und andere Möglichkeiten zur Minimierung der Überprüfungszeit sind mehr als möglich.

Und zum Schluss gebe ich noch ein paar Tipps.

Es ist wichtig zu beachten, dass eine Rückgabe des Codes zur Überarbeitung die Qualität der Implementierung nicht optimal beeinflusst. Auch wenn jeder gut gemeinte. Bei Codeüberprüfungen funktioniert dies folgendermaßen: Der Entwickler korrigiert den Code, testet ihn jedoch nicht so gründlich wie in der ersten Iteration (warum? Schließlich hat er bereits alles überprüft und nur ein wenig geändert). Die Erfahrung hat gezeigt, dass die meisten dieser Situationen genau dort zu Fehlern werden, wo aufgrund der Ergebnisse der Codeüberprüfung Korrekturen vorgenommen wurden. So funktioniert die menschliche Psychologie.

Zu Beginn des Artikels schlug ich vor, dass Sie drei Fragen zur Notwendigkeit und Richtigkeit einer Überprüfung beantworten. Jetzt haben Sie einen Algorithmus, mit dem Sie die Antworten finden können. Wenn Sie die Steuerungsschritte kennen und die Größe der Aufgabe berücksichtigen, ist es durchaus möglich, die für die Codeüberprüfung erforderliche Zeit zu planen, wobei jedes Mal versucht wird, sie immer weiter zu reduzieren.

Bei der Implementierung eines Prozesses ist es wichtig, sich an die Ziele zu erinnern, die wir uns selbst gesetzt haben, und an die Probleme, die wir lösen möchten. Dann ist es viel einfacher, die Körner von der Spreu zu trennen und messbare Kriterien für die Bewertung der Wirksamkeit zu formulieren. Und Sie müssen sie für sich selbst und für Ihr Team formulieren, das auch dringend die aufgetretenen Probleme lösen muss, sie aber auf ihre eigene Weise verstehen kann.

Es gibt noch einen wichtigen Punkt: Die Prozesse, Regeln und Werte, die für ein Unternehmen fair sind, sind möglicherweise nicht so nützlich und funktionieren in einem anderen. Was ich als Beispiele für die korrekte Überprüfung beschrieben habe, funktioniert in unserem Unternehmen. Wir fördern eine schnelle Entwicklung, häufige Veröffentlichungen und Überprüfungen für jede Aufgabe. Überlegen Sie, wie zutreffend dies für Ihr Projekt ist und dass eine Überprüfung einer der Prozesse ist, die nicht dem Zufall überlassen werden dürfen.

Aber die Entscheidung bleibt natürlich bei Ihnen.