5 Tipps, die Ihnen helfen, ein besserer Code-Prüfer zu werden

5 Tipps, die Ihnen helfen, heute ein besserer Code-Prüfer zu werden

Als Junior-Softwareentwickler habe ich immer die Kommentare zur Codeüberprüfung durchgesehen, um zu erfahren, wie man ein besserer Codierer wird. Aber als es Zeit für mich wurde, meine erste Codeüberprüfung zu versuchen, wurde mir klar, dass meine Erfahrung mich nicht darauf vorbereitet hatte, auf der anderen Seite zu sein.

Ich entwickelte einen schweren Fall von Imposter-Syndrom, der sich mit Fragen nach unten drehte: Soll ich diese Codezeile kommentieren oder ist es das nicht wert? Sollte ich Artikel finden, die jeden Kommentar unterstützen? Werde ich die Website zum Absturz bringen, indem ich dies genehmige? Werden sie mich hassen? Okay, ich gebe zu, dass ich ziemlich schnell spiralförmig bin. Aber nachdem ich mit einigen Kollegen gesprochen hatte, wusste ich, dass ich mit meinen Sorgen nicht allein war.

Junior-Software-Ingenieure werden möglicherweise in die Code-Überprüfung mit einer Annahme hineingezogen, die analog zu „Sie wissen, wie man ein Buch liest, damit Sie wissen, wie man ein Buch schreibt, was nicht stimmt“, sagt Jessica Rudder, eine erfahrene Ingenieurin bei GitHub.

Es gibt Erwartungen, die mit der Codeüberprüfung einhergehen, und der Prozess kann nervenaufreibend sein. Deshalb habe ich sieben andere Software-Ingenieure interviewt, um Tipps zum Aufbau einer Überprüfungs-Denkweise zu sammeln.

1. Denken Sie über die Gesamtwirkung nach

Im Allgemeinen sollte eine gute Pull-Anforderung (PR) nur einen begrenzten Teil der Codebasis betreffen. Der begrenzte Umfang sollte Sie jedoch nicht daran hindern, über die Codeänderung im Kontext der größeren Codebasis nachzudenken.

Nigel Munoz, ehemaliger Full-Stack-Ingenieur bei The Muse und derzeit freiberuflicher Software-Ingenieur, ermutigt den Rezensenten, darüber nachzudenken, „wie sich diese Änderung auf das größere und kleinere Bild auswirkt“. Um das Gesamtbild zu betrachten, müssen Sie technische Schulden finden – nach Code suchen, der wiederholt wird, nicht modular ist oder nicht den neuesten Standardkonventionen entspricht – sowie Änderungen an der Architektur der Codebasis analysieren.

Sam Donow, ein Kernentwickler bei Hudson River Trading, glaubt, dass „nichts zu groß oder zu klein ist, um Kommentare abzugeben. Vorschläge für kleine Verbesserungen könnten zu größeren Verbesserungen in mehreren Teilen der Codebasis führen. “

Sie können einen PR-Kommentar zu GitHub verwenden, um positives Feedback zu geben und darauf hinzuweisen, wo der Code von den Standardkonventionen des Frameworks React abweichen kann.

Während einer meiner eigenen Codeüberprüfungen erhielt ich beispielsweise den Kommentar, dass bestimmte Eigenschaften einer React-Komponente verwirrend waren, was zu umfassenderen Fragen zur Verwendung der Komponente führte. Letztendlich habe ich die Eigenschaften aus der ursprünglichen Komponente entfernt und eine separate Komponente erstellt, um das Verhalten der einzelnen Komponenten zu verdeutlichen und sicherzustellen, dass beide an mehreren Stellen verwendet werden können.

2. Betrachten Sie die Sicherheit

Vergessen Sie nicht, dass einige Änderungen mehr als nur die Codebasis betreffen können. Rudder empfiehlt zu prüfen, ob ein Benutzer „diese Funktionalität verwenden könnte, um jemanden zu belästigen oder das System zu missbrauchen“. Wenn die neue Funktion in der Pull-Anforderung beispielsweise die Benutzereingabe umfasst, suchen Sie nach SQL-Injection, Datenzugriff, Cross-Site-Scripting und anderen Sicherheitslücken.

3. Konzentrieren Sie sich auf Fehler

Ihre Code-Mitwirkenden – egal wie roboterhaft sie auch erscheinen mögen – sind Menschen, und Menschen können Funktionen brechen oder vergessen. Stellen Sie also sicher, dass Sie „die Tests mit der gleichen Wichtigkeit wie der Rest des Codes überprüfen“, rät Abhishek Pillai, ein technischer Leiter bei Teachers Pay Teachers. „Sie werden neue Fehler verhindern und als Dokumentationsform für alle anderen dienen, die in Zukunft daran arbeiten.“

Das Lesen der Tests kann Ihnen helfen, die Funktionalität einer neuen Funktion zu verstehen und die verschiedenen Fälle zu sehen, die eingeführt werden. Durch die Analyse der Tests können Sie auf fehlende Fälle hinweisen und Funktionen finden, die nicht in dieser PR enthalten sind. Wenn die Codeänderung keine Tests enthält und sie relevant erscheinen, ist es angebracht, sie im Rahmen der Überprüfung anzufordern.

Aber Tests sind nicht alles. „Vertrauen Sie nicht zu sehr auf das System“, warnt Donow. „Nur weil Tests durchgeführt wurden, heißt das nicht, dass es keine Fehler gibt.“

Möglicherweise möchten Sie die App auch lokal ausführen, um sie auf Funktion zu testen und sicherzustellen, dass sie funktioniert. Wenn es nicht funktioniert, macht es keinen Sinn, es weiter zu überprüfen “, sagt Ryan Verner, Softwareentwickler bei 8th Light. Obwohl einige Prüfer nicht der Meinung sind, dass manuelle Tests Teil des Codeüberprüfungsprozesses sein sollten – teilweise aufgrund der dafür erforderlichen Zeit , ist Verner der Ansicht, dass dies eine schnelle Möglichkeit ist, um festzustellen, ob Sie mehr Zeit für die Überprüfung investieren sollten, sowie eine Strategie, um die Kürzung zu unterstützen das Wachstum eines Bugs-Rückstands.

4. Sei ein Teamplayer

Das Klischee erhält eine neue Bedeutung, wenn es darum geht, Code zu überprüfen. „Nehmen Sie sich Zeit für eine Überprüfung, denn es ist die Codebasis aller“, sagt Verner, der sich für ein Gefühl von „kollektivem Eigentum“ einsetzt. Sie als Prüfer sollten darauf hinarbeiten, den Rückstand von Fehlern vor einer Vergrößerung zu schützen, um Ihrem Team später weniger Arbeit zu ermöglichen.

Pillai verwendet Gifs, um die genehmigten und zusammenführbaren PRs seiner Teamkollegen zu feiern.

Gleichzeitig ermutigt Charles Luxton, ein technischer Leiter bei The Muse, den Rezensenten, die Prioritäten des Teams zu verstehen und sich daran zu erinnern. Angesichts der sich schnell nähernden Fristen und Meinungsverschiedenheiten ist es manchmal das Pflaster, das Sie benötigen, um in Zukunft einen Aufgabenpunkt für den Rückstand zu erstellen, der sicherstellt, dass in Zukunft Verbesserungen vorgenommen werden, und in der Zwischenzeit einen Kommentar zu dem betreffenden Code abzugeben Halte dein Team bei Laune.

Wenn Sie sich schließlich fragen, ob der Code für jemanden Sinn macht, der gerade dem Team beigetreten ist und ihn in den ersten Wochen gelesen hat, bleibt Ihr Code lesbar und verständlich.

5. Verwenden Sie den Prozess zum Lernen und Wissensaustausch

Der Überprüfungsprozess bietet allen Beteiligten einen Ort, an dem sie mehr Einblick in die Codebasis, Sprachen, Frameworks und Best Practices erhalten.

Matt Jeffery, ein technischer Leiter bei The Muse, rät dem Prüfer, „die Änderungen architektonisch zu verstehen. Eine Möglichkeit besteht darin, Dateinamen zu lesen, da sie dazu beitragen, den Kontext zu bestimmen. Wenn Sie beispielsweise eine Änderung in der Datenzugriffsschicht betrachten Sie wissen, dass Sie sich nicht mit Geschäftslogik oder Benutzeroberfläche befassen. „

Sie können einen PR-Kommentar zu GitHub verwenden, um die Dokumentation freizugeben.

Wenn Sie aus Codeänderungen lernen, haben Sie auch die Möglichkeit, Wissen auszutauschen. „Es ist am besten, Ihre Meinung zu erklären und sie mit Dokumentation zu untermauern“, sagt Luxton. Die Links, die Sie zu unterstützenden Beweisen und vertrauenswürdigen Artikeln bereitstellen, helfen dem Prüfer und Code-Schreiber nicht nur, verschiedene Ansätze zu erkunden, wenn sie eine endgültige Entscheidung treffen, sondern erweitern auch ihre Programmierkenntnisse.

Denken Sie auch daran, dass das Überprüfen eine Zeit ist, um die Fähigkeiten Ihrer Mitarbeiter zu trainieren. „Geben Sie den Menschen den Vorteil des Zweifels, dass sie über ihren Ansatz nachgedacht haben, und weisen Sie auf verschiedene Möglichkeiten hin, während Sie versuchen, die Abwehrkräfte zu zerstreuen“, sagt Rudder. „Ich hinterlasse durchgehend Kommentare und einen abschließenden Kommentar – hier ist, was großartig ist, hier ist, was verbessert werden kann, hier ist, was vor dem Zusammenführen geändert werden muss.“

Mit diesem Ansatz schützen Sie nicht nur Ihre Codebasis vor technischen Schulden, Sicherheitsbedrohungen und Fehlern, sondern bauen auch Ihr Team auf.