Vielleicht haben Sie den ersten Teil des Artikels über den Überprüfungscode des Überprüfers gelesen (wir haben es übrigens bereits in der letzten Ausgabe des Zinc Prod-Podcasts besprochen ).
Da der Artikel viele Likes erhielt, schreibe ich andererseits die versprochene Fortsetzung über die Codeüberprüfung - vom Autor der Codeänderungen
Wie üblich werden wir MR (Merge Request) anstelle von CL sagen, da nur wenige Menschen den Begriff CL verstehen.
Die Originalanweisungen für die Autoren von MR laut Google finden Sie hier , und ich werde kurz darauf eingehen.
Also lass uns gehen
Beschreibung von MR
Bei Google wird die Beschreibung der Änderungen im Verlauf des Versionskontrollsystems gespeichert, und es ist sehr wahrscheinlich, dass viele Benutzer sie in Zukunft lesen werden. Daher ist die Beschreibung von MR sehr wichtig.
Die erste Zeile (im Titel) sollte einen Satz enthalten, der beschreibt, was in MR getan wurde. Darüber hinaus wird gemäß der Tradition ein imperativer (imperativer) Stil verwendet, d.h. Blablabla löschen , nicht blablabla löschen
Die Beschreibung selbst sollte informativ sein, eine kurze Beschreibung des zu lösenden Problems, Links zu den erforderlichen Dokumenten (falls erforderlich), Aufgaben zur Aufgabenverfolgung und anderen Kontext enthalten. Sogar in der kleinen MR sollte so etwas sein.
Eine Beschreibung des Typs "Fehler beheben" wird natürlich als unzureichend angesehen.
MR sollte so klein wie möglich sein
- Little MR kann schnell überprüft werden
- Die Überprüfung ist aussagekräftiger
- Es ist weniger wahrscheinlich, dass ein Fehler übersehen wird.
- Nicht so anstößig, wenn der gesamte MR abgelehnt wird. Es ist sehr schlimm, wenn viel Arbeit erledigt ist, und dann stellt sich heraus, dass dies alles überhaupt nicht notwendig war
- Einfachere Änderungen, weniger Konflikte
- Es ist einfacher, Code von guter Qualität zu erhalten.
- Je mehr Änderungen gleichzeitig vorgenommen werden, desto schwieriger ist es, den Code bei Bedarf zurückzusetzen
Sehr selten gibt es eine Situation, in der es unmöglich ist, die Größe des MR zu verringern und ihn in Stücke zu zerbrechen. Der Prüfer hat das Recht, MR abzulehnen, wenn es zu groß ist
Natürlich kann es keine feste Regel geben, welche MR als groß, welche als klein angesehen wird. Sind 100 Codezeilen groß oder nicht? Wer weiß.
- MR muss eine Sache tun. Normalerweise ist dies nicht die ganze Funktion, sondern ein Teil davon
- Separates Refactoring in einem separaten MR
MR sollte klein, aber autark sein
- Alles, was ein Prüfer benötigt, um MR zu verstehen, sollte in diesem MR enthalten sein
- Nach dem Einfügen des Codes sollte das System normal funktionieren.
- Wenn eine API-Methode hinzugefügt wird, sollten die Methoden zu ihrer Verwendung im selben MR demonstriert werden. Mit anderen Worten, MR sollte nicht so klein sein, dass es schwierig ist zu verstehen, wie es verwendet wird und zu welchen Konsequenzen es führen wird.
- Deckungscode mit Tests, und Tests sollten sich im selben MR befinden
Nimm dir nicht zu Herzen
Manchmal sind Rezensenten nicht sehr höflich, sie können etwas Schlechtes über Ihren Code schreiben. Dies ist ihrerseits nicht sehr professionell, aber in solchen Kommentaren steckt oft noch ein Körnchen Wahrheit, und dies muss berücksichtigt werden. Antworte nicht zu hart. Dies wird die Situation nur verschlimmern.
Wenn Ihnen der Ton des Gesprächs in den Kommentaren nicht gefällt, ist es besser, diese Person zu finden und mit ihr persönlich zu sprechen, um zu erklären, was nicht zu Ihnen passt.
Wenn dies nicht hilft, empfiehlt Google, sich an den Manager zu wenden.
Aus meiner Erfahrung möchte ich hinzufügen, dass eine Person, die einen unhöflichen Kommentar schreibt, oft keinen Bericht gibt, der irgendwie aggressiv aussehen kann. Der Text verbirgt die Hälfte der Emotionen; Zum Beispiel kann das, was in einem scherzhaft freundlichen Ton in Textform gesagt wird, wie ein harter Überlauf erscheinen. Daher stimme ich Google voll und ganz zu - im Falle eines Missverständnisses nur persönlich kommunizieren!
Erklären Sie den Code
Wenn Sie aufgefordert werden, einen Punkt im Code zu erläutern, prüfen Sie, ob Sie den Code so korrigieren können, dass er ohne Erklärung verständlich ist. Denn wenn man nicht versteht, verstehen andere vielleicht nicht.
Antwort auf Überprüfungskommentare
Wenn die Arbeit erledigt und an den Überprüfungscode gesendet wird, ist es oft psychologisch schwierig zu akzeptieren, dass auch etwas repariert werden muss. Versuchen Sie daher, die Kommentare des Rezensenten nicht feindselig wahrzunehmen, denken Sie, vielleicht hat er Recht, und der Code wird dadurch besser.
Wenn sich der Rezensent jedoch immer noch irrt, können Sie gerne darüber schreiben und die Antwort mit Argumenten und Fakten versehen.
Schlussfolgerungen
Wie ich aus einem Dokument von Google verstanden habe, muss der Autor von MR im Allgemeinen alles tun, um den Prüfer zu erleichtern. Damit der Prüfer verstehen kann, warum der Code erstellt wurde, wie der Code erstellt wurde, muss der gesamte zum Verständnis erforderliche Kontext vorhanden sein usw.
Es ist unvermeidlich, dass Meinungsverschiedenheiten gelöst werden, indem in höflicher, professioneller Form ein Konsens erzielt wird.
In der nächsten Ausgabe von Zinc Selling werden wir diesen Artikel (und vieles mehr) auf jeden Fall diskutieren. Abonnieren Sie also unbedingt unseren Podcast , andernfalls überspringen Sie den lustigen Teil!