Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:
Heute, am 1. Februar 2009, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:
Die Forderung nach Softwarequalität
So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:
Den Begriff Softwarequalität zu definieren, ist keine große Herausforderung. Qualität ist bei einem Softwareprodukt dann gegeben, wenn die Software nicht nur ihre funktionalen, sondern auch ihre nicht-funktionalen Anforderungen ausreichend erfüllt. Je höher diese Anforderungen gelegt werden, desto besser die Qualität.
Wie wichtig das Thema ist, hat bereits im November 2007 die dotnetpro mit ihrer Konzeptkonferenz prio bewiesen, als sie den Begriff Softwarequalität als Leitthema für die Konferenz gewählt hat.
Außerdem kennt man die Forderung nach Softwarequalität so wohl von Entwicklern wie auch von Managern – in fast jeder Softwarefirma spielt dieses Thema eine gewichtige Rolle.
Man könnte meinen, dass ein Thema, dass zum einen von so großer Bedeutung und zum anderen auch von so vielen gefordert wird, nicht nur ausreichend erforscht, sondern vor allem auch mehr als ausreichend gelebt wird. Leider ist in der Praxis häufig weder das eine noch das andere der Fall.
Das Paradoxe an Softwarequalität ist nämlich, dass sie gleichzeitig Geld und Zeit kostet, aber auch Geld und Zeit spart: Wird während der Entwicklung bereits auf die Einhaltung gewisser Qualitätsregeln geachtet, ist das natürlich aufwändiger, als wenn dies nicht geschieht.
Leider wird die Argumentation in der Praxis häufig an dieser Stelle beendet, denn sobald Auslieferungstermine oder Kosten die Entwicklung beeinträchtigen könnten, wird in der Regel als erstes an der Qualität gespart, denn der Code könnte zu einem späteren Zeitpunkt noch überarbeitet werden.
Das Problem ist nur: Dieser Zeitpunkt wird so gut wie nie erreicht. Denn nach der Auslieferung der Software beginnen zumeist die Arbeiten an der nächsten Version – Zeit, die vorherige erst noch zu bereinigen, findet sich nicht.
Vordergründig mag dieses Vorgehen auch in Ordnung sein, denn auf den ersten Blick funktioniert alles, und es wurden sogar Zeit und Geld gespart. Zugleich wird akzeptiert, dass der ausgelieferte Code nicht fehlerfrei ist, weshalb später Zeit in die Behebung von Bugs fließen muss. Doch genau an dieser Stelle liegt der Hund begraben.
Auch und sogar speziell in der Informatik gilt: Je später ein Fehler behoben wird, desto teurer ist seine Behebung (warum das so ist, habe ich vor einigen Monaten bereits in dem Eintrag Architektur = Planen + Entwurfsmuster erläutert). Genau an dieser Stelle kostet die Entwicklung dann nämlich wiederum übermäßig viel Zeit und Geld: Es handelt sich also um einen dieser typischen Fälle, in denen sich Dinge desto stärker rächen, je mehr man sie hinausschiebt.
Hat man diese Problematik erst einmal erkannt, akzeptiert und beschlossen, etwas zu unternehmen, stellt sich die Frage, was genau man denn eigentlich machen könnte. Hierzu gibt es meiner Meinung nach in jeder Phase der Entwicklung ausreichend Möglichkeiten, aktiv zu werden – selbst, wenn man in der Firma ansonsten nicht wirklich etwas zu sagen hat: Getting Things Done When You’re Only a Grunt.
In der Anforderungsphase kann man als Entwickler zwar die eigentlichen Anforderungen nicht oder nur kaum beeinflussen, aber man hat die Möglichkeit, eigene Aufwandsabschätzungen durchzuführen und darauf hinzuweisen, dass ein bestimmtes Feature eventuell nicht so schnell umgesetzt werden kann, wie es der Kunde gerne hätte.
Eine meiner Meinung nach ausgezeichnete Methode, wie man Aufwände überhaupt schätzen kann, ist das sogenannte Evidence Based Scheduling. Neben der Beschreibung der eigentlichen Methode enthält diese Webseite auch Tipps, wie man dem eigenen Zeitplan die Aufmerksamkeit verschafft, die er verdient hat.
In der Designphase kann ein Entwickler dann mitreden, wenn er sich nicht nur als einfacher Programmierer sieht, sondern sich auch aktiv mit dem Thema Softwarearchitektur auseinandersetzt. An dieser Stelle zeigt sich der essenzielle Unterschied zwischen Programmierern, Entwicklern und Architekten:
Während sich die Programmierung mit dem reinen Was auseinandersetzt, beschäftigt sich Architektur mit dem Wie. Und die Schnittstelle zwischen beidem - quasi die architekturbewusste Programmierung - ist die Entwicklung.
Den größten Einfluss hat ein Entwickler selbstverständlich auf die Entwicklungsphase einer Software, denn dies ist die Phase, mit der er selbst die meiste Zeit zubringt, und in der er sich am besten auskennt. Doch auch hier wissen viele Entwickler nicht recht, wie sie vorgehen sollen, um die Qualität ihres Codes zu verbessern (mir selbst ging es vor einigen Jahren ebenso).
Obwohl es kein Patentrezept für die Verbesserung der Qualität des eigenen Codes gibt, haben sich in der Praxis doch einige Vorgehensweisen als sinnvoll erwiesen, die ich im Folgenden noch ein bisschen näher beschreiben möchte:
- Coderichtlinien: Der Einsatz von Coderichtlinien hilft, konsistenten Code zu schreiben, was nicht nur im Team sinnvoll ist. Auch als Einzelkämpfer profitiert man von solchen Richtlinien, denn man beginnt, sich aktiv mit dem Code auseinanderzusetzen, was zu mehr Disziplin während der Entwicklung führt Speziell zu .NET hat Microsoft in der MSDN zahlreiche Coderichtlinien veröffentlicht – angefangen bei Namensgebung über Klassendesign bis hin zu Best Practices, wie gewisse Konstrukte in .NET optimal eingesetzt werden. Ein ausgesprochen gutes und sehr empfehlenswertes Buch zu dem Thema ist Framework Design Guidelines, zu dem ich im Dezember 2008 einen Review geschrieben habe.
- Werkzeuge: Coderichtlinien nützen nur dann etwas, wenn sie eingehalten werden. Außerdem stellt sich immer die Frage, welche Richtlinien man befolgen sollte und welche nicht. Aus Gründen der Kompatibilität zu anderen Entwicklern und auf Grund ihrer Konsistenz bietet es sich an, sich an die von Microsoft gegebenen Richtlinien zu halten. Visual Studio hilft hierbei schon ein wenig, indem es beispielsweise die Codeformatierung weitestgehend automatisch durchführt. Dennoch ist es hilfreich, ein dediziertes Programm zu nutzen, wobei hier an erster Stelle FxCop zu nennen ist. Der Einsatz von FxCop kann zunächst sehr frustrierend sein, nimmt man die Warnungen dieses Werkzeugs jedoch ernst und beschäftigt sich vor allem mit den Begründungen der Warnungen, dann lernt man im Lauf der Zeit, gewisse Regeln zu beachten.
- Unittests: Codequalität zeichnet sich nicht nur durch formal ausgezeichneten Code aus, sondern auch dadurch, dass Code über die Zeit funktional stabil bleibt – sprich, dass sich seine Semantik nicht unabsichtlich verändert, weil Seiteneffekte unerwartete Auswirkungen haben: Dies kann zu guten Teilen mit Unittests sichergestellt werden. Dazu empfiehlt sich der Einsatz eines entsprechenden Testframeworks wie beispielsweise MBUnit, und zusätzlich die Beschäftigung mit mindestens einem Teststil, wie beispielsweise TDD oder BDD. Interessant ist, dass sich diese beiden nicht gegenseitig ausschließen, sondern sich sogar gegebenenfalls wunderbar ergänzen können.
- Code Reviews: Vier Augen sehen bekanntlich mehr als zwei. Deshalb ist es fast immer hilfreich, eigenen Code noch einmal von einem zweiten Entwickler auf Schwachstellen überprüfen zu lassen. Hierzu sind weder spezielle Werkzeuge noch eine besondere Vorgehensweise notwendig – ein einfacher Austausch per E-Mail über den Code genügt im einfachsten Fall bereits.
- Pair Programming: Pair Programming ist das Konzept der Code Reviews auf die Spitze getrieben. Man reviewed Code nicht nur gemeinsam, sondern man schreibt ihn direkt gemeinsam. Pair Programming ist eines der Kernkonzepte des sogenannten Extreme Programmings und bedeutet schlussendlich, dass zwei Entwickler gemeinsam vor einem Computer arbeiten – der eine entwickelt, der andere denkt aktiv mit und macht gegebenenfalls Verbesserungsvorschläge oder hinterfragt den geschriebenen Code. Das typische Argument gegen Pair Programming ist, dass zwei Entwickler gemeinsam nicht so viel Code schreiben wie ein Entwickler alleine. Rein an der Zeilenanzahl gemessen, stimmt das – die Qualität ist jedoch um Längen besser, und es gibt auf Grund der gegenseitigen Motivation weniger Leerlauf, was sich letzten Endes in weniger Zeitaufwand niederschlägt.
- Architektur: Dass die Beschäftigung mit Softwarearchitektur ausgesprochen lohnend für eine Verbesserung der eigenen Codequalität sein kann, habe ich bereits angesprochen. Da die Frage, wie man als Entwickler denn einen Einstieg in das Thema Architektur finden, häufig gestellt wird, sei an dieser Stelle noch einmal explizit auf meinen Eintrag Architektur lernen hingewiesen.
Das Schöne an diesen Punkten ist, dass man sie größtenteils sogar in eigener Initiative durchführen kann – selbst, wenn die eigene Firma diese nicht explizit fordert oder unterstützt.
In diesem Sinne: Auf geht’s!