Softwarequalität
Es folgen alle Einträge mit dem Schlagwort Softwarequalität.
Du kannst den RSS-Feed dieses Schlagwortes abonnieren.
Cocoa beinhaltet eine kleine Unit Tests Suite, die für Cocoa Touch leider (noch) fehlt, da viele Abhängigkeiten der Unit Test Suite – z.B. CoreData – im iPhone SDK nicht verfügbar sind. Glücklicherweise gibt es bei Google Code ein Projekt namens Google Toolbox for Mac, welches unter anderem auch Unit-Test-Funktionalität anbietet.
Irgendwie hat es etwas Skurriles, dass ausgerechnet Google, welche dank Android im Smartphone-Bereich eine gewisse Konkurrenz für Apple geworden sind, Funktionalität für das iPhone SDK anbieten, bevor Apple es tut.
Ich stehe Software Metriken ja eher kritisch gegenüber. Zum einen wegen des breiten Interpretationsspielraumes – ein allgemeines Problem von Statistiken – zum anderen, weil es keinen wirklichen Konsens über eindeutige Qualitätsmerkmale von Software gibt, die auch noch pragmatisch vernünftig, also ohne enormen Aufwand zu ermitteln sind. Man sollte vorsichtig sein, wenn man sich von Metriken leiten lassen will.
Man braucht sie aber trotzdem. Weniger für den Entwickler, als vielmehr für den Kunden.
Ein großes Problem für Kunden von Softwareentwicklern, die selbst nicht vom Fach kommen, ist die Bewertung der Qualität von Software. Gerade Laien kann man wirklich jeden Mist unterjubeln, ohne dass sie die Möglichkeit haben, die Qualität zu verifizieren. Bei einem Haus z.B. kann man als Bauherr wenigstens hingehen und daran rütteln, um seine Stabilität zu untersuchen. Bei einem immateriellen Produkt wie Software ist das weitaus schwieriger.
Einfache Software-Metriken könnten da vielleicht ein wenig Abhilfe leisten. Zumindest könnten sie die Wahrnehmung des Themas beim Kunden schärfen.
Bestes Beispiel sind die Produkte von Webentwicklern, deren Qualität mit “minderwertig” viel zu oft noch schmeichelhaft beschrieben ist – sogar wenn man sich Websites großer Firmen anschaut. Technische Qualität, Usability, Validität. Man will nicht wissen, ob und wenn doch wo die Enwickler ihr Handwerk gelernt haben.
Gestern z.B. habe ich mich über praktisch alle Websites bekannter, Deutscher Automobilhersteller aufgeregt. Heute bin ich über dieses, wirklich gruseliges Beispiel gestolpert.
Das ist einfach nur unfassbare Inkompetenz. Das ist so, als würde BMW seine Bremsblöcke von einem Kaugummi-Hersteller beziehen.
Wo wir schon beim Thema sind:
Quelle: Focus Shift
Writing applications without tests makes you a bad person, incapable of love.
Schreibt Obie Fernandez in seinem Buch “The Rails Way”.
Natürlich hat er Recht. Man muss schon wirklich eine bößartige Natur haben, ungetesteten Code ins Repository zu commiten und damit dem Rest des Teams, das auf das definierte Verhalten fremden Codes vertraut, den Feierabend zu versauen.
Komischerweise testet trotzdem niemand. Ich habe für einen Vortrag über Software Metriken für Ruby ein Open Source Rails-Projekt gesucht, das ich für die Demo von metric_fu verwenden kann. Und ich habe kein einziges mit anständigen Tests für die Code-Coverage-Metrik gefunden. Die von Rails automatisch angelegten Tests-Skeletons sollten per Default fehlschlagen, bis der Entwickler sie mit sinnvollem Testcode füllt. Sonst kümmert sich scheinbar eh niemand drum.
All you need is love.
Es kann sehr nervig sein, fremden Code zu verstehen. Gerade wenn es so übelst schwül ist, wie heute. Den Autor dieses Codes sollte man seine eigene Tastatur fressen lassen (ohne Salz oder Ketchup):
protected void verifyAntwortB(){
timerZeit.stop();
String tmpsa1[]=new String[4];
String tmpsa2[]=actQuiz.getFrage().getAntworten();
int tmpi;
for(int i=0;i<4;i++){
tmpi=((Integer)antworten.get(i)).intValue();
tmpsa1[i]=tmpsa2[tmpi];
}
boolean tmpb=actQuiz.verifyAntwort(tmpsa1,phasenZeit);
guiQuizSpielen.showErgebnis();
if(tmpb)guiQuizSpielen.updateErgebnis("Rrichtig!");
else guiQuizSpielen.updateErgebnis("Falsch!");
}
Schon der Methodenname ist absurd. Das Vermischen von Englisch und Deutsch ärgert bei gutem Willen erstmal nur die sprachliche Ästhetik. Das “B” im Methodennamen ist hingegen völlig bescheuert: es soll nämlich nicht bedeuten, dass hier die Antwort B (und nicht etwa Antwort A, oder Antwort C) verifiziert wird, sondern dass die Methode eine zur Methode “verifyAntwort()” verwandte neue Methode ist.
Und sich aus tmpsa1 ein “Temporary String Array Nr. 1″ zu denken, bringt im folgenden das weitere Verständnis auch nicht wirklich weiter. Die Namensgebung der GUI-Elemente schlägt alles. Sie wurden nicht nach ihrer Funktion, sondern nach ihrem Index in der View-Hierarchie benannt – actbut_2_4_2 z.B.
Wo zum Geier bekommt man so was beigebracht?
![[blogoscoop]](http://stats.blogoscoop.net/1167/4.gif){kind=small}
