Hier gehen wir wieder: Sie sehen die Benachrichtigung, und Sie spüren diesen bekannten Widerstand. Code Review fühlt sich oft kognitiv schwer und nicht-deterministisch an: zu viele Wege zu folgen, zu viel Zweideutigkeit, zu viele Meinungen. Aber wie maximieren Sie den Wert einer Rezension, ohne die Rezensenten zu erschöpfen oder das Team in endlose Debatten zu fangen? Ich habe einen gesunden, nachhaltigen Überprüfungsprozess in ein Akronym destilliert: Es priorisiert, was wirklich wichtig ist - von Business-Logik und Edge-Fällen bis hin zu Zuverlässigkeit und Lesbarkeit - während subjektive Meinungen unter Kontrolle gehalten werden. PERFECT Was ist Code Review? Es kann von einem anderen Entwickler, vom Autor selbst oder mit Hilfe automatisierter Werkzeuge durchgeführt werden. Diese Anforderungen werden durch geschäftliche oder technische Bedürfnisse definiert.In der Produkt- oder maßgeschneiderten Softwareentwicklung werden sie letztendlich immer von Geschäftszwecken angetrieben.Solche Anforderungen können Codequalität, Verhinderung kritischer Probleme, schnellere Entwicklungszyklen, Teamwachstum und andere Faktoren umfassen. Zum Beispiel ist der persönliche Wunsch eines Entwicklers, perfekt sauberen Code zu schreiben, nicht an sich ein gültiger Grund für die Code-Revision.Wenn jedoch gezeigt wird, dass sauberer Code Produktionsfehler reduziert, die Gesamtqualität der Software verbessert oder die Teammotivation und Wartungsfähigkeit positiv beeinflusst, wird er zu einem legitimen Zweck der Code-Revision. Brauchen Sie wirklich eine Code-Review? Code-Review kann bis zu 20-30% der Arbeitszeit eines Entwicklers dauern, einschließlich Code-Review und Warten auf Bewertungen. Idealerweise sollten Sie den Kompromiss zwischen der Zeit und dem Aufwand analysieren, der für die Code-Review aufgewendet wurde, und dem geschäftlichen Wert, den sie bietet, vorzugsweise mithilfe von Metriken und entscheiden, ob die daraus resultierenden Verbesserungen diese Kosten rechtfertigen. Jedes Projekt muss seine eigene akzeptable Balance finden. Die kurze Antwort ist fast immer Selbst eine leichte, aber strukturierte Überprüfung kostet in der Regel wenig und liefert einen erheblichen Wert, was es vernünftig macht, in den meisten Projekten zu verwenden. Wenn sich jedoch eine Code-Überprüfung in einen "Cargo-Cult" verwandelt, wenn Bewertungen nur formell existieren, Genehmigungen ohne echte Diskussion stattfinden und keine tatsächlichen Probleme verhindert werden, dann benötigen Sie einfach keine Peer-to-Peer-Überprüfung in dieser Form. yes Wenn ein Code-Review-Prozess Kommunikationsprobleme aufzeigt oder die Lieferung erheblich verlangsamt, können Teams versucht sein, es vollständig aufzugeben.Während dies kurzfristige Erleichterung bringen kann, ist das langfristige Ergebnis in der Regel negativ.Ein effektiverer Ansatz besteht darin, die zugrunde liegenden Probleme wie Kommunikationslücken oder einen unstrukturierten Überprüfungsprozess zu beheben, anstatt Code-Review vollständig zu entfernen. Prinzipien der perfekten Code-Review Im Folgenden beschreibe ich eine Reihe von Code-Review-Prinzipien, die nach ihrer Bedeutung angeordnet sind. Diese Prinzipien beschreiben einen idealen Code-Review-Prozess, der alle wesentlichen Aspekte abdeckt. Um sie leichter zu erinnern, benutze ich das Akronym , wo jeder Buchstabe dem ersten Buchstaben eines Prinzips entspricht. PERFECT   Important: Wenn Sie etwas zu kommentieren haben, beschreiben Sie klar, was falsch ist und warum, unterstützen Sie Ihr Feedback mit konkreten Argumenten und schlagen Sie eine Alternative vor - zumindest auf einem hohen Niveau. Wichtig ist: 1. Zweck ✔️ Code solves the task. Dies ist die primäre und nicht verhandelbare Anforderung. Wenn der Code keine Aufgabe löst, hat er keinen Wert und sollte wahrscheinlich überhaupt nicht zusammengeführt werden. Für einen Reviewer besteht der erste Schritt darin, zu verstehen, was die Aufgabe ist und welches Ergebnis der Code erwartet wird. Diese Informationen können aus einem Work-Tracking-Ticket, der Bewertungsbeschreibung oder sogar einer direkten Diskussion mit Kollegen stammen. Sobald die Aufgabe klar ist, sollte der Reviewer überprüfen, ob der Code sie tatsächlich löst.Eine nützliche Technik besteht darin, ungefähr zu beschreiben, wie Sie die Lösung angehen und sie mit dem implementierten Code vergleichen. Unabhängig davon, wie sauber oder lesbar der Code ist, hat er wenig Sinn, wenn er die beabsichtigte Aufgabe nicht löst. 2. Edge Fälle ✔️ Edge cases are handled. Versuchen Sie, sowohl geschäftliche als auch technische Eckfälle zu identifizieren und zu überprüfen, ob der Code sie richtig bearbeitet.Dies umfasst unerwartete Eingänge, ungewöhnliche Berechnungsergebnisse, ausgelöste Anforderungen oder Bedingungen, Grenzwerte, Typgrenzen, Nichtigkeitsfähigkeit und viele andere. Ein erheblicher Teil der Produktionsfehler wird durch vernachlässigte Randfälle verursacht.Wenn mindestens eine andere Person sogar einige von ihnen identifiziert, kann die Wahrscheinlichkeit von Produktionsproblemen dramatisch reduziert werden. Dies sind Situationen, die inhärent gefährlich sind, aber im aktuellen Zustand des Codes unerreichbar erscheinen. Zum Beispiel, Zugriff auf einen Wert von einer Option oder vielleicht Typ, ohne explizit seine Anwesenheit zu überprüfen. Dies kann im aktuellen Zustand des Codes sicher sein, aber es ist oft schwierig vorherzusagen, wie zukünftige Änderungen, vor allem diejenigen, die ohne vollständiges Bewusstsein der bestehenden Annahmen gemacht werden, diese Logik beeinflussen werden. In der Praxis neigen solche Fälle dazu, sich zu akkumulieren. Während eine einzelne Instanz Probleme nicht verursachen kann, erhöht eine größere Anzahl von ihnen das Gesamtrisiko erheblich. Eine gute Praxis ist, Sprachfunktionen wie beabsichtigt zu verwenden, explizite Kontrollen durchzusetzen 3. Zuverlässigkeit ✔️ Code does not have performance and security issues. Auch wenn ein Projekt nicht direkt mit Geld oder menschlicher Sicherheit verbunden ist, ist es oft schwierig vorherzusagen, wie es wiederverwendet, in andere Systeme integriert oder im Laufe der Zeit entwickelt werden kann. Aus diesem Grund ist es eine gute Praxis, immer zu überprüfen, ob der Code mindestens grundlegende Leistungs- und Sicherheitserwartungen erfüllt. Zum Beispiel, dass er keine offensichtlichen Leistungsschranken einführt und dass öffentliche Schnittstellen ordnungsgemäß gesichert sind. Selbst einfache Kontrollen helfen, eine große Klasse von Problemen zu verhindern, die sonst viel mehr kosten würden, um später zu beheben, wenn echte Probleme in der Produktion auftreten. Aus Sicht der Zuverlässigkeit konzentriert sich die Codeüberprüfung in der Regel auf Bereiche, in denen Ausfälle, unsicheres Verhalten oder verminderte Leistung am wahrscheinlichsten auftreten. Dies umfasst die Zeit- und Speicherkomplexität (angemessen für das erwartete Datenvolumen, Ausführungszeit und Speichernutzung), Eingabe- und Ausgabevalidierung, Credential-Speicher, gebrochene Integrationen, Cache-Invalidierung und ähnliche Bedenken. 4. Die Form ✔️ Code aligns with design principles. Diese Ausrichtung hilft, die Darstellung des Codes zu standardisieren, wodurch es leichter zu lesen und zu verstehen ist - sowohl für andere Entwickler als auch für den ursprünglichen Autor in der Zukunft. Im Gegensatz zu Geschäftskorrektheit, Leistung oder Sicherheit neigen Designfragen dazu, subjektiver zu sein. aus diesem Grund sind klare Argumente und gemeinsame Vereinbarungen unerlässlich, um nicht-konstruktive Diskussionen und Konflikte während der Überprüfung zu minimieren. Es gibt viele bekannte Prinzipien, die angewendet werden können, wie SOLID, KISS, DRY und andere. Einige von ihnen bleiben weitgehend subjektiv, während andere konkretere Kriterien und Leitlinien liefern. Jedoch, unabhängig vom spezifischen Prinzip, kommen die meisten Designdiskussionen letztendlich auf das Management von Kohäsion und Coupling zurück. Aus diesem Grund empfehle ich, ein solides Verständnis dieser Konzepte zu entwickeln und die Prinzip im Kontext Ihres Projekts, andere Designprinzipien als Beispiele oder spezifische Interpretationen dieser Kernidee zu behandeln. High Cohesion / Low Coupling 5. Beweise ✔️ Tests and CI pipelines pass. Tests erleichtern das Debuggen, Refactoring und die Einführung neuer Änderungen, reduzieren gleichzeitig die Anzahl der Produktionsfehler und verbessern die Gesamtstabilität. Andernfalls kann die gesamte Code-Revision ihren Wert verlieren, da die Reparatur von gebrochenen Pipelines erhebliche Änderungen einführen kann, die eine erneute Überprüfung des Codes erfordern.Darüber hinaus bedeutet dies, wenn Tests oder Pipelines dauerhaft gebrochen oder ignoriert werden, dass sie nicht mehr aktiv verwendet werden, veraltetes Verhalten enthalten und mehr Verwirrung als Nutzen verursachen können. Wenn es Vereinbarungen über schriftliche Tests gibt, sollten Änderungen entsprechend von Tests abgedeckt werden. Diese Tests müssen auch nach den gleichen Grundsätzen wie der Produktionskodex überprüft werden. Mindestens sollten sie die beabsichtigte Logik validieren, der vereinbarten Struktur und Konventionen folgen und eine akzeptable Leistung haben. Idealerweise sollte der Produktionskodex keine spezielle Logik enthalten, die nur für Tests geschrieben ist. 6. Klarheit ✔️ Code clearly communicates its intent. Verschiedene Menschen haben unterschiedliche Wege des Lesens und Verständnisses von Code, unterschiedliche Hintergründe und unterschiedliche Erfahrungsstufen. Als Ergebnis ist die Klarheit von Code oft subjektiv und es ist schwierig, Code zu schreiben, der für alle gleichermaßen leicht zu verstehen ist. Dennoch sollten wir uns bemühen, die Absicht des Codes so klar wie möglich zu machen. Idealerweise sollte der Code verständlich sein, ohne jede einzelne Zeile zu lesen - es sollte möglich sein, ihn diagonal zu lesen. Dies vereinfacht und reduziert die Kosten für Überprüfung, Wartung, Debugging und die Einführung neuer Änderungen erheblich. Sie können Konventionen für die Benennung, Dateistruktur (ein gutes Kriterium ist die Fähigkeit, Dinge ohne Suche zu finden), Blocklänge, Nesting, Aussagenordnung, Dokumentation, Verwendung von Kommentaren und andere. Wenn es keine vereinbarten objektiven Kriterien gibt und der Code nicht explizit unklar ist, überlasse ich diese Entscheidungen lieber dem Autor, auch wenn ich persönlich mit einigen Entscheidungen nicht einverstanden bin. 7. Geschmack ✔️ Personal preferences are noted but do not block changes. Jeder Reviewer bringt seine eigenen Entwicklungsgewohnheiten und persönlichen Präferenzen mit. Je weniger schriftliche Überprüfungsvereinbarungen ein Team hat, desto mehr Meinungsempfindungen kommen dazu. Gleichzeitig haben viele dieser Kommentare immer noch Sinn und können auf reale Probleme hinweisen. Sie sollten nicht vollständig ignoriert werden. Es ist jedoch wichtig, klare Erwartungen zu setzen: Wenn der Kommentar eines Reviewer nicht durch klare Argumentation und einen konstruktiven Vorschlag unterstützt wird, kann der Autor wählen, es nicht anzugehen. Wertvolle Meinungen können später überprüft und in gemeinsame Vereinbarungen umgewandelt werden. Sobald etwas zu einer Einigung wird, muss es nicht vollständig objektiv sein - es wird einfach zu einem Teil der Art und Weise, wie das Team arbeitet. Wie man es tatsächlich funktioniert Die richtigen Code-Review-Prinzipien zu kennen und konsequent darauf zu handeln, sind zwei sehr unterschiedliche Dinge.Während es kein universelles Rezept gibt, das für jedes Team funktioniert, kann ich Ihnen einige grundlegende, aber effektive Empfehlungen geben. Das Hauptziel ist es, Code-Review nicht zu einer kognitiv anspruchsvollen Aktivität zu machen, die übermäßige Ressourcen von Entwicklern entleert, sondern zu einem klaren und routinemäßigen Prozess.Idealerweise sollten Reviewer eine Reihe vordefinierter Konventionen befolgen, anstatt zu überdenken oder zu verzögern, mehr Aufmerksamkeit auf tatsächliche Probleme zu schenken und eine noch höhere Gesamtqualität der Überprüfung zu erreichen. 
 
 
 
 
 
 
 
 
 
 
 Establish written review conventions. These should include the principles described above, their concrete implementation in the context of your project, and any other aspects you want reviewers to pay attention to. 
 
 
 Keep conventions up to date and actionable. All criteria should be usable during review at any moment. Whenever you notice a recurring review pattern (comment → discussion → fix), turn it into a convention. 
 
 
 Require self-review before peer review. Everyone should perform self-review using the same conventions before sending code for review by others. This saves time for all participants and helps reviewers build experience and efficiency over time. 
 
 
 Integrate code review into the development process. Define clear rules for selecting reviewers, the number of reviewers, how comments are written and resolved, how updates are communicated, approval rules, review status visibility, and review SLAs. There should be a clear answer to common questions around code review, instead of uncertainty, anxiety, and unnecessary stress. 
 
 Automate everything that can be automated. 
 
 
 Stop approving with "LGTM". "LGTM" (Looks Good To Me) often signals that the reviewer did not fully understand the changes and simply wants to move on. While reviewers are not responsible for the final outcome of approved code, such approvals reduce the value of the review itself. 
 
 
 Practice code review whenever possible. Code review is a skill that improves through deliberate practice. The more experience reviewers gain, the less effort reviews require and the more effective they become. This can be supported through attention to structure, constructive feedback, short workshops, and other focused practices. Brauchen Sie wirklich alle Prinzipien? Auch wenn Sie nicht beabsichtigen, alle diese Prinzipien in der Praxis zu verwenden, ist ihr Verständnis immer noch nützlich. Sie helfen, eine technische Vision zu gestalten, informierte Diskussionen zu unterstützen und den Code-Review-Prozess zu strukturieren, indem Sie klären, wann verschiedene Ansätze Sinn machen. Wie bereits erwähnt, ist Code-Review keine einzelne Technik, sondern ein Spektrum von Praktiken. Die oben beschriebenen Prinzipien helfen dabei, die Vorteile der Code-Review im Allgemeinen zu maximieren. Jedoch können bei einem bestimmten Projekt einige Ansätze mehr Anstrengung erfordern als der Wert, den sie liefern.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Ein nachhaltiger Code-Review-Prozess für beschäftigte Teams (PERFECT)

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps