I'm a coder - Review rejected
Es wird mal wieder Zeit für eine I’m a coder News und das heutige Thema werden Reviews sein. Selbige sind extrem wichtig für die Qualität einer Software, welche mitunter maßgeblich durch die eigentliche Codequalität definiert wird. Denn vor allem über längere Zeit ist Software mit guter Codequalität besser wartbar, erweiterbar und erlaubt einen einfacheren Einstieg für neue Entwickler. Reviews sind wichtig, doch auch schwierig und zeitaufwendig. Entsprechend gehen sie manchmal unter, werden nur halbherzig gemacht oder sind zu streng bzw. zu nachsichtig. Hier einen guten Mittelweg zu finden ist schwer, aber extrem wichtig. Nachdem man die eigentlichen Änderungen verstanden und die Funktionalität überprüft hat, folgt der meiner Meinung nach schwerste Teil. Denn nun muss man die Validierung bezüglich der Einhaltung von Coding Guidelines und Naming Vorgaben durchführen.
Hier gibt es zwar Regeln, aber selbige lassen erfahrungsgemäß Spielraum für Interpretationen. Doch es ist wichtig Code an die richtige Stelle im Projekt zu platzieren, Dinge so zu benennen, dass man sie gut wieder findet und auch die Einhaltung von Konzepten wie MVVM usw. sollte sichergestellt werden. In diesen Bereichen muss jedes Team ein eigenes Level an Strenge finden und einen gemeinsamen Flow entwickeln, aber initial sollte man lieber zu viel mit einem Reject zurückschicken, als zu wenig. Entweder man ist einer Meinung und Änderungen werden durchgeführt oder man diskutiert über die Situation und einigt sich gemeinsam auf eine akzeptable Lösung, welche anschließend natürlich dokumentiert werden sollte. Auf diese Art und Weise sind alle involviert und sofern jeder das Recht hat Fragen zu stellen und Entscheidungen zur Diskussion zu stellen, entwickelt sich eine gute gemeinsame Basis, die hoffentlich zu gutem Code führt.
Ich persönlich merke dass ich manchmal zu viele Sachen bei einem Review durchgehen lasse. Dies geschieht aus verschiedenen Gründen, z.B. will man ein umfangreiches und gutes Ticket nur ungern wegen Kleinigkeiten ablehnen oder aber man denkt sich, die Änderungen können auch später gemacht werden. Es gibt eine Vielzahl von weiteren Gründen, die aber eigentlich alle nicht sonderlich valide sind. Vor allem im Nachhinein selbst Änderungen durchzuführen halte ich für falsch, auch wenn ich dies selber schon tat, denn man beschützt niemanden, man sorgt eher für Inselwissen in Bezug auf Coding Guidelines und ähnliches. Alle sollten gemeinsam über die Guidelines diskutieren, sie festlegen und sich an selbige halten. Auf dieser Basis sollten dann faire Reviews erstellt werden.
Der Weg zu einem optimalen Flow ist lang und man sollte immer versuchen sich zu verbessern, aber ich denke Arbeit und Zeitaufwand ist in diesem Bereich der Softwareentwicklung ist es definitiv Wert beachtet zu werden. Mich würde eure Meinung zum Thema generell und vor allem zu euren Review-Flows interessieren.