Qualitätssicherung durch Code Inspektion
Einleitung
Warum Qualitätssicherung
Qualitätskriterien
Qualitätssicherung sollte sich durch die ganze Projektlaufzeit (von der Analyse bis zur Wartung) durchziehen. Qualitätssicherung in der Implementierungsphase ist sehr schwierig, falls die Analyse fehlerhaft oder unvollständig durchgeführt wurde. Nichtvorhandene oder lückenhafte Analysedokumente sollten uns aber nicht dazu verleiten, auf Qualitätsicherung während der Implementation zu verzichten.
Der Source Code sollte folgenden Ansprüchen genügen:
Korrektheit und Vollständigkeit sind ohne ordentliche Analysedokumente schlecht nachweisbar und messbar.
Erweiterbarkeit und Wartbarkeit sind oft eine Frage des Programmier und Designstils der erlernbar ist. Die im Anhang angegebene Smalltalk Inspektionsliste, sowie das Werkzeug SmallLint helfen die häufigsten Stilfehler zu vermeiden.
Wiederverwendbarkeit erhält man i.a. nicht ohne extra Zeitaufwand. Am Ende eines Projektes sollte ein erfahrener Mitarbeiter aus dem vorhandenen Code "Software-Werkzeuge" bauen und dokumentieren.
Vorteile von Code Inspektion
Qualitätsmanagement
Wann erfolgt Code Inspektion
Code Inspektion sollte erfolgen:
Was wird inspektiert
Es wird der SourceCode eines Mitarbeiters, sowie die dazugehörige Dokumentation auf die obengenannten Qualitätskriterien überprüft. Die gefundenen Fehler sollten schriftlich festgehalten, und im nächsten Inspektionsprozess nochmals überprüft werden.
Es sollte nicht die Leistung des Mitarbeiters sondern die Qualität des Codes bzw. Dokuments kontrolliert werden. Die Aufgabe der CodeInspektion kann auch sein, neue Mitarbeiter einzuweisen. (z.B vor Urlaubsvertretung).
Eine Inspektion hat nur Sinn, wenn definiert ist, welcher Mitarbeiter für welche Klassen bzw. Applikationen verantwortlich ist.
Wer nimmt an Code Inspektion teil
An einer Code-Inspektion sollten mindestens 2, aber höchstens 5 Mitarbeiter teilnehmen:
Für die Mitarbeitere die den Code verwenden müssen reicht aber oft eine klar definierte Schnittstelle aus.
Der Inspektionsprozeß
Der Autor sollte vor der Inspektion, alle betroffenen Klassen und Applikationen versionieren, und entsprechend kennzeichnen (z.B.: für Review 1.1.0 ). Sollten gleichzeitig mehrere Applikationen getestet werden, kann eine neue ConfigurationMap erzeugt werden.
Fehler bzw. Verbesserungsvorschlaege, die während der Inspektion auftreten, können gleich im Notizenfeld von Envy protokolliert werden. Die gefundenen Fehler sollten in folgende 3 Prioritätsklassen eingeteilt werden:
Klassen und Applikationen sollten nur freigegeben, falls sie keine Fehler vom Typ S und I enthalten.
Die Smalltalk Inspektion Checkliste und SmallLint
Das Software-Werkzeug Smallint analysiert den SourceCode und sucht automatisch nach möglichen Fehlern und Unsauberkeiten. Smalllint ist ein Teil des Refactory-Browsers und schon in unserere Envy Bibliothek vorhanden. Eine genauere Beschreibung des Programms ist in
http://st-www.cs.uiuc.edu/users/brant/Refactory/Lint.html.
Eigene Kommentare zu der Inspektions Checkliste im Anhang:
Zu 1) Modifizierung der Basis-Klassen
Gerade Envy erlaubt es Basis-Klassen in eigenen Applikationen erweitern, und man sollte als Programmierer auch den Mut besitzen, davon Gebrauch zu machen. Allerdings sollte das Verhalten von bekannten Methoden nicht verändert werden.
Zu 2) Das Law of Demeter
Zu Vermeiden sind Ausdrücke der folgenden Form:
self attribute nextAttribut anotherAttr add: anObject.
Sende Nachrichten nur an:
Zu 6,7,11) Kommentare
Klassenkommentare sollten Pflicht sein. Dazu gehört eine Kurzbeschreibung der Klasse. (Wenn man nicht in wenigen Sätzen ausdrücken kann, was die Aufgabe der Klasse ist, so deutet dies auf einen schlechten Design hin). Danach erfolgt eine Beschreibung der Instanz- und Klassenvariablen (Namen der Variable, Welche Werte sie annehmen koennen und Kurzbeschreibung). Sinnvoll ist auch die Beschreibung mit welchen Klassen sie
zusammenarbeiten (Im Sinne von CRC-Cards).
Methodenkommentare sind in den meisten Fällen unnötig , falls die Namen der Methoden und Parameter sinnvoll gewählt sind. Dazu kommt, daß die Länge einer Methode nicht grösser als 10 Zeilen sein soll. Ist eine Methode ohne Kommentar nicht zu verstehen, so deutet es auf einen schlechten Design hin. Trotzdem gilt: Lieber einen Kommentar zuviel als einen Kommentar zuwenig.
Zu 12,13) Gegen Case Statements und Methoden isMemberOf: bzw. isKindOf: hilft oft das folgende Prinzip:
Bsp:
Tabelle<<editiere: aZeile
(aZeile isMemberOf: UeberschriftsZeile ) ifTrue: [ Screen default bell ].
(aZeile isMemberOf: FesterKommentarZeile) ifTrue: [Screnn default bell].
(aZeile isMemberOf: EditierZeile) ifTrue: [ aZeile editiere ].
Besser ist folgende Version
UeberschriftsZeile<< isEditierbar
^false
FesterKommentarZeile<< isEditierbar
^false
EditierZeile<< isEditierbar
^true
Tabelle<<editiere: aZeile
aZeile isEditierbar ifTrue: [ aZeile editiere]
IfFalse: [ Screen default bell].
Zu 16: Benutze Methode become: mit Vorsicht
Mit der Methode become: kann man die internen ObjektId’s zweier Objekte austauschen:
Beispiel: ApplicationWindows allInstances do: [ :each | each become: String new ].
Dies ist ein Beispiel das angewendetet werden kann, falls das Image gewachsen ist, weil die ApplicationWindows nicht sauber aufgelöst wurden. Achtung: Die Methode become: sollte nie innerhalb eines Programms aufgerufen werden, hoechstens für das TroubleShooting in einem unsauberen Image.
Zu 35) Klassen die nil als Oberklassen haben,
Dies ist in Smalltalk durchaus möglich und in äusserst seltenen Fällen durchaus gewollt. Damit wird verhindert, dass ein Objekt Methoden versteht, die in der Klasse Object implementiert sind.
Weiterführende Literatur:
Tips, wie qualitativ guter Smalltalk-Code aussieht sind in:
Anhang 1: Die Smalltalk Insapektion Checkliste aus SmalltalkReposrt Jan/Feb 1998
Die folgende Liste ist auch veröffentlicht unter .
http://www.lineaengineering.com/Resources/Inspection/inspection.html