Das Code-Review ist ein Aspekt der Softwareentwicklung, der die Qualität und Wartbarkeit des Codebestands stark beeinflusst. Wenn ein Code-Review abgeschlossen ist, trägt dies zur Reduzierung von Fehlern bei, verbessert die Qualität des Codes und fördert die Zusammenarbeit im Team. In diesem kompakten Code-Review-Handbuch werden wir die empfohlenen Ansätze für Code-Reviews aus der Perspektive des Reviewers, der Sicht des Autors und sogar aus der breiteren teamweiten Perspektive diskutieren.
Code-Review aus der Perspektive des Teams
Beginnen wir damit, die Dinge aus der Perspektive des Teams zu betrachten: Jedes Team sollte einen Code-Review-Leitfaden haben, auf den alle Entwickler zugreifen können. Es ist äußerst wichtig, sicherzustellen, dass alle auf dem gleichen Stand sind und die gleichen Ressourcen zur Verfügung haben. Dieser Leitfaden enthält eine Liste von kritischen Punkten, die für ein erfolgreiches Code-Review notwendig sind. Durch diesen Leitfaden wird sichergestellt, dass der Code eine gute Struktur hat, gut performt, ordnungsgemäß dokumentiert ist und leicht wiederverwendbar, lesbar und wartbar bleibt. Wir müssen sicherstellen, dass unser Team die „Definition of Done“ (DoD) auf eine Weise definiert, die für alle leicht verständlich ist. Dies hilft uns dabei, sicherzustellen, dass alle Teammitglieder die Mindestqualitätsstandards kennen, die für das Endprodukt erforderlich sind.
Ein weiterer wichtiger Punkt ist, dass Teammitglieder ihre Kollegen motivieren, an Code-Reviews teilzunehmen! Eine Möglichkeit, die Qualität der Reviews zu steigern, besteht darin, Entwicklern die Möglichkeit zu geben, voneinander zu lernen. So können sie ihre Fähigkeiten und ihr Wissen teilen und gemeinsam bessere Software entwickeln. Jeder im Team sollte wissen, dass seine Beiträge wertvoll sind, unabhängig davon, wie viel Erfahrung er hat. Es ist wirklich wichtig zu erkennen, dass Code-Reviews nicht lästig sind, sondern ein wesentlicher Bestandteil des Entwicklungsprozesses. Auf diese Weise werden Entwickler bereitwillig Zeit und Mühe in die Durchführung von Reviews investieren.
Zusätzlich sollten sich die Teammitglieder gegenseitig motivieren, Feedback für kontinuierliches Lernen einzuholen, und eine offene Diskussionskultur schaffen. Ein erster Schritt kann die Förderung von Pair-Programming sein; dies kann oft dazu führen, dass Entwickler durch Echtzeit-Feedback von einem Ping-Pong zwischen ihren Kommentaren zur Perfektion gelangen. Wir können auch regelmäßige Code-Walkthroughs planen, um den Autor und den Reviewer auf dem Laufenden zu halten und über den Fortschritt zu informieren.
Ein weiterer wichtiger Punkt ist, dass Teams einen Styleguide haben sollten, um ihren Code klar und leicht lesbar zu halten. Dies hilft allen Teammitgliedern, den Code zu verstehen, und erleichtert die Zusammenarbeit erheblich. Der beste Weg, dies zu erreichen, besteht darin, die Regeln des Styleguides auf Code-Editoren und den kontinuierlichen Integrationsprozess anzuwenden. Dadurch erhalten Entwickler sofortiges Feedback, um Code-Stil-Warnungen zu beheben, was den Prüfern ermöglicht, sich auf die Kernfunktionalität zu konzentrieren, anstatt auf den Code-Stil.
Teammitglieder sollten aus den Erfahrungen der anderen lernen. Um dies zu erreichen, sollten Teams regelmäßige Communities of Practice (CoPs) einplanen, um Trends und Probleme zu besprechen, die während einer Überprüfung auftreten. Diese Sitzungen (Backend CoP, Frontend CoP, Design CoP, usw.) helfen dem Team nicht nur, eine bessere Codebasis zu haben, sondern fördern auch das allgemeine Wachstum und den Erfolg des Teams.
Teams sollen große Stories in kleinere Sub-Tickets aufteilen, um Pull-Requests leichter bearbeiten zu können. Diese einfache Strategie kann dem Team helfen, die Aufgaben zu zerlegen. Jeder versteht die Story besser, was die Schätzung der Stories in Verfeinerungssitzungen erleichtert. Es kann auch dazu beitragen, dass Teammitglieder Verantwortung für die Story übernehmen und den Fortschritt leicht verfolgen können. Eine gute Story-Verfeinerung vereinfacht den Entwicklungsprozess und stellt sicher, dass das Team komplizierte Stories Schritt für Schritt bewältigen kann.
Code-Review aus der Perspektive des Autors
Wir müssen aufgeschlossen sein, um das Beste aus dem Review-Prozess herauszuholen. Wir sollten daran denken, dass jeder in unserem Team unterschiedliche Fähigkeiten und Sichtweisen hat. Diese Unterschiede sollten wir wertschätzen und respektieren. Wenn wir bereit sind, Kritik anzunehmen, können wir neue Dinge lernen und uns weiterentwickeln. Wir sollten freundlich und gelassen sein, wenn unsere Kollegen ihre Meinung äußern. Mach keine Annahmen. Wenn du dir bei etwas nicht sicher bist, stelle einfach Fragen. Das ist eine großartige Möglichkeit, Missverständnisse zu vermeiden. Unsere kooperative und aufgeschlossene Haltung ermöglicht es uns, uns zu verbessern und bessere Entwickler zu werden.
Als erfahrener Softwareentwickler ist es entscheidend, die Codebasis konsistent zu halten. Achte darauf, dass dein Code so konsistent wie möglich mit dem Rest der Codebasis ist. Bevor wir Änderungen am Projekt vornehmen, müssen wir sicherstellen, dass wir ein gutes Verständnis davon haben, wie es eingerichtet ist und wie die Dinge normalerweise gemacht werden. Es ist wichtig zu bedenken, wie sich deine Änderungen auf das gesamte Projekt auswirken und sicherzustellen, dass sie nichts durcheinanderbringen. Die Zusammenarbeit mit Teammitgliedern ist äußerst wichtig für eine einfache Wartung und sorgt dafür, dass alles reibungslos läuft.
Wie bereits besprochen, ist es für Entwickler äußerst wichtig, sich an die üblichen Codekonventionen zu halten, wenn sie Code schreiben. Dies trägt dazu bei, alles konsistent und leichter verständlich zu halten. Diese Codestandards umfassen Regeln für Kommentarkonventionen, Einrückungsstilkonventionen, Zeilenlängenkonventionen, Namenskonventionen usw. Der beste Weg, diese Konventionen einzuhalten, besteht darin, einen Linter oder einen Code-Formatter zu verwenden, der Entwickler während der Entwicklung automatisch auf Verstöße hinweist.
Es ist auch vorteilhaft, wenn ein Entwickler einen fehlgeschlagenen Test für eine Fehlerbehebung schreibt; dies hilft, die Ursache des Fehlers zu verstehen, während versucht wird, den Fehler in einem Test zu reproduzieren. Wenn das Problem erfolgreich behoben wurde, sollte der fehlgeschlagene Test bestanden werden. Mit dem fehlgeschlagenen Test können wir unser Codebasis sicher ändern, und sie bleibt vertrauenswürdig.
Ein Entwickler sollte immer versuchen, überprüfbaren Code zu schreiben. Um dies zu erreichen, kannst du deine Commits klein und einfach halten. Dies hilft den Prüfern, den Code leichter zu verstehen. Es ist oft viel einfacher, einen Code mit zehn Commits, die jeweils verschiedene Dinge tun, zu verstehen, als einen Commit mit zehn verschiedenen Funktionen. Kleine Commits können die Gesamtkomplexität verringern.
Automatisierte Tests können die Qualität und Stabilität der Software aufrechterhalten. Diese Tests helfen Entwicklern, Probleme in ihrem Code zu identifizieren, die bei regulärer Nutzung möglicherweise nicht auftreten. Auf diese Weise können Prüfer sicher sein, wenn sie einen Pull-Request genehmigen. Wir müssen sicherstellen, dass unsere Tests alle möglichen Szenarien abdecken, aber wir müssen sie auch so schreiben, dass sie leicht zu verstehen sind.
Wir müssen sicherstellen, dass unsere Dokumentation immer auf dem neuesten Stand ist. Das ist äußerst wichtig! Wir müssen alle Änderungen an unserer Codebasis verfolgen. Auf diese Weise können wir leicht sehen, was wir geändert haben und wann! Mit Dokumentation können wir Änderungen schnell erfassen und Verwirrung vermeiden. Eine klare und einfache Dokumentation sorgt für einen reibungslosen und effizienten Überprüfungsprozess.
Wenn wir uns bei den vorgenommenen Codeänderungen nicht sicher sind, ist es immer eine gute Idee, ein Teammitglied um Feedback zu bitten. Wenn wir unsere Zweifel kommunizieren und Feedback erhalten, können wir von anderen Kollegen lernen. Während dieser Art von Zusammenarbeit können wir auch die allgemeine Codequalität verbessern.
Am Ende können wir es unseren Teamkollegen erleichtern, indem wir unseren Code selbst überprüfen, bevor sie dies tun. Manchmal vergessen wir, bestimmte Dinge zu tun, lassen einige Variablen ungenutzt oder finden die Dokumentation unklar. Das passiert uns allen! Daher sollten wir unseren Code kurz überprüfen, bevor wir ihn live stellen. Auf diese Weise können wir lästige Probleme vermeiden und sicherstellen, dass unsere Arbeit erstklassig ist.
Code-Review aus der Perspektive des Reviewers
Das Erste, was erwähnt werden sollte, ist, dass es beim Review eines Pull-Requests wichtig ist, aufgeschlossen zu sein und hilfreiches Feedback zu geben. Wir sollten uns auf den Code konzentrieren und vermeiden, mit dem Finger auf Personen zu zeigen! Wenn wir etwas empfehlen, sollten wir versuchen, spezifisch und hilfreich zu sein, ohne zu aufdringlich zu wirken. Vergiss nicht, ein Lob auszusprechen, wenn du etwas Cooles in dem Pull-Request entdeckst! Wenn wir einen guten Code-Review-Prozess haben wollen, der uns hilft, uns zu verbessern, müssen wir sicherstellen, dass sich alle auf die Entwicklung und eine positive Einstellung konzentrieren.
Ich habe irgendwo gelesen, dass der herausforderndste Teil der Softwareentwicklung nicht das Codieren selbst ist, sondern das Verstehen der Anforderungen. Die Anforderungen können den Prüfern helfen zu entscheiden, ob die vorgenommenen Änderungen den Bedürfnissen der Story entsprechen. Es ist immer eine gute Idee, die Story durchzugehen und ihren Hintergrund zu verstehen. Man sollte auch in Kontakt mit dem Beitragenden bleiben – falls etwas unklar ist, nicht nur im Code, sondern auch in der Story selbst.
Wir sollen Konflikte in Pull-Requests so schnell wie möglich klären. Es ist normal, während Code-Reviews Meinungsverschiedenheiten zu haben, aber es ist wichtig, sie schnell zu lösen. Wenn ein Pull-Request zu lange offen bleibt, kann es zu Merge-Konflikten kommen oder den Entwickler dazu bringen, zwischen verschiedenen Stories hin- und herzuschalten. Dies kann es schwierig machen, konzentriert zu bleiben, daher ist es am besten, den Kontextwechsel so oft wie möglich zu vermeiden.
Wie bereits gesagt, ist es bei der Überprüfung eines PRs wichtig, darauf zu achten, dass der Code leicht lesbar, wartbar und skalierbar ist. Neben dem Auffinden von Fehlern ist es unsere Aufgabe, sicherzustellen, dass der Code leicht verständlich ist. Wir müssen sicherstellen, dass alle Variablen- und Funktionsnamen sinnvoll sind, der Code richtig eingerückt ist und die Kommentare leicht zu verstehen sind. Um sicherzustellen, dass wir in Zukunft leicht etwas ändern können, müssen wir wiederholten Code oder Code-Gerüche erkennen. Es wäre großartig, wenn wir die gleichen Teile immer wieder verwenden könnten und uns nicht wiederholen müssten.
Wenn wir einen Pull-Request reviewen, ist es wichtig zu bedenken, wie sich Änderungen am Code auf andere Dienste auswirken könnten. Alles muss reibungslos laufen! Deshalb ist es wichtig, ein detailliertes Code-Review durchzuführen, um potenzielle Probleme zu erkennen.
Es ist wichtig, die Tests sehr sorgfältig zu überprüfen. Wir müssen sicherstellen, dass diese Tests alles abdecken, was der Code tun soll – auch die schwierigen Dinge, die nicht immer passieren. Bei der Überprüfung müssen wir sicherstellen, dass wir alles testen und verschiedene Szenarien ausprobieren. Wir dürfen hier nichts übersehen.
Wir zudem müssen auch alle zugehörigen Dokumente überprüfen. Das ist notwendig weil wir sicherstellen müssen, dass der Code mit der ursprünglichen Dokumentation übereinstimmt. Gute Dokumentation ist wie eine Landkarte für Entwickler, die ihnen hilft, den aktuellen Code zu verstehen, zu warten und zu verbessern. Sie macht es viel weniger verwirrend, wenn wir neue Dinge hinzufügen oder ein Bug fixen wollen.
Wir können Kommentare, die mit ’nit‘ beginnen, verwenden, um schnell auf kleine Probleme hinzuweisen. Zum Beispiel könnten wir schreiben : ’nit: entferne alle Leerzeichen‘. ‚Nit‘ gibt dir einige interessante Informationen, die nicht wirklich notwendig sind, aber dennoch interessant sein können. Die Fähigkeit, die wichtigsten Kommentare zu identifizieren, kann uns helfen, Änderungen effektiver zu priorisieren.
Fazit des Code-Review-Handbuchs
In diesem Blogbeitrag haben wir einige Best Practices für Code-Reviews besprochen. Diese Tipps können uns helfen, Code zu verbessern und die Kommunikation sowie den Informationsaustausch im Team zu erleichtern. Es ist großartig, Richtlinien für Code-Reviews zu haben, da sie sowohl den Autoren als auch denReviewers helfen, kleine Details zu erfassen, die sie möglicherweise übersehen haben. Als Entwickler können wir aus jedem Review-Prozess lernen und unseren Code verbessern, wenn wir für konstruktives Feedback offen sind.
Mit diesen coolen Tipps können wir unseren Code-Review-Prozess weniger kompliziert gestalten, eine bessere Codebasis schaffen und letztendlich großartige Softwareprodukte liefern.
Wenn du mehr über meine, Mert Yuecel, Projekte erfahren möchtest, schau gerne auf meinem GitHub-Profil vorbei oder vernetze dich mit mir auf LinkedIn – ich freue mich auf den Austausch!
