Das zur Softwareentwicklung heute mehr gehört als einfach nur irgendwie die gewünschte (oder gar vermeintlich gebrauchte) Funktionalität zusammen zu hacken, hat sich ja bei den meisten herumgesprochen.
Die erstellte Software soll heute auch einen gewissen Qualitätsanspruch genügen. Aber was ist Qualität. Wenn man diese Frage in eine Runde von Softwareentwicklern stellt, so bekommt als Antwort auch schon mal ein breites Spektrum von fragenden Gesichtern bis hin zu einer Reihe an Buzzwords. Dabei findet sich dann so was wie Testabdeckung, Checkstyle, Dokumentation und ab und an auch mal FindBugs etc. Recht selten gibt es dann auch Antworten wie SOLID, lesbarer Code etc.
Auffällig ist, dass zuerst meistens Dinge genannt werden, welche durch irgendwelche Tools und IDE Plug-Ins automatisch geprüft werden könne. Das bestehen dieser Prüfungen oder erreichen gewisser Werte (Testabdeckung) wird dann als Qualität interpretiert.
Grundsätzlich ist die Anwendung dieser Tools ja nicht schlecht, wenn sie gezielt eingesetzt werden und nicht einfach alle Verfügbaren eingebunden werden. Die Masse der Kennzahlen und Tools mach auch hier keine Qualität. Die Tools können helfen sich gute Gewohnheiten anzueignen oder bei Dingen, welche man selten implementiert an die Gefahren zu denken.
Leider werden aber einige Entwickler zu Metrik Zombies sobald so ein Tool eingeführt ist. Sobald das Tool ein Problem meldet wird alles getan um die Meldung zu entfernen. Ob das Problem damit behoben oder ein neues entstanden ist, ist zweitrangig. So wird z.B. ein nicht serialisierbares Feld in einer serialisierbaren Klasse als transient gekennzeichnet damit die Warnung verschwindet, aber nicht dafür gesorgt, dass dieses Feld nach einer deserialisierung wieder gesetzt wird. Die false positives oder den Klassiker mit der Testabdeckung brauch ich ja wohl nicht mehr aufführen oder? Ob dadurch die Qualität der Software steigt sei mal dahingestellt.
Gute Gegenmittel sind die ausgewogene Wahl der eingesetzten Tools verbunden mit einem Verständnis für Ergebnisse und Reviews welche Lösungen auch mal kritisch betrachten dürfen.
Viel Erfolg im Kampf gegen die Untoten im Team.
Die erstellte Software soll heute auch einen gewissen Qualitätsanspruch genügen. Aber was ist Qualität. Wenn man diese Frage in eine Runde von Softwareentwicklern stellt, so bekommt als Antwort auch schon mal ein breites Spektrum von fragenden Gesichtern bis hin zu einer Reihe an Buzzwords. Dabei findet sich dann so was wie Testabdeckung, Checkstyle, Dokumentation und ab und an auch mal FindBugs etc. Recht selten gibt es dann auch Antworten wie SOLID, lesbarer Code etc.
Auffällig ist, dass zuerst meistens Dinge genannt werden, welche durch irgendwelche Tools und IDE Plug-Ins automatisch geprüft werden könne. Das bestehen dieser Prüfungen oder erreichen gewisser Werte (Testabdeckung) wird dann als Qualität interpretiert.
Grundsätzlich ist die Anwendung dieser Tools ja nicht schlecht, wenn sie gezielt eingesetzt werden und nicht einfach alle Verfügbaren eingebunden werden. Die Masse der Kennzahlen und Tools mach auch hier keine Qualität. Die Tools können helfen sich gute Gewohnheiten anzueignen oder bei Dingen, welche man selten implementiert an die Gefahren zu denken.
Leider werden aber einige Entwickler zu Metrik Zombies sobald so ein Tool eingeführt ist. Sobald das Tool ein Problem meldet wird alles getan um die Meldung zu entfernen. Ob das Problem damit behoben oder ein neues entstanden ist, ist zweitrangig. So wird z.B. ein nicht serialisierbares Feld in einer serialisierbaren Klasse als transient gekennzeichnet damit die Warnung verschwindet, aber nicht dafür gesorgt, dass dieses Feld nach einer deserialisierung wieder gesetzt wird. Die false positives oder den Klassiker mit der Testabdeckung brauch ich ja wohl nicht mehr aufführen oder? Ob dadurch die Qualität der Software steigt sei mal dahingestellt.
Gute Gegenmittel sind die ausgewogene Wahl der eingesetzten Tools verbunden mit einem Verständnis für Ergebnisse und Reviews welche Lösungen auch mal kritisch betrachten dürfen.
Viel Erfolg im Kampf gegen die Untoten im Team.
Oh man: Beim Lesen der Überschrift dachte ich, dass es um eine Metrik Namens "Zombies" geht, also zum Beispiel den Prozentsatz der Klassen/Methoden, die im Projekt vorhanden aber nie benutzt werden. :-D
AntwortenLöschenÜber die "Zombie Metrik" sollte man mal nachdenken :-)
Löschen