Schlaues zur Softwarequalität

Standard

Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don’t buy a new scale; change your diet. If you want to improve your software, don’t test more; develop better.

auch wieder von Steve McConell aus Code Complete

Advertisements

Clean Code Zitat

Standard

Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‚How can I improve the code so that this comment isn’t needed?‘ Improve the code and then document it to make it even clearer.

Steve McConell

aus Code Complete (ein wirklich empfehlenswertes Werk für Softwareentwickler)

Über die Kunst Software anwendergerecht zu testen

Standard
Es gibt sie, die Anwender mit den „goldenen“ Fingern. Alles ist fertig. Die Software ist getestet und abgenommen. Dann passiert’s. Die Anwender klagen über Fehler. Der Kundenbetreuer ist verzweifelt, der Projektleiter wütend über die Entwickler, die Entwickler verstehen das nicht. Geht doch alles.
Woran liegt’s, das ist hier die Frage.
Oder doch nicht? Lag’s nur am Softwareerstellungsprozess?
Muss: der Anwender-Stakeholder beschreibt vor Beginn der Implementierung zusammen mit dem Softwareprojektleiter was rauskommen soll. D.h., Anwenderprozess, Use cases. Was soll an Bedienung möglich sein, was nicht. Der Softwareprojektleiter achtet auf das „Außenherum“ und macht den Stakeholder auf Abhängigkeiten und Einschränkungen aufmerksam.
Muss: der Softwareprojektleiter gibt dem Entwickler die Beschreibung weiter, ergänzt und erläutert diese. Weißt auf Abhängigkeiten hin. Prüft, ob der Entwickler das verstanden hat. Er definiert Tests, die eine Verifikation der Realisierung der neuen Anforderung zulassen.
Muss: Code review mit einem erfahrenen Entwickler. Der Ersteller des neuen Codes erklärt, was dieser tun soll.
No go: der Entwickler checkt sein Werk ein. Es compiliert ja.
Muss: der Entwickler testet, dass das, was er entwickelt hat, prinzipiell geht.
Herausforderung: Automatisierung von Tests zur Minimierung des Aufwandes und für Nachvollziehbarkeit. Interne Algorithmik gerne mit Unit Tests. Die müssen allerdings vor der Implementierung geschrieben sein und auch verifiziert werden. Sonst nutzen sie dem Entwickler nichts. Anwenderprozesse, schwierig. Aufgezeichnet über Makros. Zwar nachvollziehbar, aber sie können nicht die Umgebung und die Kreativität von Anwendern abbilden. Daher aufwendig und weniger brauchbar.
No go: nur der Entwickler testet. Denn, der weiß, welche Algorithmik er programmiert hat und deshalb testet er nur auch den Weg, der funktioniert.
Muss: Test durch einen Softwaretester. Der Projektleiter erklärt die Anforderung und die Use Cases, sowie die Abhängigkeiten und in welchen Prozess beim Kunden das Ganze eingebettet ist. Ebenso übergibt er die Liste der definierten Tests. Der Softwaretester verifiziert an Hand der Tests und muss dann in einem begrenzten Zeitraum versuchen, mögliches und unmögliches zu tun, um Fehler zu provozieren. Alles sollte nachvollziehbar dokumentiert werden.
No go: Damit wird die Software für die produktive Umgebung freigegeben.
Muss: Anwendertest mit echten Endkundenanwendern auf einem Testsystem. Beurteilung der Bedienbarkeit und testen durch ganz normales Arbeiten.
No go: Anwender testen nicht, weil zu mühsam, keine Zeit, keine Lust, eh unnötig.
Muss: alle Beteiligen (Stakeholder, testende Key User, Projektleiter Softwaretester) müssen aus ihrer Sicht das Go geben.
Ergebnis: einen Monat später Fehlermeldung durch Anwender im fernen Timbuktu. Feststellung Daten korrupt. Nicht erklärbar, oder doch. Andere Länder, andere Denkweisen. Wurde leider nicht in den Key User Test einbezogen. Hat ganz andere Vorgehensweise. Wurde im Test nie überprüft und genau da sitzt der Bug.

Software lebt ständig

Standard
Sei es während der Entwicklung oder später im Pflegezyklus, einmal entworfener und geschriebener Code ist einem ständigen Wandel unterworfen.
Eine gute Software sollte ja schließlich
  • lesbar sein
  • übersichtlich
  • verständlich und nachvollziehbar
  • erweiterbar
  • auf jeden Fall Redundanzen vermeiden
  • und testbar sein.
Schon in der Entwurfsphase wird der Code einem ständigen Refactoring unterzogen. Allein schon wegen der Lesbarkeit werden Funktions- und Variablennamen umbenannt, wenn sich Sinn und Zweck geändert haben. Schließlich ist die Erstellung von lesbarem Code, der die Wartung erleichtert, das Ziel. Da kein Spaghetticode erstellt werden soll, wird weiter in aufrufbare Funktionen verfeinert. Mehrfachprogrammierung der gleichen Funktionalität ist verboten.
Ähnlich der Modellierung von Prozessabläufen ändert sich ständig der Verfeinerungsgrad. Wie beim Verfeinern von Prozessen werden neue Ausführungsebenen in den Code eingezogen.
Jede Änderung sollte auch mit einem kurzen Inlinekommentar versehen werden. Ebenso sollten anhand von Kommentaren die Abläufe nachvollziehbar sein. Da sich die Software jedoch im Entstehungsprozess ändert, bitte auch die Kommentare nachführen.
Gleichzeitig sollte die Anforderunge(en) so umgesetzt werden, dass zukünftige Änderungen nur lokale Auswirkungen haben und keine anderen Funktionalitäten des Softwarepakets davon betroffen sind. Auch deshalb ist ein ständiger Wandel bei der Realisierung erforderlich.
Zum Abschluss der Realisierung, nach dem erfolgreichen Test, sollten auch alle auskommentierten Codezeilen, die man vorsorglich im Code belassen hat entfernt werden. Das erleichtert später bei der Wartung die Übersicht ungemein.
In der Wartungsphase, bei der Fehlersuche, erkennt man oft Codestellen, die man in eigene Funktionen ausgliedern kann, um die Lesbarkeit zu erhöhen, evtl. um sehr ähnliche, mehrfach verwendete Codezeilen in einer Funktion zu kapseln, damit das Gleiche nur noch an einer Stelle gemacht und somit die Wiederverwendbarkeit des Codes erhöht wird.
Wird die Funktionalität nachträglich erweitert oder geändert, kann es wiederum Sinn machen, vorhandene Variablen und Funktionen umzubenennen. Nichts ist schlimmer, als wenn Code mit der Zeit eine andere Bedeutung bekommt und man sich aufgrund von Benamungen nicht mehr zurecht findet.
Aus Erfahrung kann ich nur sagen, dass man sich an die Regeln halten sollte, die einmal geschriebenen Code auch noch nach Jahren verbessern können. Denn, nichts ist schlimmer als schlecht strukturierten und inline dokumentierten Code Ewigkeiten nach der Entstehung warten und Fehler korrigieren zu müssen.

Software … ein gutes Stück Handwerk

Standard
Immer noch hat der Softwerker den Geruch des Nerds, des freien Künstlers, des Geistesarbeiters, desjenigen, der nie eine Aussage treffen wird, wann eine gestellte Aufgabe denn fertig sein wird.
Doch das hat sich gewandelt und wandelt sich immer weiter.
Softwerker sind immer mehr spezialisierte Handwerker, die ihre Werkzeuge gut kennen müssen, die die Bereiche verstehen müssen in denen SIe arbeiten, die eine Aufgabe selbständig abklären und einfach abarbeiten können müssen.
Der selbstverliebte Programmierer, der der sich nur um seinen Code kümmern und nicht die zu lösende Aufgabe verstehen will und damit keine Verantwortung für eine gute Anwenderlösung übernehmen will, der ist out.
Viele der in Programmen versteckten Fehler, viele Misserfolge von Softwareentwicklungen sind, meiner Meinung nach, darauf zurückzuführen, dass etwas spezifiziert und einfach auch so umgesetzt wurde, wie die einzelnen Realisierungshäppchen spezifiziert waren. Aber Spezifikateure machen auch Fehler, bedenken nicht alles und sehen manche Randaspekte nicht, die sich erst bei der eigentlichen Softwarerealisierung ergeben. An dieser Stelle ist der Softwerker gefordert. Wenn ihm etwas auffällt, das  er nicht versteht, hat er nachzufragen, abzuklären, eigenständig einen Vorschlag zu machen.
Ein Softwerker erfasst die Aufgabe. Beschreibt vor dem Tun seine Vorgehensweise, kommentiert seinen Code, verwendet eine Quellcodeversionierung, dokumentiert die Abläufe der entstandenen Funktion. Und, ganz wichtig, er ist kein einsamer Wolf, er kommuniziert mit dem Team und trifft Entscheidungen zusammen mit dem Team.
Zumindest bei einer Firmengröße wie der unsrigen, mit den komplexen Aufgabenstellungen, die wir haben, ist die Grundeinstellung, ein Handwerker, ein Softwareingenieur zu sein, unabdingbar für den Erfolg unserer Projekte.
Und so ist es nicht verwunderlich, dass es, ähnlich den Handwerkskammern, auch eine Vereinigung von handwerklich guten Softwerkern, die Softwerkskammer, gibt. https://www.softwerkskammer.org