=Paper=
{{Paper
|id=Vol-1332/paper_10
|storemode=property
|title=Clean Code – ein neues Ziel im Software-Praktikum
|pdfUrl=https://ceur-ws.org/Vol-1332/paper_10.pdf
|volume=Vol-1332
|dblpUrl=https://dblp.org/rec/conf/seuh/SchmeddingVR15
}}
==Clean Code – ein neues Ziel im Software-Praktikum==
https://ceur-ws.org/Vol-1332/paper_10.pdf
Clean Code – ein neues Ziel im
Software-Praktikum
Doris Schmedding, Anna Vasileva, Julian Remmers, Technische Universität Dortmund
doris.schmedding | anna.vasileva | julian.remmers@tu-dortmund.de
Zusammenfassung Im Software-Praktikum (SoPra) in unserer Fa-
In diesem Beitrag wird ein Konzept vorgestellt, wie kultät führen acht BA-Studierende gemeinsam Pro-
in der Informatik-Ausbildung die Sensibilität für gu- jekte durch. Etwa sechs bis 10 Gruppen bearbeiten
ten Code erhöht werden soll. Das Software-Prakti- gleichzeitig die gleichen Aufgaben. In einem Block-
kum bietet einen geeigneten Rahmen, dieses Ausbil- praktikum in der vorlesungsfreien Zeit dauert eine
dungsziel umzusetzen. Wir zeigen Code-Defizite, Projekt drei Wochen. Es werden nacheinander in 6
die sich in studentischen Projekten häufig finden. Es Wochen zwei Projekte durchgeführt.
wird ein Tool vorgestellt, das bei der Entdeckung
Wir verwenden die Programmiersprache Java.
unterstützt, und Refactorings präsentiert, mit denen
die Studierenden die selbst gefundenen Defizite Zur Modellierung setzen wir UML mit dem Tool
leicht beheben können. Astah ein. Aus dem Modell werden Java-Code-Rah-
men generiert. Als Entwicklungsumgebung benut-
Motivation zen wir Eclipse mit dem SVN-Plugin Subclipse. Die
In den ersten Semestern der universitären Ausbil- Dokumentation mit JavaDoc und JUnit-Tests sind
wichtige Bestandteile unseres Entwicklungsprozes-
dung liegt der Schwerpunkt darauf, die Konzepte
ses und inzwischen ebenso wie alle oben genannten
der verwendeten Programmiersprachen kennen zu
Tools und Methoden allgemein akzeptiert. Am Ende
lernen und funktional korrekte Programme zu
eines Projekts erfolgt die Abnahme und Bewertung
schreiben. Dies wird zumindest an der Fakultät für
Informatik an der TU Dortmund aufgrund der gro- der Projekte gegenseitig durch die Gruppen. Die Er-
gebnisse der Bewertung werden im Plenum disku-
ßen Anzahl der Studienanfänger weitgehend durch
automatisierte Tests überprüft. In der Software- tiert.
Auch wenn man nach drei Wochen nicht er-
Technik-Vorlesung liegt der Schwerpunkt auf der
warten kann, ein perfekt funktionierendes Pro-
Modellierung, Mustern [Gamma 2004] und dem
gramm zu erhalten, wird die funktionale Korrekt-
Vorgehen in Software-Entwicklungsprojekten, we-
heit als Ziel in der Software-Entwicklung von kei-
niger auf der Programmierung.
Erst in einem studentischen Software-Entwick- nem der Beteiligten in Frage gestellt. Für die Studie-
renden ist in ihrem eigenen Projekt und bei der Be-
lungsprojekt kommen die verschiedenen Aspekte
der Software-Entwicklung wie Prozessmodell, Mo- wertung der Ergebnisse der anderen Gruppen auch
das Aussehen des Programms sehr wichtig, insbe-
dellierung und Programmierung gemeinsam zum
sondere bei Spielen. Bisher überhaupt nicht im Fo-
Einsatz und fügen sich zu einem Ganzen. Die Be-
kus stand die innere Qualität der Programme. Das
deutung von Lesbarkeit und Verständlichkeit des
wollen wir ändern. Unsere Vision ist, dass der Qua-
Codes kann sich den Studierenden aber erst wirklich
erschließen, wenn mit mehreren Studierenden litäts-Check nach einer Änderung genauso selbst-
verständlich wie der JUnit-Test wird.
gleichzeitig in einem komplexen Projekten gearbei-
tet wird und die Studierenden anhand von selbst
produzierten Beispielen eigene evtl. auch leidvolle
Vorgehensweise
Erfahrungen beim Lesen fremden Codes sammeln. Dazu identifizieren wir zunächst einmal typische
Auch wenn die Wartbarkeit von Programmen ein Defizite in studentischen Projekten [Remmers 2014].
Aus der Masse von Qualitätsmängeln, die Martin
wichtiges Ziel in der Software-Entwicklung dar-
[Martin 2008] beschreibt, wählen wir diejenigen aus,
stellt, lässt sie sich im universitären Kontext, in dem
die
studentische Projekte nur eine kurze Lebensdauer für Studierende leicht verständlich sind,
haben, nur schwer vermitteln.
Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
81
häufig in Studenten-Projekten vorkommen, Studierenden zum Teil nur schwer vermitteln las-
leicht und möglichst mit Tool-Unterstützung er- sen, z. B. dass eine Methode maximal vier Zeilen
kennbar sind und lang sein soll. Jedenfalls erschienen uns Martins
mit Tool-Unterstützung einfach zu beheben Qualitätsanforderungen für unsere Studierenden
sind.
völlig unerreichbar, so dass wir einige erreichbare
Ab wann ein Qualitätsmangel vorliegt, ist eine Frage
Regeln [Remmers 2014] definiert haben, die von den
des persönlichen Anspruchs an die Qualität. Wenn
SoPra-TeilnehmerInnen nicht verletzt werden soll-
man mit einem Tool Qualitätsmessungen durch-
ten.
führt, lassen sich Grenzwerte angeben, was noch to-
Die Regeln wurden in die folgenden drei Grup-
leriert wird und ab wann ein Defekt vorliegen soll.
pen eingeteilt:
Wir geben jeweils an, für welche Grenzen wir uns
entschieden haben und diskutieren ihre Sinnhaf-
Bezeichner sollen verständlich sein und die
Java-Konventionen einhalten. Humor ist bei der
tigkeit. Wahl der Bezeichner zu vermeiden!
Ein erster Einsatz unserer Messinstrumente Methoden sollen nicht zu komplex sein, eine be-
und Grenzwerte im Software-Praktikum in der vor- stimmte Maximallänge nicht überschreiten und
lesungsfreien Zeit nach dem Sommersemester 2014 wegen der Vertauschungsgefahr nicht zu viele
diente zur Evaluation, ob die angenommenen Män- Parameter haben.
gel tatsächlich mit Hilfe des von uns ausgewählten Klassen sollen nicht zu lang sein, keinen toten
Code enthalten und keine Gott-Klassen sein.
Tools festzustellen sind und in welchem Umfang
(siehe “Ergebnisse unserer Messungen“) sie auftre- Gott-Klassen oder Gott-Objekte [Riel 1996] gehören
ten. Am Ende des SoPras erhielten die Gruppen je- zu den sogenannten Anti-Patterns und widerspre-
weils einen Bericht über die festgestellten Mängel. chen dem „Single-Responsibility“-Prinzip [Martin
In einem zweiten Einsatz im SoPra im WS 14/15 2008]. Als Gott-Klassen werden Klassen bezeichnet,
ist geplant, bereits in der Einführungsveranstaltung deren Methoden zu komplex sind, die auf zu viele
das Thema Code-Qualität anhand einiger Folien ein- Attribute anderer Klassen zugreift und deren Me-
zuführen und die Qualitätsmessung anzukündigen. thoden nur eine geringe oder gar keine Kohäsion be-
Den Studierenden stehen im Wiki des Software- sitzen.
Praktikums Tutorials zum Thema Clean Code [Mar- Außerdem haben wir nach dem Anti-Pattern
tin 2008], statische Code-Analyse und Refactoring „Magische Werte“ („Magic Values“) und nach Lite-
[Fowler1994] für das Selbststudium zur Verfügung. ralen anstelle von Konstanten in Bedingungen su-
Außerdem wird bei der Eclipse-Einführung gezeigt, chen lassen, da sie die Lesbarkeit und Wartbarkeit
wie einfache Refactorings durchgeführt werden. Im der Bedingungen verletzen.
Rahmen der Reflexion der Erfahrungen im ersten
Projekt [Schmedding 2011] soll jede Gruppe nach Statische Programmanalyse
dem ersten Projekt einen Bericht über die festgestell- Wir setzen die statische Programmanalyse hier im
ten Mängel erhalten und eine Diskussion über die Software-Praktikum zur Aufdeckung von Qualitäts-
möglichen Ursachen und Folgen der Mängel geführt mängeln ein. Dazu verwenden wir das Eclipse-
werden. Wir erwarten im zweiten Projekt eine Ver- Plugin PMD1. PMD prüft die Einhaltung einer sehr
besserung der Code-Qualität. umfangreichen Menge von vordefinierten Regeln,
Durch die Beschränkung auf zunächst einmal die jeweils unter bestimmten Oberbegriffen zusam-
wenige Mängel und den Einsatz eines Tools zur mengefasst sind. Manche der von PMD festgelegten
Qualitätskontrolle, jeweils gekoppelt mit Hinwei- Qualitätsregeln empfinden wir als zu streng, z. B.
sen, wie man den Mangel mit Tool-unterstützten Re- die Forderung, dass eine Methode nur ein „return
factorings einfach beheben kann, erhoffen wir uns statement“ enthalten soll. Dagegen sollten unserer
eine große Akzeptanz unserer Qualitätsoffensive. Meinung nach manche Grenzwerte wegen des rela-
tiv kleinen Projektumfangs und der begrenzten Pro-
Clean Code jektlaufzeit niedriger liegen.
In [Matin 2008] werden sehr viele Qualitätsmängel
beschrieben, die sehr ambitioniert sind und sich den
1 http://sourceforge.net/projects/pmd/files/pmd-e-
clipse/
82 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
Der Benutzer kann unter Preferences->PMD Refactoring
einzelne Regeln oder Regelgruppen an- oder abwäh- Sogenannte „Refactorings“ [Fowler 1999], Verbesse-
len. Außerdem besteht die Möglichkeit, eine spezi- rungen bestehenden Codes, werden eingesetzt, um
elle Regelmenge in Form einer XML-Datei (siehe die mit PMD gefundenen Mängel zu beseitigen.
Anhang B) zu laden. Für diesen Weg haben wir uns Wichtig ist, dass die Funktionalität erhalten bleiben
entschieden, um alle Studierenden mit den gleichen muss, was durch ständige Tests überprüft wird.
auf die Lehrveranstaltung zugeschnittenen Quali- Viele Refactorings sind in unserer Entwicklungsum-
tätsmaßstäben zu versorgen. Wie bereits erläutert, gebung Eclipse bereits standartmäßig integriert, so
haben wir für die Ausbildung im Software-Prakti- dass sie über das Kontextmenü leicht zu erreichen
kum eigene Grenzwerte definiert. Auch Spillner und anzuwenden sind.
und Linz empfehlen in [Spillner 2005], beim erstma- Mit Hilfe von Tutorials im SoPra-Wiki für das
ligen Einsatz eines Analysetools die Grenzwerte so Selbststudium wird gezeigt, welche Refactoring-
zu wählen, dass die Akzeptanz eines derartigen Techniken die Studierenden einsetzen können, um
Tools nicht gefährdet wird. die mit PMD (und FindBugs) gefundenen Mängel
Wir haben PMD als Analysetool ausgewählt, zu beseitigen. Ähnlich wie Martin beschreibt Fowler
weil es flexibel ist und gut in unsere Arbeitsumge- in [Fowler 1999] eine Fülle von Verbesserungen
bung passt. Außer PMD können die Studierenden (~70), aus denen wir diejenigen ausgewählt haben,
auch das Eclipse-Plugin FindBugs2 zur statischen die wir für unsere Studierenden für praktikabel und
Code-Analyse benutzen, das ebenfalls Bestandteil gut nachvollziehbar halten. Diejenigen, die sich mit
der vorbereiteten Entwicklungsumgebung ist. Tool-Unterstützung umsetzen lassen, sind die fol-
Im SoPra-Wiki wird für das Selbststudium ge- genden:
zeigt, wie man PMD (und FindBugs) verwendet und Rename wird zur Verbesserung der Namensge-
eigene Regeln einbindet. Die im SoPra eingesetzten bung eingesetzt und kann auf alle Bezeichner
PMD-Regeln sind in Anhang B im XML-Format auf- angewendet werden. Da alle Aufrufe mit geän-
gelistet. Die gewählten konkreten Grenzwerte für dert werden, können die Studierenden gut die
die eingesetzten Zählmetriken kann man dem An- Mächtigkeit des Werkzeugs erkennen.
hang A entnehmen. Die Wahl der Grenzwerte wird Extract Method kann eingesetzt werden, wenn
eine Methode zu lang oder zu komplex gewor-
jeweils im Zusammenhang mit den Ergebnissen der
den ist. Das Werkzeug legt für den markierten
Messungen erläutert. Einige Grenzwerte haben wir
Bereich eine neue Methode an und ersetzt ihn
von PMD übernommen, für andere haben wir unse- durch den Aufruf der Methode.
rem Ausbildungsumfeld angepasste Werte gewählt. Extract Local Variable kann verwendet werden,
Das Kriterium für die Erkennung einer möglichen wenn der Code aufgrund einer langen Aufruf-
Gott-Klasse wird im Zusammenhang mit den Mess- kette nur noch schwer lesbar ist. Dann wird für
ergebnissen (siehe Klassen) vorgestellt und disku- die markierte Aufrufkette automatisch eine neue
tiert. lokale Variable angelegt.
Nicht alle für das Software-Praktikum als wich-
Mit Introduce Parameter Object wird eine über-
lange Parameterliste durch ein Parameterobjekt
tig ausgewählten Regeln des Clean Codes lassen
ersetzt. Zusätzlich wird eine neue Klasse mit den
sich automatisch überprüfen. Kein Tool kann fest- früheren Parametern als Attributen angelegt,
stellen, ob ein Bezeichner sinnvoll gewählt wurde. auf Wunsch auch mit entsprechenden Zugriffs-
Als Indiz für eine sorgfältige Wahl dient uns die methoden.
Länge eines Bezeichners, die wir messen können. Mit Extract Constant kann eine Zahl in einer Be-
Aber wie Spillner und Linz [Spillner 2005] sind dingung in eine Konstante umgewandelt wer-
wir der Ansicht, dass sich Qualitätsstandards und den, um die Wartbarkeit und Lesbarkeit des
Codes zu erhöhen.
Konventionen nur dann einführen und beibehalten
lassen, wenn geeignete Prüfwerkzeuge vorhanden
Move verschiebt eine Komponente einer Klasse
innerhalb einer Klasse, bei Bedarf auch in eine
und leicht zu bedienen sind, da ein nicht automa- andere Klasse, sofern die ursprüngliche Klasse
tisch überprüfbares Regelwerk nur als bürokrati- eine Referenz auf die neue Klasse besitzt. Dann
scher Ballast empfunden wird. werden in Falle von Methoden ihre Aufrufe ent-
sprechend geändert.
2 http://findbugs.sourceforge.net/
Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
83
Alle anderen Mängel sollten manuell, also ohne E-
35 35
clipse-Refactoring-Tool, behoben werden. Das ist 31 29
z. B. die Beseitigung von totem Code kein Problem. 14 24 22
19
18 12
Von der Anwendung von Extract Class in Eclipse ra- 9 17
ten wir ab, da dessen Funktionalität nicht der in 14
21 14 17
[Fowler1999] beschriebenen entspricht. Extract 15 16 13
8
Class wird eingesetzt, um eine zu komplex oder zu 3
lang geratene Klasse zu teilen. Auch Extract Method Gr. 2 Gr. 3 Gr. 4 Gr. 5 Gr. 7 Gr. 8 Gr. 9
kann nicht immer voll automatisch vom Tool durch-
Control-Klassen Model-Klassen
geführt werden. Wenn in der zu extrahierenden An-
Summe
weisungsfolge mehrere Werte geändert werden,
stößt die Code-Transformation von Eclipse an ihre
Grenzen, die man auf jeden Fall berücksichtigen Abb. 1: Anzahl der Klassen
sollte. Die GUI-Klassen haben wir bei der Umfangs-
Eine wirkliche Verbesserung des Codes erhält smessung nicht mit berücksichtigt, da sie zwar sehr
man in der Regel erst, wenn man eine Kombination umfangreich sind, ihr Programmierstil aber
von Refactoring-Techniken anwendet, z. B. erst weitgehend von der Game-Engine (Slick2D oder
Extract Class und danach Move. Selbstverständlich LibGDX) geprägt ist. Wir interessieren uns mehr für
muss nach jeder Veränderung geprüft werden, ob die Teile der Programme, welche nach der
Modellierung mit UML selbst entwickelt wurden.
die verlangte Funktionalität noch gegeben ist und ob
die Mängel wirklich beseitigt wurden oder neue
Mängel entstanden sind. 217
1459 524
1337 302
Ergebnisse unserer Messungen 728 2260 215
In diesem Kapitel stellen wir die Ergebnisse unser 1463 1620
803 1418
Messungen vor, die wir durchgeführt haben, ohne 573 660
dass die Studierenden zuvor informiert waren, dass 237 246 206 288 212 221 231
wir die Codequalität analysieren würden. Gr. 2 Gr. 3 Gr. 4 Gr. 5 Gr. 7 Gr. 8 Gr. 9
Aufgabe in diesem Projekt war die Realisierung
LOC Controller LOC Model
eines Computerspiels, das Brettspiel Cartagena3 in
den Varianten Jamaika und Tortuga. Das Spiel sollte Summe
mit folgenden Anforderungen realisiert werden:
Drei verschiedene simulierte Gegner, Abb. 2: LOC differenziert nach Model- und Con-
Rücknahme der Züge bis zum Spielbeginn, trol-Klassen und Anzahl der Methoden insgesamt
Speichern und Laden angefangener Spiele,
Highscore-Liste, Man sieht, dass die Projekte sowohl in der Anzahl
Tipp für unerfahrene SpielerInnen, der Klassen (Abb. 1), zwischen 17 und 35, als auch
Editor für die freie Gestaltung des Spielfelds, im Umfang (Abb.2), zw. 1531 und 2477 LOC (Lines
Einlesen einer Spielsituation im vorgegebenen of Code), und Methodenanzahl, zw. 206 und 288,
Format. stark schwanken.
Am Software-Praktikum haben 8 Gruppen mit je 8 Da wir das MVC-Muster [Gamma u.a. 2004] für
Mitgliedern teilgenommen. Alle Gruppen haben die Strukturierung der Software vorgeben, wird in
funktionstüchtige Spielprogramme produziert, die Abb. 1 und Abb. 2 zwischen Model- und Control-
die oben aufgelisteten Anforderungen erfüllt haben.
Klassen unterschieden. Die beiden Gruppen 4 und 5
Da eine Gruppe (Gruppe 6) nicht unseren SVN-Ser-
ver sondern Git4 zur Versionsverwaltung benutzt haben eher dem objektorientierten Paradigma
hat, konnten wir keine Messung vornehmen. Eine folgend die Programmlogik den Klassen des
Gruppe (Gruppe 1) ist nicht zustande gekommen. Problembereichs, den Model-Klassen, zugeordnet,
Abb. 1 und Abb. 2 zeigen deshalb den Umfang der während die Model-Klassen Gruppen 3, 7, 8 und 9
Projekte von sieben Gruppen. fast nur Datenhaltung betreiben. Das wird in Abb. 2
gut deutlich: Die Model-Klassen von Gruppe 4 und
3 http://de.wikipedia.org/wiki/Cartagena_(Spiel) 4 http://git-scm.com/
84 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
5 sind deutlich umfangreicher als ihre Control- sind. Für jede Kategorie gab es maximal 10, Punkte
Klassen und die Model-Klassen der übrigen pro gefundenen Verstoß wurde ein Punkt abgezo-
Gruppen. Wir werden später sehen, dass, wie zu gen. Da wir davon ausgegangen sind, dass extrem
erwarten war, die einzelnen Model-Klassen der lange Klassen im SoPra selten sind, gab es dafür nur
anderen Gruppen, die rein der Datenhaltung maximal 5 Punkte.
dienen, nur kurz und wenig komplex sind. Das gilt
Namensgebung
auch für die Methoden dieser Klassen. Die Gruppe
2 hat während des Projektverlaufs ihre Strategie Bei der Suche nach Defekten in der Namensgebung
verändert, von zunächst „ganz dummen“ wurden verschiedene Aspekte unterschieden (siehe
Abb. 4):
Datenklassen, zu Model-Klassen mit mehr Logik.
Nicht-Einhaltungen der Java-Konventionen bei
Daher rührt das relativ ausgeglichene Bild vom der Bezeichnerwahl. Das kann von PMD festge-
Umfang von Model- und Control-Klassen in Abb. 2. stellt werden.
Am Ende der Projektlaufzeit von drei Wochen Sinnvolle oder nicht sinnvolle Bezeichner er-
haben wir ein Code-Review vorgenommen, indem kennt PMD natürlich nicht. Wir suchen nach be-
wir die verfügbaren Projekte der Gruppen und die sonders kurzen Bezeichnern (min. 5 Zeichen),
von PMD angezeigten Defekte kritisch analysiert schauen uns die Fundstellen an und entscheiden
und dokumentiert haben. Dazu mussten wir die über die Verständlichkeit. Bezeichner „t“ oder
„x“ haben bei uns keine Chance und führen zu
Projekte aus dem jeweiligen SVN-Repository her-
Punktabzug. Wir akzeptieren dagegen Bezeich-
unterladen und die Messungen mit PMD und den ner aus unserem Problembereich wie „Game“
SoPra-spezifischen Regeln durchführen. Die Stellen, oder „Zug“.
an denen PMD Defekte gefunden hat, haben wir uns
genauer angesehen und selbst beurteilt, ob es sich 12
um einen relevanten Verstoß handelt. Pro Gruppe
haben wir zu Zweit etwa eine Stunde benötigt. 10
70
8
60
50 6
40 4
30
20 2
10 0
0 Java-Konvention Sinnvolle
Gr. 2 Gr. 3 Gr. 4 Gr. 5 Gr. 7 Gr. 8 Gr. 9 Bezeichner
Abb. 3: Gesamtergebnis
Gr. 2 Gr. 3 Gr. 4 Gr. 5
Zum Projektabschluss bewerten die Gruppen ge-
genseitig ihre Projekte anhand eines von uns vorge- Gr. 7 Gr. 8 Gr. 9
gebenen Schemas, das in erster Linie die geforderte
Funktionalität und die Benutzungs-freundlichkeit Abb. 4: Namensgebung
berücksichtigt. Analog dazu wurde ein Bewertungs- Bei Gruppe 2 haben wir keine Defekte in der
schema (siehe Anhang A) mit Punkten entwickelt, Namensgebung gefunden, da ein Gruppenmitglied
um die Gruppe (mit Schokolade) zu belohnen, die den Code überarbeitet hat. Wir können daraus
den nach unseren Erkenntnissen besten Code ge- schließen, dass sich Verstöße bei der Namensge-
schrieben hat. Abb. 3 zeigt die Summe der jeweils bung leicht mit PMD erkennen und mit den Refac-
toring-Techniken von Eclipse beseitigen lassen.
erreichten Punkte. Gruppe 2, die Siegergruppe, hat
Die Java-Konventionen werden von allen Gruppen
65 von 75 möglichen Punkten erreicht. Zusätzlich
weitgehend eingehalten. Wir vermuten, dass es da-
bekam jedes Entwicklungsteam einen Bericht, wel-
ran liegt, dass viele Bezeichner aus dem UML-Mo-
che Mängel in ihrem Projekt besonders typisch und
dell stammen, das einem mehrfachen Review-Pro-
häufig waren.
zess unterzogen wird. Besonders viele einbuchsta-
Nachfolgend werden die verschiedenen As-
bige Bezeichner findet man bei den Parametern.
pekte diskutiert, die in die Bewertung eingegangen
Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
85
Auffällig waren Unterstriche in Methodenna- höchsten zyklomatischen Komplexität von 67 ist
men in Gruppe 9, die nicht den Java-Konventionen „loadGame“ von Gruppe 4.
entsprechen (Abb. 4). Sie haben wohl ihre Ursache Auch die von Eclipse generierten equals-Me-
in dem zuvor besuchten C-Kurs. thoden von Klassen sind schwer zu lesen und wer-
den von PMD als zu komplex eingestuft.
Methoden
Bei der genaueren Betrachtung der besonders
Bei Methoden haben wir ihre Länge, die Anzahl der komplexen Methoden sieht man deutlich, wie die
Parameter und ihre zyklomatische Komplexität un- Entwickler mit der Komplexität „gekämpft“ haben.
tersucht.
Man findet Ausgaben auf die Konsole, auskommen-
Eine Methode sollte maximal 40 Zeilen lang
tierte Programmzeilen, Kommentare zur eigenen
sein. Bei PMD ist 100 als maximale Länge von Me-
Orientierung und Fragen („Was soll ich damit?“).
thoden eingestellt. Martin akzeptiert nur 4 Zeilen.
Keine Gruppe hat es geschafft, ohne zu komplexe
Wir denken aber, dass die Studierenden etwa 40 Zei-
Methoden auszukommen.
len noch überschauen können. Außerdem wollten
Eine Parameterliste wird als zu lang angesehen,
wir die Messlatte auch nicht zu hoch bzw. zu niedrig
wenn sie fünf oder mehr Parameter beinhaltet. Der
setzen.
Defekt, sehr lange Parameterlisten zu verwenden,
Wie man sieht (Abb. 5), hat es keine Gruppe ge-
ist in den Gruppen unterschiedlich häufig
schafft, ohne zu lange Methoden auszukommen. Die
vorgekommen. Im Programm von Gruppe 5 fand
längste gefundene Methode mit 186 Zeilen hat die
sich eine Methode mit 7 Parametern. Das war der
Gruppe 9 produziert. Die Gruppe 8 hat so viele
höchste gefundene Wert.
lange Methoden geschrieben, dass in diesem Bereich
keine Punkte erhalten geblieben sind. Klassen
10 Wir betrachten Klassen als zu groß, wenn sie mehr
als 400 Zeilen lang sind. Voreingestellt bei PMD sind
8 1000 Zeilen, was bei einem Projektumfang von etwa
2000 LOC im Software-Praktikum viel zu viel ist
6 und in keiner Weise den Ideen von Clean Code ent-
spricht.
4 Wie bereits erwähnt, haben wir nur 5 Plus-
punkte als Guthaben für diese Rubrik verteilt. Alle
2 Gruppen konnten mindestens 2 Punkte behalten
(siehe Abb. 6), so dass unsere Vermutung bestätig
0 wurde, dass sehr große Klassen im SoPra selten
LOC der #Parameter Zyklom. sind. Gruppe 2, Siegerin der Gesamtwertung und
Methoden Methoden Komplexität eine der Gruppen mit den meisten Klassen (35), hat
überhaupt keine überlange Klasse produziert.
Gr. 2 Gr. 3 Gr. 4 Gr. 5 Die zu langen Klassen sind auch die, die von
PMD als Gott-Klassen identifiziert werden. Gott-
Gr. 7 Gr. 8 Gr. 9
Klassen sind Klassen, die zu viel wissen und sich in
zu viele Dinge einmischen.
Abb. 5: Methoden
PMD setzt in der Regel “GodClass“5 eine Stra-
Die extrem langen Methoden besitzen in der Regel tegie zur Erkennung um, welche in [LMD06] be-
auch eine hohe zyklomatische Komplexität. Die schrieben wurde. Nach dieser Strategie kann eine
längste Methode (von Gruppe 9) hatte eine zyklo- Gott-Klasse durch die Berechnung der drei Werte
matische Komplexität von 49. Als mangelhaft wer- WMC, ATFD und TCC erkannt werden:
den Methoden ab einer Komplexität von 10 gewer- WMC (Weighted Method Count) ist die Summe
tet. Das entspricht dem von McCabe [McCabe 1976] der zyklomatischen Komplexitäten aller Metho-
selbst vorgeschlagenen Wert. Die Methode mit der den einer Klasse. Diese darf nach der Regel
„GodClass“ den Grenzwert von 47 nicht über-
schreiten.
5Die Regel „GodClass“ wird in folgender Java- 5.1.2/xref/net/sourceforge/pmd/lang/java/rule/de-
Klasse definiert: http://pmd.sourceforge.net/pmd- sign/GodClassRule.html
86 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
ATFD (Access To Foreign Data) ist die Anzahl Auch die Klassen, die jeweils den simulierten Com-
der direkten Zugriffe einer Klasse auf Attribute putergegner realisieren, werden in fünf von sieben
anderer Klassen. Diese darf nach der Regel Gruppen als potentielle Gott-Klassen erkannt. In
„GodClass“ nicht höher als 5 sein.
TCC (Tight Class Cohesion) ist für eine Klasse
diesen Klassen wird die Spielsituation analysiert
und ausprobiert, welcher Zug zu einer neuen, be-
als Quotient definiert, die Anzahl an Methoden-
paaren, die auf mindestens ein gemeinsames At- sonders vorteilhaften Spielsituation führt. Die
tribut oder eine lokale Methode (dieser Klasse) Gruppe 5 hat für jede der geforderten KI-Stärken
zugreifen, die also eng miteinander verbunden eine eigene Klasse angelegt, wobei alle drei als Gott-
sind, durch die Gesamtzahl alle möglichen Be- Klassen erkannt werden.
ziehungen zwischen den Methoden [LMD06]. Außerdem sind die Klassen gefährdet, die den
Entsprechend kann TCC Werte zwischen 0 und Zug des Menschen auf Zulässigkeit prüfen, alle
1 annehmen. Der berechnete Wert darf nach der
möglichen Züge bestimmen und den Zug durchfüh-
Regel „GodClass“ 0,33 nicht unterschreiten. An-
ren. Diese Klassen heißen „Game“, „GameControl-
sonsten liegt die gewünschte Kohäsion der Me-
thoden nicht vor und man kann die Klasse rela- ler“, „Board“ oder „BoardController“, „SpielerCon-
tiv leicht aufteilen. troller“ oder „Human“. Damit sind schon alle als
Gott-Klassen erkannte Klassen genannt. Alle Grup-
10 pen haben sich mindestens eine Gott-Klasse geleistet
(siehe Abb. 6).
8 Im Gegensatz zu den Control-Klassen sind bei
fast allen Gruppen die Model-Klassen in Ordnung.
6 Was nicht weiter erstaunlich ist, wenn man sich da-
ran erinnert, dass es sich hier meist um einfache Da-
4 tenhaltungsklassen handelt. Nur bei Gruppe 5, eine
der Gruppen mit einem eher objektorientierten An-
2 satz, finden sich auch im Modell mögliche Gott-
Klassen, z. B. die Klasse „Board“ mit WMC=112,
0 ATFD=51, TCC=0.098.
LOC der Toter Code Gott-Klassen Zusammenfassend lässt sich festhalten, dass
Klassen bei uns spezielle Klassen dafür prädestiniert zu sein
scheinen, sich zu Gott-Klassen zu entwickeln, näm-
Gr. 2 Gr. 3 Gr. 4 Gr. 5 lich diejenigen mit den algorithmisch anspruchs-
Gr. 7 Gr. 8 Gr. 9 vollsten Aufgaben.
Auch wenn Bezeichner wie „…Manager“ oder
Abb. 6: Klassen „…Controller“ Hinweise auf potentielle Gott-Klas-
sen liefern sollen, hat bei uns die Gruppe 5 die meis-
Wenn eines der Kriterien verletzt ist, wird eine Gott-
Klasse vermutet. Bei uns waren meist zwei oder alle ten potentiellen Gott-Klassen produziert, obwohl sie
Kriterien betroffen. Die längste Klasse „GameCon- einen Ansatz mit mehr und umfangreicheren Mo-
troller“ mit 992 LOC ist auch eine mögliche Gott- del- als Control-Klassen gewählt hatte.
Klasse. Auch das Muster, dass Gott-Klassen gern aus
Schaut man sich die Projekte im Detail an, stellt „entarteten“ Mediator-Klassen [Gamma u.a. 2004]
man fest, dass es immer die gleichen Klassen sind, entstehen, haben wir so bei uns nicht gefunden. Me-
die als mögliche Gott-Klassen erkannt werden. Vier diator-Klassen werden von den Studierenden häufig
von sieben Gruppen haben nur eine Klasse für das eingesetzt, um die Arbeit der verschiedenen Con-
Einlesen der Spielsituation in dem vorgegebenen troller zu koordinieren. Sie heißen z. B. „MainCon-
Format angelegt, die den Inhalt der Datei einliest troller“. Bei uns scheint eher die algorithmische
und abhängig vom gelesenen String viele unter- Komplexität der Auslöser für Gott-Klassen zu sein.
schiedliche Objekte erzeugt. Oft hat diese Klasse Wir finden potentielle Gott-Klassen da, wo die algo-
dann sogar nur eine Methode wie die bereits als rithmisch anspruchsvolleren Aufgaben zu lösen
komplexeste Methode vorgestellte Methode „load- sind. Es gelingt vielen Studierenden offenbar nicht,
Game“ von Gruppe 4 (siehe Methoden). ein komplexes Problem in mehrere überschaubarere
Teilprobleme zu zerlegen.
Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
87
Toten Code haben wir in Form von unbenutz- aufgaben werden aus Platz- und Zeitgründen be-
ten Methoden, Parametern und Attributen gefun- sonders kurze Bezeichner verwendet. Man zeigt ja
den. Es gab leere Methoden, die als Code-Rahmen auch immer nur einen kleinen Ausschnitt. Die Stu-
aus dem UML-Modell generiert wurden, aber sich dierenden sind somit überhaupt nicht vorbereitet
dann wohl doch als überflüssig herausgestellt ha- auf die Notwendigkeit von aussagekräftigen Be-
ben. Wir haben auskommentierten Programmcode zeichnern und die Vermeidung von Zahlen in Be-
und sogar zwei unbenutzte Klassen gefunden. Die dingungen zur Verbesserung der Wartbarkeit in
Projektlaufzeit ist mit drei Wochen zu knapp für den umfangreicheren Projekten.
letzten Feinschliff oder die „Baustellen“ geraten in Der Zusammenhang zwischen der Länge einer
Vergessenheit, weil sie ja beim Kompilieren keine Methode und ihrer Komplexität ist leicht nachzu-
Fehler melden und die Ausführung des Programms vollziehen. Gruppen, die besonders viele lange Me-
nicht stören. thoden geschrieben haben, hatten auch viele kom-
plexe Methoden. Im Umkehrschluss kann man für
Weitere Defekte
die Studierenden die Empfehlung ableiten, keine
In den Spielprogrammen haben wir sehr häufig langen Methoden zu schreiben. Lange Methoden
Zahlen in Bedingungen gefunden, z. B. für die ma- sollten rechtzeitig aufgespalten werden. Derartiger
ximale Anzahl der Mitspieler und die Anzahl der Code ist auch besser zu testen.
Teilschritte, aus denen ein Zug besteht. In einem Die Beseitigung von langen Parameterlisten
Team, das sich wochenlang mit genau diesem Spiel durch das Refactoring „Introduce Parameter Object“
beschäftigt hat, mag ein derartiger Ausdruck abso- ist durchaus kritisch zu sehen, da bei seiner Anwen-
lut verständlich erscheinen. Ohne sehr gutes Kon- dung eine Klasse entsteht, die wiederum einen Kon-
textwissen aus der Aufgabenstellung und den Spiel- struktor mit gleicher Parameterliste hat. Auch die
regeln sind solche Code-Stellen nicht zu verstehen. Vermeidung von vielen Parametern durch Arraylis-
Ursache dafür scheint uns zu sein, dass gute ten oder Ähnlichem ist keine wirkliche Lösung, da
Vorbilder fehlen. Vielmehr ist die Formulierung dieser Code nicht besser lesbar ist. Vielmehr müssen
derartiger Bedingungen mit Literalen statt Konstan- von vornherein andere, kleinere Methoden entwor-
ten in anderen Vorlesungen und Übungen schon aus fen werden, die Teilaufgaben lösen.
Platzgründen üblich. Den Studierenden wird die Be- Die Länge einer Klasse scheint ein relativ leicht
deutung von lesbarem Code erst dann klar, wenn sie verständliches und leicht zu erkennendes Kriterium
in fremdem Code nach Fehlern suchen müssen. und ein gutes Indiz zu sein, um eine Klasse zu iden-
Da Java die Anordnung der Komponenten ei- tifizieren, die Gefahr läuft, sich zu einer Gott-Klasse
ner Klasse nicht wirklich einschränkt, findet sich in zu entwickeln. Die Regel für die Gott-Klassen mag
manchen Klassen eine lustige Abfolge von Metho- für Anfänger schwierig zu durchschauen sein, aber
den und Variablen. Dass die Deklaration nicht wahl- „zu lang“ kann wirklich jeder begreifen und im
los erfolgen sollte, sondern insbesondere in umfang- Auge behalten. Oft kann man beim Entwurf bereits
reichen Klassen einer vorgegebenen Ordnung ent- erkennen, dass eine Klasse sehr viele Methoden be-
sprechen sollte, wird nicht vermittelt und erst beim kommen soll. Dann könnten die Gruppenbetreuer
Studium fremden Codes klar. rechtzeitig den Tipp geben, die Klasse zu zerlegen.
Insbesondere, wenn ein Mangel an Kohäsion der
Diskussion der Ergebnisse Methoden vorliegt, sollte die Aufspaltung kein
Wir haben relativ viele Mängel gefunden. Die Stu- Problem sein.
dierenden wussten allerdings beim Programmieren Das Refactoring von einmal entstandenen Gott-
nicht, dass wir danach suchen würden. Klassen ist relativ kompliziert. In dem Entwicklerfo-
Die Probleme bei der Namensgebung und die rum „Stackoverflow“ findet man auf die Frage nach
Verwendung von Literalen rühren wahrscheinlich dem Refactoring von Gott-Klassen als Antwort6: Das
daher, dass diese in den vorangehenden Vorlesun- ist wie Jenga spielen. Wenn man an der falschen
gen und Übungen nicht thematisiert wurden. In den Stelle was wegnimmt, bricht alles zusammen.
Vorlesungsfolien und beim Anschrieb der Übungs-
6 http://stackoverflow.com/questi-
ons/14870377/how-do-you-refactor-a-god-class
88 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
Das vorliegende Datenmaterial ist zu wenig gig voneinander betrachtet werden und es keine ne-
umfangreich, als dass man vermutete Zusammen- gativen Punkte gibt, haben selbst ganz viele Miss-
hänge, wie „Wenige Klassen führen zu mehr Gott- griffe in einer Kategorie, z. B. bei der Bezeichner-
Klassen.“ oder „Mehr Control-Klassen führen zu wahl, nicht den völligen Verlust aller Punkte zur
mehr Gottklassen.“, belegen könnte. In unseren Bei- Folge. In einer anderen Kategorie kann der Punkte-
spielen sind die Gottklassen in der Regel sehr lang. verlust wieder ausgeglichen werden.
Auch die interessante Frage, ob das MVC-Mus- Im WS14/15 wollen wir Code-Qualität von Be-
ter mit seiner Aufteilung in die Model- und die Con- ginn an stärker thematisieren (siehe Vorgehens-
trol-Schicht die Entstehung von Gott-Klassen be- weise). Die Tutorials zu Clean Code und Refactoring
günstigt, lässt sich (noch) nicht beantworten. Die sind fertig gestellt. PMD steht mit dem SoPra-Regel-
Entwicklung eines Projekts gemäß MVC-Muster werk als Eclipse-Plugin zur Verfügung. Wir hoffen,
ohne Gott-Klassen wird angestrebt und sollte durch- dass die Studierenden damit in der Lage sind, Män-
aus möglich sein. gel zu erkennen, und viele Mängel so beheben kön-
Neben den Fragen danach, warum die Studie- nen.
renden so viele Defekte in ihren Code einbauen und Auch die Gruppenbetreuer sind aufgrund der
wie sie beseitigt oder vermieden werden können, im letzten SoPra durchgeführten Messungen und
stellt sich die Frage, wie die Studierenden auf die der Diskussion der Ergebnisse mehr für das Thema
Kritik reagieren. Viele Studierende zeigen sich Code-Qualität sensibilisiert. Sie müssen den Grup-
durchaus einsichtig und es ergeben sich konstruk- pen dabei helfen, umfassendere Mängel wie poten-
tive Diskussionen, wie man die Defekte hätte ver- tielle Gott-Klassen oder zu lange Parameterlisten
meiden können, z. B. zum Thema große Klassen o- möglichst schon in der Entwurfsphase zu vermei-
der schlechte Bezeichnerwahl. Daneben gibt es kriti- den, indem sie wie wir ein Gespür dafür entwickeln,
sche Anmerkungen von den Studierenden zu den wo sie entstehen könnten.
gewählten Regeln und Grenzwerten, z. B. zur maxi-
malen Länge der Parameterliste und zu sehr kurzen Zusammenfassung
Parameterbezeichnern. Uns ist natürlich klar, dass Wir stellen vor, wie wir das Thema „Code-Qualität“
die Grenzwerte für die Messung relativ willkürlich in der Lehrveranstaltung Software-Praktikum ein-
gewählt sind und dass man darüber diskutieren geführt haben. Dabei gehen wir im Sinne des Blen-
kann. Grundsätzlich begrüßen wir auch diese Dis- ded Learning vor. Aus angeleiteten Lernprozessen
kussionen über das Vorgehen, weil damit unser Ziel, und durch Selbststudium mit Hilfe von im Wiki be-
Sensibilisierung für das Thema Codequalität, er- reitgestellten Unterlagen erarbeiten sich die Studie-
reicht wird. Diskussionen über die Punktevergabe renden das Thema selbst. Wir haben für Anfänger
gibt es nicht. Sie scheint als fair empfunden zu wer- angemessene Aspekte der Code-Qualität und geeig-
den. nete Grenzwerte für die Messinstrumente festgelegt.
Diese Vorbereitungen für ein erfolgreiches Selbst-
Wie geht es weiter? studium stellen wir hier vor. Durch die handlungs-
Die gewählten Grenzwerte haben sich bewährt und orientierte Vermittlung im Rahmen eines Software-
können beibehalten werden. Martin formuliert in Projekts soll den Studierenden die Bedeutung von
[Martin 2008] sehr strenge Qualitätsmaßstäbe, de- Code-Qualität für die Software-Entwicklung leicht
nen selbst erfahrene Entwickler nur schwer genügen verständlich werden.
können. Da wir die Studierenden nicht völlig demo- Durch das ständige Feedback des Tools erfah-
tivieren wollen, haben bewusst erreichbare Ziele ge- ren die Studierenden, wie nahe sie dem Ziel von ho-
setzt. Mit den von uns gewählten Werten haben wir her Code-Qualität bereits gekommen sind und wo
offenbar Grenzwerte gefunden, die die Studieren- noch Mängel bestehen. Den Studierenden wird in
den in den meisten Fällen einhalten und nur selten den Tutorials und in einer Live-Demo von Eclipse
verletzen. gezeigt, wie sie welche Mängel leicht mit welchen
Die Idee, bei der Bewertung von einem Gutha- Refactoringschritten beheben können und wo sie
ben von 10 Punkten bzw. 5 Punkten bei jedem Ver- manuell eingreifen müssen. Durch die Diskussion
stoß einen Punkt abzuziehen, halten wir weiterhin mit den Dozenten und untereinander sollte den Stu-
für didaktisch richtig. Da die Kategorien unabhän- dierenden die Bedeutung der Mängel klar werden.
Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
89
Auf keinen Fall wollen wir die Bewertung zu Lanza, Michele; Marinescu, Radu; Ducasse, Stephan
strikt durchführen, beispielsweise die Vergabe des (2006): Object-oriented metrics in practice,
Scheins von der Einhaltung der Qualitätsgrenzen Springer.
abhängig machen, da wir die Gefahr von adaptivem Martin, R. C. (2008): Clean code: a handbook of agile
Verhalten sehen und verhindern wollen. Der Inhalt, software craftsmanship. Pearson Education.
die Funktionalität des Programms, ist immer noch McCabe, Thomas (1976): A complexity measure. In:
wichtiger als die Form. IEEE Transaction on Software Engineering, Nr.
4, S. 308-320.
Literatur Remmers, J.R. (2014): Clean Code – Code-Qualität
im Software-Praktikum. BA-Arbeit, Fakultät für
Fowler, M. (1999): Refactoring: Improving the De-
Informatik, TU Dortmund.
sign of Existing Code. Addison-Wesley, Rea-
ding, MA. Riel, Arthur J. (1996): Object-oriented design heuris-
tics. Addison-Wesley Publishing Company.
Gamma, Erich; Helm, Richard; Johnson, Ralph E.;
Vlissides, John (2004): Entwurfsmuster. Elemente Schmedding, D. (2011): Teamentwicklung in studen-
wiederverwendbarer objektorientierter Soft- tischen Projekten. Software Engineering im Un-
ware. Addison Wesley, München. terricht der Hochschulen (SEUH) 2011, Mün-
chen.
Spillner, Andreas; Linz, Tilo (2005): Basiswissen
Softwaretest. dpunkt.verlag, Heidelberg.
Anhang A: Bewertungsschema
Kriterium Überprüfung durch Bewertung
Einhaltung der Java-Konventionen bei PMD Max. 10 Punkte, pro Verstoß 1
der Namensgebung Punkt Abzug
Sinnvolle Bezeichner Stichproben, manuell Max. 10 Punkte, pro Verstoß 1
Punkt Abzug
Zeilenlänge der Methoden <= 40 PMD Max. 10 Punkte, pro zu lange Me-
thode 1 Punkt Abzug
Parameteranzahl der Methoden <= 4 PMD Max. 10 Punkte, pro Methode mit
zu vielen Parametern 1 Punkt Ab-
zug
Zyklomatische Komplexität der Me- PMD Max. 10 Punkte, pro Verstoß 1
thoden <= 10 Punkt Abzug
Zeilenlänge der Klassen <= 400 PMD Max. 5 Punkte., pro zu lange Klasse
1 Punkt Abzug
Toter Code PMD Max. 10 Punkte, pro Verstoß ein
Punkt Abzug
Gott-Klasse PMD Max. 10 Punkte, pro gefundene
Gott-Klasse 1 Pkt. Abzug
90 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
Anhang B: SoPra-spezifische Regelmenge
Diese Regelmenge wurde zur Nutzung in der Lehrveranstaltung "SoPra" der TU Dort-
mund erstellt.
Sie besteht ausschließlich aus Standardregeln.
Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015
91