Praktische Tipps für eine effektive Codeprüfung. Teil 2

    Der erste Teil der praktischen Tipps für eine effektive Codeprüfung wurde vor mehr als zwei Jahren verfasst, hat jedoch nicht an Relevanz verloren. Dieser Artikel enthält einige weitere Tipps, mit denen Sie die Effektivität dieser komplexen und verantwortungsvollen Praxis verbessern können. Kurz gesagt, Inspektionen müssen schnell durchgeführt werden, darüber sprechen, visualisieren und nicht versuchen, die Unermesslichkeit zu erfassen.


    Im Rhythmus eines Walzers


    Inspektionen sollten schnell enden. Eine vollständige Inspektion liegt vor, wenn der Code überprüft wird, alle erkannten Fehler korrigiert werden und die Korrekturen vom Inspektor überprüft werden. Wenn die Inspektion lange dauert, treten folgende Probleme auf:
    • Es ist schwer zu verstehen, wer was tut.
    • Entwickler sind unscharf, dh es gibt mehrere Inspektionen und Aufgaben gleichzeitig, an denen sie arbeiten, was zu einer schlechten Leistung führt.
    • Inspektionen werden irrelevant, dh ein Code wurde zur Inspektion ausgegeben, aber in Wirklichkeit ist er im Versionskontrollsystem bereits anders.
    • Inspektionen werden defokussiert. Je länger die Inspektion dauert, desto mehr Inspektionen erhält der Code Korrekturen, desto schwieriger ist es, die Inspektion durchzuführen.

    Wenn die Inspektion länger als drei Tage dauert, stimmt etwas nicht - entweder verzögert jemand oder versucht, das Unermessliche anzunehmen.

    Umarmen


    Manchmal sieht der Inspektor, dass eine Aufgabe dieser Art bereits wiederholt gelöst wurde, und wenn ein Refactoring durchgeführt wird, können ähnliche Aufgaben viel billiger gelöst werden. Infolgedessen steht der Inspektor vor einem Dilemma: Schreiben Sie entweder eine Bemerkung innerhalb der Inspektion, dass Refactoring durchgeführt werden soll, oder schreiben Sie nicht, da Refactoring zeitaufwändig und ungeplant sein kann.

    Einerseits muss die Bemerkung aufgezeichnet werden, da das Verständnis der Notwendigkeit eines Refactorings ein nützliches Ergebnis der Arbeit des Inspektors ist, das erhalten bleiben muss. Wenn Sie nicht umgestalten, werden wir weiterhin unsere Anstrengungen verschwenden, wenn wir eine andere ähnliche Aufgabe ausführen. Wenn der Inspektor hingegen einen solchen Fehler macht, tritt ein weiteres Problem auf - sehr lange Inspektionen. Der Ausweg besteht darin, eine neue Refactoring-Aufgabe außerhalb des Rahmens dieser Inspektion zu erstellen. Das heißt, es ist besser, schwerwiegende Mängel in Form einer separaten Aufgabe zu starten, für die eine separate Inspektion erstellt wird. Eine grobe Schätzung, was ein „schwerer Defekt“ ist, ist ein Defekt, dessen Behebung mehr als zwei Stunden dauert.

    Besser einmal zu hören


    Nichts kann Live-Kommunikation ersetzen. Es gibt objektiv komplexe Aufgaben mit komplexen Lösungen. In diesem Fall kann der Autor vor der Durchführung der Inspektion den Inspektoren live mitteilen und den Inspektoren die Lösung mit Hilfe von Fingern, einer IDE, einem Stück Papier oder einer Tafel mit Filzstiften zeigen. Im Idealfall wird der Autor dies vor der Implementierung der Lösung tun, obwohl es besser spät als nie ist. Es besteht jedoch die Gefahr, dass Sie nicht versuchen, fehlerhaften unlesbaren Code mit verbalen Erklärungen zu korrigieren. Der Code bleibt schlecht, auch wenn alles im Detail darüber erzählt wurde.

    Übrigens ist es manchmal nützlich, Tester zu solchen Geschichten einzuladen. Wenn Sie die Details der Implementierung kennen, können Sie besser testen und nicht triviale Fehler finden.

    Visualisiere es


    Die Code-Inspektion ist neben der Entwicklung und dem Testen eine wichtige Phase des Task-Lebenszyklus. Wenn Sie ein Scrum- oder Canban-Board verwenden, ist es sinnvoll, eine andere Spalte für die Inspektionsphase zwischen den Spalten "In Entwicklung" und "Testbereit" auszuwählen. In diesem Fall wird die Tafel den tatsächlichen Stand der Dinge genauer wiedergeben, was von ihr verlangt wird.

    Jetzt auch beliebt: