Hallo Spa\u00df Coder,<\/p>\n
ist euer Code immer perfekt? Macht ihr keine Fehler? Habt ihr immer auf Anhieb die beste Struktur und Architektur gefunden? Dann ist dieser Artikel nichts f\u00fcr euch. Heute wollen wir uns mit dem Thema besch\u00e4ftigen, wie wir im Team voneinander lernen k\u00f6nnen.<\/p>\n
Eine M\u00f6glichkeit, Wissen im Team zu verteilen und zu lernen, haben wir mit dem Pair Programming<\/a> ja bereits vorgestellt. Diesmal schauen wir uns an, wie wir auch in verteilten Teams gemeinsam zu besserem Code kommen k\u00f6nnen. Dabei helfen uns Code Reviews.<\/p>\n <\/p>\n Unter einem Review verstehen wir in der Softwareentwicklung die manuelle \u00dcberpr\u00fcfung der Arbeitsergebnisse. Beim Code Review geht es dabei insbesondere darum, den entstandenen Code zu pr\u00fcfen. Wir schauen uns den Code eines Kollegen an und pr\u00fcfen, ob der Code das macht, was er laut Beschreibung tun soll, sich an vereinbarte Standards h\u00e4lt und gut lesbar ist. Wir achten auf eine saubere Struktur, die Einhaltung der SOLID-Prinzipien<\/a>, die sinnvolle Verwendung von Patterns, saubere Fehlerverarbeitung, und so weiter und so weiter.<\/p>\n Wir schauen also kritisch auf den Code und pr\u00fcfen ihn eingehend auf Fehler und Sauberkeit.<\/p>\n <\/p>\n Durch Code Reviews finden wir Fehler bereits im Code, die wir sonst ggf. erst sehr sp\u00e4t in der Testphase entdecken. Ein 4-Augen-Pronzip ist eine g\u00fcnstige Art der Pr\u00fcfung. Dadurch erh\u00f6hen wir die Qualit\u00e4t der Software.<\/p>\n Ein Code Review sollte immer m\u00f6glichst im Dialog erfolgen. Dieser muss nicht zwingend direkt gef\u00fchrt werden, sondern kann auch asynchron erfolgen, etwa via E-Mail oder ein geeignetes Code Review-Werkzeug. Dadurch tauschen wir Wissen zwischen den beteiligten Entwicklern aus. Der Autor bekommt aktives Feedback zu seinem Code. Fehler werden entdeckt, auf m\u00f6gliche Testautomatisierung hingewiesen, schlecht lesbarer (und damit schlecht wartbarer) Code wird aufgedeckt. Der Reviewer liest Code, sieht guten Code und elegante L\u00f6sungen. Aber auch Fehler, die er selbst vielleicht auch gemacht h\u00e4tte. Beide lernen dabei was f\u00fcr sich.<\/p>\n Unterm Strich haben wir also mit recht geringem Kostenaufwand einen hohen Nutzen erzielt. Zus\u00e4tzlich erh\u00f6hen wir die Qualit\u00e4t der Software und die Wartbarkeit des Codes…und wir verringern den Truck Factor<\/a> als Risiko f\u00fcr das Projekt. Alles in allem erh\u00f6hen wir damit also die Kundenzufriedenheit durch saubere Software.<\/p>\n <\/p>\n Was generell f\u00fcr Teams gilt, damit diese gut und effizient zusammenarbeiten k\u00f6nnen, gilt f\u00fcr gemeinsam durchgef\u00fchrte Code Reviews insbesondere. So sind Einigungen \u00fcber Namenskonventionen, Code-Formatierung, Einsatz erlaubter Frameworks usw. im Vorfeld zu kl\u00e4ren, damit nicht jeder „seinen“ Code-Stil\u00a0 durchsetzen will. Im Team kommt es darauf an, einheitlich zu arbeiten. Pers\u00f6nliche Vorlieben m\u00fcssen dabei hinten anstehen.<\/p>\n Damit ein Code Review zu einem guten Ergebnis f\u00fcr alle Beteiligten wird, sollte der Autor kritikf\u00e4hig sein. Es geht darum, den Code zu bewerten, nicht den Autor zu diskreditieren. Wir wollen gemeinsam besseren Code und bessere Softwarequalit\u00e4t erreichen. Rechtfertigungen und unausgesprochene Kritik sind dabei fehl am Platz. Aber auch der Reviewer sollte sich an gewisse Feedback-Regeln<\/a> halten.<\/p>\n Hilfreich ist es – vor allem, wenn man gerade im Team mit Code Reviews beginnt – sich Ziele f\u00fcr das Code Review zu setzen. „Diese Woche schauen wir insbesondere auf saubere Benennung von Packages, Klassen und Variablen.“ oder „In diesem Sprint ist uns wichtig, dass es zu m\u00f6glichst jeder Klasse ausreichend automatisierte Tests gibt.“<\/p>\n Dass jeder Entwickler vor dem Einchecken ins Versionskontrollsystem den eigenen Code noch einmal \u00fcberpr\u00fcft, versteht sich nat\u00fcrlich von selbst.<\/p>\n <\/p>\n Zeitnah nach dem Einchecken des Codes schaut sich der Reviewer den Code an. Es sollten keine Review-Marathons durchgef\u00fchrt werden. Dann fehlt die Konzentration und vor allem, wenn man alle Reviews am Ende macht, die Zeit, die \u00c4nderungen auch noch sauber einzubauen.<\/p>\n Zun\u00e4chst schauen wir uns als Reviewer an, worum es bei dem commiteten Code \u00fcberhaupt geht. Wie ist die User-Story? Wie lauten die Akzeptanzkriterien? Welche Rahmenbedingungen gilt es zu beachten?<\/p>\n Anschlie\u00dfend verschaffen wir uns einen \u00dcberblick \u00fcber die \u00c4nderung. Welche Teile des Systems sind betroffen? Welche Codestellen wurden ge\u00e4ndert? Welche verschoben? Welche entfernt?<\/p>\n Dann schauen wir uns den Code an. Dabei achten wir ggf. besonders auf das Ziel, welches wir uns im Vorfeld gesetzt haben. Wir pr\u00fcfen den Code, ob er der Aufgabenstellung entspricht, suchen nach Fehlern und unsauberen Codestellen.<\/p>\n Finden wir was Auff\u00e4lliges, kommentieren wir dies entsprechend. Hierbei bietet sich nat\u00fcrlich ein entsprechendes Code Review Werkzeug an. Aber auch direktes pers\u00f6nliches Feedback ist angebracht. Wichtig ist, dass wir uns ausreichend Zeit nehmen und f\u00fcr Ruhe sorgen. Es geht nicht darum, die \u00c4nderung abzunicken, sondern zu pr\u00fcfen. Auch positive Anmerkungen sind erlaubt!<\/p>\n Wenn wir als Autor nun Feedback zu unserem Code erhalten, sollten wir nicht gleich in den Rechtfertigungsmodus schalten. Besser schauen wir uns den Kommentar einmal in Ruhe an, versuchen ihn zu verstehen und dann konstruktiv anzunehmen. Sind wir weiterhin der Ansicht, dass unser L\u00f6sungsvorschlag der bessere ist, bietet es sich an, dies mit dem Reviewer zu besprechen und gemeinsam zu einer einvernehmlichen L\u00f6sung zu kommen. Dabei gilt es f\u00fcr beide, kompromissbereit zu sein.<\/p>\n <\/p>\n Hier noch ein paar Tipps, die unser Kollege Mario dankenswerterweise zusammengestellt hat.<\/p>\n <\/p>\n <\/p>\n Wir beide arbeiten in aller Regel im Pair Programming, die extremste Form des Code Reviews. Wenn wir aber einmal getrennt an Code arbeiten, stellen wir uns diesen gegenseitig vor, besprechen die Idee hinter der L\u00f6sung, den L\u00f6sungsweg, die Architektur usw.<\/p>\n Dabei gibt der andere jeweils seine Einsch\u00e4tzung ab, was man am Code noch verbessern kann. Diese bauen wir bei Kleinigkeiten (Refactorings) dann direkt ein oder merken wir uns f\u00fcr sp\u00e4ter vor, wenn es um gr\u00f6\u00dfere \u00c4nderungen geht.<\/p>\n Der wichtigste Punkt f\u00fcr uns ist dabei immer, das gegenseitige Lernen. Wir lernen unsere gesamte Codebasis kennen, auch, wenn wir sie nicht immer selbst geschrieben haben.<\/p>\n Formellere Reviews, die wir in dem Unternehmen, in dem wir arbeiten durchf\u00fchren, zielen vielmehr auf die Punkte der Codequalit\u00e4t ab. Aber auch hier wollen wir immer m\u00f6glichst viel lernen oder unser Wissen und unsere Erfahrung mit den Kollegen teilen.<\/p>\n <\/p>\n Zum Abschluss noch die Einheit, in der Code-Qualit\u00e4t gemessen wird: WTF\/Minute<\/a>. Je kleiner der Wert, desto besser \ud83d\ude09<\/p>\n <\/p>\n Wir w\u00fcnschen euch viel Spa\u00df beim Ausprobieren.<\/p>\n Eure Spa\u00df-Coder<\/p>\n <\/p>\n Dieser Artikel basiert neben unseren Erfahrungen auf folgenden Quellen:<\/p>\n http:\/\/de.wikipedia.org\/wiki\/Review_(Softwaretest)<\/a><\/p>\nWas ist ein Code Review?<\/h1>\n
Warum sollten wir Code Reviews durchf\u00fchren?<\/h1>\n
Was brauchen wir f\u00fcr Code Reviews?<\/h1>\n
Wie f\u00fchren wir Code Reviews durch?<\/h1>\n
Tipps f\u00fcr ein besseres Code Review<\/h1>\n
F\u00fcr den Autor<\/h2>\n
\n
F\u00fcr den Reviewer<\/h2>\n
\n
Unsere Erfahrung mit Code Reviews<\/h1>\n