Wenn es um Code-Inspektion geht, konzentrieren sich die Leute eher darauf, wer es tut. Der Entwickler, der den Code geschrieben hat, spielt dabei eine ebenso wichtige Rolle wie der Prüfer. Es gibt fast keine Empfehlungen für die Vorbereitung des Codes für die Inspektion, daher machen Autoren Fehler oft nur aus Unwissenheit.
In diesem Artikel werden die Best Practices für die Teilnahme an der Codeprüfung als Autor zusammengestellt. Wenn Sie mit dem Lesen fertig sind, senden Sie den Inspektoren so perfekte Änderungen, dass sie mit Liebe zu Ihnen brennen, nicht weniger.
Aber ich möchte nicht, dass Code-Inspektoren vor Liebe zu mir strahlen
Und sie werden es immer noch sein. Sich demütigen. Noch hat sich niemand in der Geschichte der Menschheit auf seinem Sterbebett darüber beschwert, dass er zu Lebzeiten zu geliebt wurde.
Warum die Codeprüfung verbessern?
Das Erlernen effektiver Inspektionstechniken erleichtert dem Inspektor, dem Team und vor allem Ihnen das Leben.
- Beschleunigter Wissenstransferprozess. Wenn Sie Ihre Änderungen richtig vorbereiten, wird der Inspektor auf die Bereiche aufmerksam gemacht, in denen Sie wachsen müssen, anstatt auf langweilige Stilfehler. Und wenn Sie klarstellen, dass Sie konstruktive Kritik schätzen, bemüht sich der Rezensent verstärkt um das Feedback.
- Ein Beispiel für andere. Gute Code-Inspektionspraktiken bei Ihrer Ausführung setzen die Messlatte für Ihre Umgebung. In der Regel werden gute Techniken angewendet, was bedeutet, dass es für Sie einfacher ist, wenn Ihnen jemand von Ihren Kollegen den Code zur Überprüfung sendet.
- Minimale Konflikte. Die Code-Inspektion führt häufig zu Spannungen im Team. Wenn Sie verantwortungsbewusst und absichtlich vorgehen, kommt es seltener zu Streitigkeiten.
Goldene Regel: Schätzen Sie die Zeit des Rezensenten
Dies scheint offensichtlich, aber ich stoße oft auf Autoren, die Inspektoren als ihre persönlichen Qualitätskontrollspezialisten behandeln. Solche Leute werden keinen Finger schlagen, um zumindest einige der Fehler zu erkennen oder eine Reihe von Änderungen vorzunehmen, die für die Überprüfung bequem sind.
Ihre Kollegen kommen jeden Tag mit begrenzter Aufmerksamkeit zur Arbeit. Wenn sie Ihnen etwas davon widmen, können sie diese Ressource nicht mehr für ihre eigenen Aufgaben ausgeben. Das Beste aus ihrer Zeit zu machen, ist eine Frage der einfachen Gerechtigkeit.
Die Codeüberprüfung ist viel erfolgreicher, wenn die Teilnehmer sich gegenseitig vertrauen können. Ihr Inspektor wird keine Mühe scheuen, wenn er weiß, dass Sie seine Bemerkungen ernst nehmen werden. Wenn Sie den Prüfer als ein Hindernis betrachten, das überwunden werden muss, erhalten Sie von ihm viel weniger wertvolle Empfehlungen.
Technik
1. Überprüfen Sie den Code
zuerst selbst. Bevor Sie ihn an einen Kollegen senden, lesen Sie ihn. Beschränken Sie sich nicht darauf, Fehler zu fangen - stellen Sie sich vor, Sie sehen dieses Fragment zum ersten Mal. Was kann daran verwirrend sein?
Nach meiner Erfahrung kann es hilfreich sein, eine Pause zwischen dem Schreiben und Bearbeiten von Code einzulegen. Menschen senden oft am Ende des Tages einen neuen Teil des Codes, aber in dieser Zeit ist es am wahrscheinlichsten, dass sie etwas durch Nachlässigkeit übersehen. Warten Sie bis zum Morgen, werfen Sie einen neuen Blick auf die Änderungen und geben Sie sie dann an einen Kollegen weiter.
Welcher Idiot hat das geschrieben?
Synchronisieren von Cron-Jobs mit dem Mondzyklus: Ich habe synchronisierte Logik hinzugefügt, um unsere ETL-
Pipeline im Einklang mit der Natur zu halten. Simulieren Sie die Arbeitsumgebung eines Validators so weit wie möglich. Verwenden Sie das gleiche Vergleichsprogramm wie er. Dumme Fehler sind in diesen Dienstprogrammen besser zu finden als in Ihrem normalen Code-Editor.
Erwarten Sie nicht, dass Sie perfekt sind. Sie werden den Code unweigerlich mit einem Teil senden, das Sie nach dem Beheben eines Fehlers vergessen haben, oder einer Streudatei, die Sie entfernen wollten. Es ist nicht das Ende der Welt, aber es lohnt sich immer noch, den Überblick zu behalten. Beachten Sie Muster in Ihren Fehlern und finden Sie heraus, welche Systeme Sie implementieren können, um sie zu verhindern. Wenn dieselben Fehler sehr häufig auftreten, kommt der Inspektor zu dem Schluss, dass Sie seine Zeit nicht schätzen.
2. Schreiben Sie eine klare Beschreibung des Änderungssatzes
In meinem letzten Mentoring-Job hatte ich gelegentlich Treffen mit einem erfahreneren Programmierer. Vor dem ersten Treffen bat er mich, ein Software-Design-Dokument zu holen, das ich zusammengestellt hatte. Als ich ihm die Papiere reichte, erklärte ich, was das Projekt war und wie es sich auf die Ziele meines Teams bezieht. Mein Mentor runzelte die Stirn und sagte unverblümt: "Alles, was Sie gerade gesagt haben, sollte auf der ersten Seite des Dokuments stehen."
Und er hatte recht. Ich habe das Dokument mit der Erwartung von Entwicklern aus meinem Team geschrieben, aber nicht berücksichtigt, dass es von Außenstehenden gelesen werden könnte. Das Publikum war nicht auf die Grenzen meiner Abteilung beschränkt - es gab immer noch Partnerteams, Mentoren und Leute, die Entscheidungen über Beförderungen trafen ... Das Dokument sollte so geschrieben sein, dass ihnen alles klar war. Nach diesem Gespräch versuche ich immer, meine Arbeit in dem für das Verständnis notwendigen Kontext zu präsentieren.
Die Beschreibung des Änderungssatzes sollte alle Hintergrundinformationen enthalten, die der Leser möglicherweise benötigt. Selbst wenn Sie eine Beschreibung für den Prüfer schreiben, denken Sie daran, dass dieser möglicherweise weniger Kontextinformationen enthält, als Sie denken. Darüber hinaus ist es möglich, dass in Zukunft auch andere Kollegen mit diesem Code arbeiten müssen. Wenn Sie sich die Änderungshistorie ansehen, sollten sie Ihre Absichten verstehen.
Eine gute Beschreibung beschreibt, wofür das Änderungsset gedacht ist und warum Sie es so gewählt haben.
Wenn Sie tiefer in die Kunst des Schreibens großartiger Beschreibungen eintauchen möchten, lesen Sie „ Wie schreibe ich eine Git-Commit-Nachricht? “ Von Chris Beams und „ Mein Lieblings-Git-Commit “ von David Thompson.
3. Einfache Dinge automatisieren
Wenn Sie sich bei kleinen Dingen wie einer schwebenden Klammer oder Problemen mit automatisierten Tests auf den Inspektor verlassen, verschwenden Sie seine Zeit.
Überprüfen Sie, ob mit der Syntax alles in Ordnung ist? Ich würde mich an den Compiler wenden, aber es ist schade, seine Zeit zu verschwenden.
Automatisierte Tests sollten als Teil des Teams als Teil des Standardverfahrens betrachtet werden. Eine Inspektion beginnt erst, wenn die gesamte Reihe automatisierter Prüfungen in einer kontinuierlichen Integrationsumgebung bestanden wurde .
Wenn Ihr Team auf tragische Weise täuscht und eine kontinuierliche Integration ablehnt, richten Sie intern ein automatisiertes Audit ein. Implementieren Sie Hooks , Linters und Formatierer vor dem Festschreiben in Ihrer Entwicklungsumgebung, um sicherzustellen, dass alle Konventionen eingehalten werden und das beabsichtigte Verhalten von Festschreiben zu Festschreiben bestehen bleibt.
4. Stellen Sie sicher, dass der Code selbst die Fragen beantwortet
Was ist falsch mit diesem Bild?
Ich verstehe den Zweck der Funktion nicht.
Dies ist der Fall, wenn der Frombobulator beim Aufrufen übergeben wird, wenn keine frombobulate-Implementierung vorliegt
. In die Geschichte der Veränderungen eintauchen und alle Diskussionen neu lesen? Es ist noch schlimmer, wenn der Autor an meinen Schreibtisch kommt, um alles persönlich zu erklären. Erstens hindert es mich daran, mich zu konzentrieren, und zweitens hat keine lebende Seele mehr Zugang zu den klingenden Informationen.
Wenn der Inspektor Verwirrung über einen Punkt im Code äußert, besteht Ihre Aufgabe nicht darin, die Situation für diese bestimmte Person zu klären. Es ist notwendig, die Situation für alle auf einmal zu klären.
- Hallo?
- Als Sie vor sechs Jahren bill.py geschrieben haben, warum hatten Sie t = 6?
- Schön, dass du angerufen hast! Dies ist auf die 6% Umsatzsteuer zurückzuführen.
- Na sicher!
- Eine gute Möglichkeit, eine Umsetzungsentscheidung zu rechtfertigen.
Die beste Antwort auf jede Frage ist das Code-Refactoring, mit dem sie entfernt wird. Was kann umbenannt werden, um klarer zu machen, wie die Logik geändert werden kann? Kommentare sind eine akzeptable Lösung, verlieren aber definitiv vor dem Hintergrund von Code, der sich natürlich selbst dokumentiert.
5. Geben Sie die Änderungen geringfügig ein
Das Überschreiten von Grenzen ist eine schlechte Praxis und kann häufig bei der Überprüfung von Code festgestellt werden. Der Entwickler verpflichtet sich, einen Fehler in der Logik zu beheben, stößt dabei jedoch auf einen Fehler in der Benutzeroberfläche. "Nun, da ich sowieso mit diesem Stück arbeite", denkt er, "werde ich es gleichzeitig reparieren." Infolgedessen beginnt Verwirrung. Der Prüfer muss nun herausfinden, welche Änderungen für Aufgabe A und welche für Aufgabe B funktionieren.
Die besten Änderungssätze machen eine Sache . Je präziser und einfacher die Änderung ist, desto leichter kann der Inspektor den Kontext im Auge behalten. Durch das Teilen nicht verwandter Änderungen können Sie auch mehrere Peers gleichzeitig überprüfen lassen, was bedeutet, dass der Code schneller zu Ihnen zurückkehrt.
6. Funktionale von nicht funktionalen Änderungen trennen
Eine andere Faustregel lautet, dass funktionale und nicht funktionale Änderungen nicht verwechselt werden dürfen.
Entwickler mit wenig Erfahrung mit Code-Inspektion verstoßen häufig gegen diese Regel. Sie nehmen eine Art Aufschlüsselungsänderung vor, und der Code-Editor ändert sofort das Format in der gesamten Datei. Der Entwickler versteht entweder nicht, was passiert ist, oder entscheidet, dass es noch besser ist, und sendet Code, bei dem eine Funktionsänderung unter Hunderten von Zeilen nicht funktionsfähiger Zeilen vergraben ist.
Finden Sie eine funktionale Änderung?
Eine solche Verwirrung ist wie eine Spucke angesichts eines Inspektors. Nur-Format-Änderungen sind leicht zu überprüfen. Auch funktionale Änderungen. Ein funktionaler Zusammenbruch im Ozean der Formatänderungen kann verschwendet und verrückt sein.
Darüber hinaus mischen Entwickler Refactoring gerne zeitnah in wichtige Änderungen ein. Ich bin mit Code-Refactoring seitens der Kollegen sehr einverstanden, aber nicht, wenn sie gleichzeitig neues Verhalten implementieren.
Verhaltensänderung mitten im Refactoring
Wenn ein Code sowohl Refactoring als auch Verhaltensänderungen benötigt, müssen Sie den Prozess in zwei oder drei Gruppen aufteilen:
- Fügen Sie Tests für das aktuelle Verhalten hinzu (falls keine vorhanden sind)
- Refactor den Code, ohne etwas in den Tests zu ändern
Indem die Tests in der zweiten Phase intakt bleiben, kann der Prüfer sicherstellen, dass das Refactoring das Verhalten nicht verletzt. Dementsprechend muss er in der dritten Phase nicht herausfinden, was hier umgestaltet wird und was das Verhalten ändert - schließlich haben Sie sich im Voraus voneinander getrennt.
7. Auflösen von Änderungssätzen, die zu groß sind
Aufgeblähte Änderungssätze sind wie die hässlichen Cousins weitläufiger Grenzen . Stellen Sie sich eine Situation vor: Ein Entwickler kommt zu dem Schluss, dass er zur Implementierung der Funktionalität A zuerst die Semantik der Bibliotheken B und C korrigieren muss. Wenn es nur wenige Änderungen gibt, egal was passiert, aber sehr oft breiten sich diese Änderungen aus und die Ausgabe ist eine riesige Liste von Änderungen.
Die Komplexität des Änderungsprotokolls wächst exponentiell mit der Anzahl der betroffenen Zeilen. Wenn sich die Änderungen auf 400 oder mehr Zeilen auswirken, suche ich nach einer Möglichkeit, sie zu zerlegen, bevor ich eine Inspektion anfordere.
Vielleicht wird es möglich sein, anstatt alles auf einmal zu tun, zuerst mit Abhängigkeiten zu arbeiten und im nächsten Satz neue Funktionen zu implementieren? Ist es realistisch, den Code gesund zu halten, wenn Sie die Hälfte der Funktionalität jetzt und die andere Hälfte in der nächsten Phase implementieren?
Es kann mühsam sein, darüber nachzudenken, wie der Code aufgeteilt werden kann, um ein funktionierendes, verständliches Teil zu erhalten. Dies ermöglicht jedoch ein besseres Feedback und schafft weniger Komplexität für den Prüfer.
8. Nehmen Sie Kritik freundlich an
Der sicherste Weg, den ganzen Test zu verderben, besteht darin, Kritik mit Feindseligkeit zu nehmen. Es kann schwierig sein, Widerstand zu leisten, da viele Entwickler stolz auf ihre Arbeit sind und ihre Arbeit als Erweiterung ihrer selbst wahrnehmen. Und wenn der Inspektor taktlose Kommentare abgibt oder zur Person geht, erschwert dies die Angelegenheit weiter.
Letztendlich können Sie als Autor frei entscheiden, wie Sie auf Kommentare reagieren. Behandeln Sie die Worte des Inspektors als eine objektive Diskussion des Codes, die nichts mit der Beurteilung Ihrer Persönlichkeit zu tun hat. Wenn Sie defensiv werden, wird es nur noch schlimmer.
Ich versuche, Kommentare als Versuch zu verstehen und zu nutzen. Wenn ein Rezensent einen dummen Fehler im Code findet, bin ich instinktiv angezogen, Ausreden zu machen. Aber ich halte mich zurück und lobe stattdessen seine Beobachtung.
- Im Januar und Februar 1900 wird es nicht funktionieren.
- Genau, gut bemerkt!
Seltsamerweise ist die Tatsache, dass der Inspektor nicht offensichtliche Fehler im Code feststellt, ein gutes Zeichen. Dies deutet darauf hin, dass Sie gut darin sind, Dateien für das Scannen vorzubereiten. Ohne schlampige Formatierung, schlechte Namen und andere auffällige Dinge kann der Prüfer tief in die Logik und das Design eintauchen und wertvollere Beobachtungen machen.
9. Seien Sie geduldig, wenn der Inspektor einen Fehler macht
Von Zeit zu Zeit kommt es vor, dass der Inspektor einfach falsch liegt. Er kann ganz normalen Code falsch lesen und Sie können Fehler pflanzen. Viele Entwickler beginnen in solchen Fällen, sich heftig zu verteidigen. Sie sind beleidigt, dass jemand seine Arbeit kritisiert und sogar nicht auf irgendetwas basiert.
Auch wenn der Rezensent falsch liegt, müssen Sie noch viel darüber nachdenken. Wenn er etwas falsch interpretiert, wie hoch ist die Wahrscheinlichkeit, dass andere Menschen in Zukunft den gleichen Fehler machen? Müssten die Leser den Code nicht hin und her studieren, um sicherzustellen, dass der Fehler, den sie sehen, nicht hier ist?
- Hier liegt ein Pufferüberlauf vor, da nicht überprüft wurde, ob im Namen genügend Speicher vorhanden ist, um alle NewNameLen-Zeichen aufzunehmen.
- Ist es in meinem Code? Undenkbar! Der Konstruktor ruft PurchaseHats auf und CheckWeather, was einen Fehler auslösen würde, wenn die Pufferlänge nicht übereinstimmt. Sie würden zuerst 200.000 Codezeilen lesen und dann wagen, die Möglichkeit zuzugeben, dass ich mich irgendwo geirrt habe.
Überlegen Sie, wie Sie eine Umgestaltung vornehmen, oder fügen Sie Kommentare hinzu, damit Sie auf einen Blick verstehen, dass alles in Ordnung ist. Wenn das Missverständnis auf die Verwendung wenig bekannter Merkmale der Sprache zurückzuführen ist, schreiben Sie den Code mithilfe von Mechanismen neu, für die keine gründlichen Kenntnisse erforderlich sind.
10. Geben Sie eine verständliche Reaktion
Ich befinde mich oft in dieser Situation: Ich sende Kommentare an eine Person, er aktualisiert den Code unter Berücksichtigung einiger von ihnen, aber gleichzeitig schweigt er. Es gibt eine Zeit der Unsicherheit. Entweder hat er den Rest der Kommentare verpasst oder er ist noch dabei, sie zu korrigieren. Wenn Sie hypothetisch überprüfen, was bereits getan wurde, kann sich herausstellen, dass dieser Code noch in Arbeit ist und ich meine Zeit verschwende. Wenn wir warten, können wir in eine Pattsituation geraten - wir werden beide sitzen und auf den nächsten Schritt voneinander warten.
Legen Sie eine bestimmte Reihenfolge der Aktionen im Team fest, damit immer klar ist, wer im Moment den "Staffelstab" hat. Der Prozess sollte nicht verlangsamt werden dürfen, nur weil niemand versteht, was überhaupt passiert. Dies ist einfach zu tun - hinterlassen Sie einfach Kommentare auf der Ebene der Änderungssätze, aus denen hervorgeht, wann das Recht zum Handeln auf einen anderen Teilnehmer übertragen wird.
Korrigieren der Header> Aktualisieren des Codes gemäß den Kommentaren> Alles ist fertig, bitte schauen Sie.
Jeder Kommentar, bei dem Sie Maßnahmen ergreifen müssen, sollte beantwortet werden, indem Sie bestätigen, dass Sie ihn ausgeführt haben. Einige Tools zur Codeüberprüfung bieten die Möglichkeit, verarbeitete Kommentare zu kennzeichnen. Wenn nicht, verwenden Sie eine Reihe einfacher Textaufzählungszeichen wie Fertig. Wenn Sie mit dem Kommentar nicht einverstanden sind, erklären Sie höflich, warum Sie sich entschieden haben, keine Korrekturen vorzunehmen.
Einige Tools, wie Reviewable und Gerritt, schlagen vor, verarbeitete Kommentare mit Tags zu versehen
. Vergleichen Sie Ihre Reaktionen mit den Bemühungen des Reviewers. Wenn er einen Moment detailliert beschrieben hat, damit Sie etwas Neues für sich selbst lernen können, beschränken Sie sich nicht auf die Markierung „Fertig“. Antworte nachdenklich, um zu zeigen, dass du seine Arbeit schätzt.
11. Fehlende Informationen geschickt einholen
Manchmal lassen die Kommentare des Inspektors zu viel Interpretationsspielraum. Wenn sie Ihnen etwas im Sinne von "Ich verstehe diese Funktion nicht" schreiben, stellt sich sofort die Frage, was genau einer Person nicht klar ist. Zu lang? Schlechter Name? Müssen Sie besser dokumentieren?
Lange habe ich mich gefragt, wie ich vage Kommentare klarstellen und nicht versehentlich in eine Konfrontation geraten kann. Das erste, was mir in den Sinn kam, war zu fragen: „Was ist in ihr unverständlich?“, Aber es klingt mürrisch.
Ich habe einmal absichtlich eine vage Antwort an diese Art von Kollegen geschickt, und er hat mich mit seiner Antwort entwaffnet:
"Was kann geändert werden, um es besser zu machen?"
Ich mag diesen Satz, weil er Offenheit für Kritik und mangelnde Feindseligkeit ausdrückt. Wenn ich jetzt vage Rückmeldungen bekomme, antworte ich mit einer Variation des Grundmotivs "Was muss geändert werden, um es besser zu machen?"
Eine andere nützliche Technik besteht darin, zu erraten, was der Prüfer gemeint hat, und die Führung zu übernehmen, indem der Code entsprechend korrigiert wird. Wenn Sie einen "unverständlichen" Kommentar erhalten, schauen Sie sich den Code genauer an. In der Regel wird etwas gefunden, das in Bezug auf Klarheit verbessert werden kann. Durch die Änderungen wird dem Inspektor mitgeteilt, dass Sie bereit sind, Änderungen vorzunehmen, auch wenn er eine andere Vorstellung vom Endergebnis hatte.
12. Geben Sie dem Prüfer Priorität
Wenn im Tennis nicht ganz klar ist, ob der Ball beim Aufschlag außerhalb der Grenzen lag, ist es üblich, die Situation zu seinen Gunsten zu interpretieren. Diese Regel sollte auch bei der Überprüfung Ihres Codes befolgt werden.
Einige Designentscheidungen sind Geschmackssache. Wenn der Prüfer der Meinung ist, dass Ihre Zehn-Zeilen-Funktion besser in zwei Fünf-Zeilen-Funktionen unterteilt werden sollte, liegt die objektive Wahrheit weder bei Ihnen noch bei ihm. Welche Option besser ist, hängt von der Präferenz ab.
Wenn der Inspektor einen Vorschlag macht und die Argumente für seine Position für Sie ungefähr gleich sind, akzeptieren Sie seinen Standpunkt. Schließlich ist er von Ihnen beiden derjenige, der einen neuen Blick auf den Code ausnutzt.
13. Reduzieren Sie die Codeübertragungszeit
Vor einigen Monaten hat ein Benutzer eine kleine Änderung an einem Open Source-Projekt vorgenommen, das ich verwalte. Einige Stunden später habe ich mich mit Kommentaren abgemeldet, aber er ist bereits mit den Enden verschwunden. Ein paar Tage später kehrte ich zurück und stellte fest, dass es immer noch keine Antwort gab.
Sechs Wochen später tauchte der mysteriöse Entwickler mit Überarbeitungen wieder im Projekt auf. Obwohl ich seine Arbeit schätze, führte die lange Pause zwischen den beiden Überprüfungsstufen dazu, dass ich doppelt so viel Aufwand für die Inspektion aufgewendet habe. Ich musste nicht nur den Code, sondern auch meine eigenen Kommentare erneut lesen, um mich daran zu erinnern, was allgemein besprochen wurde. Wenn die Person in ein paar Tagen auftauchen würde, wäre keine zusätzliche Arbeit erforderlich.
Intellektuelle Kosten für die Codeinspektion mit kurzen (links) und langen (rechts) Übertragungszeiten
X-Achse - Zeit; y-Achse - Inspektorspeicher; blaue Schattierung - Kontextwiederherstellung; blaue Füllcodeprüfung; graue Füllung - warten; rote Schattierung - zusätzliche Kosten
Sechs Wochen sind natürlich ein Ausnahmefall, aber ich sehe oft lange, ungerechtfertigte Pausen in meinem Team. Jemand reicht eine Reihe von Änderungen zur Überprüfung ein, erhält Feedback und verschiebt die Änderungen um eine Woche, da sie durch eine andere Aufgabe abgelenkt wurden.
Neben der Tatsache, dass Sie später Zeit damit verbringen müssen, den Kontext wiederherzustellen, verursachen halbfertige Codefragmente Komplexität. Sie erschweren es, den Überblick darüber zu behalten, was bereits abgelassen ist und was noch nicht. Je mehr teilweise verarbeitete Änderungslisten gezüchtet werden, desto höher ist die Wahrscheinlichkeit von Zusammenführungskonflikten, und niemand bastelt gerne daran.
Sobald Sie Ihren Code zur Überprüfung eingereicht haben, ist es Ihre oberste Priorität, ihn durchzuarbeiten. Wenn der Prozess aufgrund Ihrer Schuld ins Stocken gerät, stehlen Sie dem Inspektor die Zeit und verkomplizieren das Leben des gesamten Teams.
Abschließend
Überlegen Sie bei der Vorbereitung Ihres nächsten Änderungsprotokolls für die Einreichung, welche Faktoren Sie berücksichtigen können, und nutzen Sie diese Möglichkeiten, um die Überprüfung produktiv zu gestalten. Suchen Sie bei der Teilnahme an einer Codeüberprüfung nach Dingen, die den Prozess regelmäßig verlangsamen und Ressourcen verschwenden.
Denken Sie an die goldene Regel: Schätzen Sie die Zeit des Rezensenten. Wenn Sie ihm die Möglichkeit geben, sich auf die wirklich interessanten Teile des Codes zu konzentrieren, sind seine Kommentare hilfreich. Wenn Sie ihn zwingen, Zeit mit kleinen Dingen zu verschwenden oder die Verwirrung zu enträtseln, umso schlimmer für Sie beide.
Denken Sie abschließend sorgfältig über Ihre Antworten nach. Missverständnisse über Kleinigkeiten oder gedankenlose Worte können Dinge mit alarmierender Geschwindigkeit entgleisen lassen. Wenn es darum geht, die Arbeit eines anderen zu kritisieren, sind die Leidenschaften groß. Vermeiden Sie daher sorgfältig alles, was den Prüfer dazu veranlassen könnte, zu glauben, dass Sie ihn angreifen oder ihn ohne angemessenen Respekt behandeln.
Herzliche Glückwünsche! Wenn Sie bis hierher gelesen haben, können Sie sich bereits als Code-Inspektionsexperte betrachten. Ihre Inspektoren brennen höchstwahrscheinlich bereits, deshalb behandeln Sie sie menschlich.