Hallo, ich liebe gute Software und guten Kaffee.
Ich heiße Manfred Sprenzel. Wenn Sie wissen wollen, wie man richtig gute Software schreibt, dann sind Sie hier richtig. Ich bin Programmierer und von mir erhalten Sie in diesem Blog Informationen, durch die sich Ihr künftiges Berufsleben ändern kann.
Wenn Sie hier Lösungen für konkrete technische Probleme mit ellenlangen Code-Beispielen suchen, dann sind Sie im falschen Blog. Wenn Sie wissen wollen, wie man guten Kaffee macht, dann ist das leider auch nicht der richtige Blog für Sie.
Mein Ziel ist es, guten Programmierern dabei zu helfen, noch professioneller und noch besser zu werden.
Das Wort „Programmierer“ drückt in der deutschen Sprache gut aus, dass diese Arbeit eine Handwerkskunst ist. Seien wir ehrlich: Wir Softwareentwickler sind Handwerker, wie übrigens Zahnärzte oder Chirurgen auch. Diese These vertrat ich lange schon bevor es die Software Craftsmanship Bewegung gab. Echte Professionalität im eigenen Handwerk lernt man am besten von anderen Handwerkern, die ebenfalls professionell arbeiten. Im Handwerk lernen die Jungen von den Alten.
Das Ergebnis von unfachmännischer Programmierung ist schlechter Programmcode. Ich habe schlechten Code in jeder Facette gesehen.
Der schlimmste Programmcode, den ich jemals zu sehen bekam, stammt von einem sehr „jungen Team“, einem Team ohne alte Hasen – alle frisch von der Uni. Der Jugendwahn, der in den 2000er Jahren vor allem in Deutschland grassierte, bescherte uns jede Menge schlechten Legacy-Code, der uns noch heute beschäftigt. Besteht ein Team nur aus Älteren, dann ist es genauso schlecht. Die Alten schmoren irgendwann nur noch in ihrem eigenen Saft. Ein Team sollte daher immer altersgemischt sein.
Die Software mag für den Anwender durchaus akzeptabel funktionieren. Für einen Entwickler ist Code jedoch genau dann schlecht, wenn er nicht schnell und einfach zu verändern ist. Es kann sein, dass die Anforderungen sich geändert haben oder dass Fehler gefixt werden müssen. Wenn Code zu verworren und kompliziert ist und es weder Unit- noch Regressionstests gibt, dann ist dies nicht mehr ohne großen Aufwand möglich.
Wie jeder andere, mag ich es nicht, wenn Software nicht das macht was sie soll, oder wenn sie fehlerhaft ist, oder wenn sie gar Schaden anrichtet. In Abwandlung des angeblichen Zitats von Winston Churchill behaupte ich: „Traue keiner Software, die Du nicht selbst entwickelt hast.“ Das folgende kann passieren, wenn man sich nicht daran hält:
Während des zweiten Praxissemesters in meinem Studium, war ich bei einer Firma beschäftigt, die eine Branchen-Software für Apotheken herstellte. Stolz, erzählten mir damals die Verantwortlichen, dass sie regelmäßig Sicherungskopien ihres Source Codes machen und welch ausgeklügelte System von Zeitintervallen zur Aufbewahrung und Löschung der Backups sie dabei einsetzen würden. Irgendwann war es dann soweit. Ein lautes klirrendes Geräusch und die Feststplatte des Server war kaputt. Was dann folgte war eine Katastrophe. Das Wiederherstellen war nicht mehr möglich. Die Backup-Software hatte einen Fehler. Die Software schrieb zwar brav ihre Protokolle aber in den gespeicherten Daten war nur Müll. Es war nichts mehr zu machen. Der Hersteller der Backup-Software entschuldigte sich und erstattete den Kaufpreis zurück. Zum Glück konnte man mit viel Mühe die Stuation doch noch retten. Mithilfe von diversen Quelltext-Versionen, die verteilt auf verschiedenen Rechnern herumlagen, konnte man innerhalb von einigen Tagen wieder eine vollständige Quelltext-Version zusammenstückeln.
Andere Firmen hätten vielleicht nicht so gehandelt. Statt sich mit der Erstattung des Kaufpreises zufrieden zu geben, hätten sie Rechtsanwälten eine Freude bereitet.
Code Smells, schlechten Code rieche ich mittlerweile von weitem.
Ich weiß aus der Praxis aber auch wie guter Code aussieht, wie er sich anfühlt und wie er riecht. Ja, es gibt ihn, den einfachen, klaren Clean Code, der gut getestet ist und exakt das tut, was er soll. Wie bei einer beruhigenden Melodie, darf man hier keine störenden Dissonanzen hinterlassen. Es ist meist Unwissenheit, die vieles zerstört. Aus dem gleichen Grund, aus dem man ganz kleinen Kindern keine lebendigen Haustiere in die Hände gibt, sollten Sie als Projektmanager oder Produkt-Owner Ihren Quelltext auch nicht unerfahrenen Programmierern anvertrauen. Zumindest nicht unbeaufsichtigt, also nicht ohne Review von erfahrenen Entwicklern.
Eigentlich mag ich das Wort „Clean Code“ nicht. Ich benutze es nur wegen seines Bekanntheitsgrades. Es hört sich für mich zu sehr nach Waschmittelreklame an, nach Selbstzweck und einem Spleen von Uncle Bob. Ich bevorzuge den Begriff „nachhaltige Softwareentwicklung“, der bereits den Werterhalt des Quelltextes als Zweck enthält. Wenn Sie wissen wollen warum nachhaltiger Code der bessere Clean Code ist, dann lesen Sie meinen ersten Blogbeitrag.
Mein Berufsleben
Noch ein paar Worte zu meinem Lebenslauf. Ich bin Jahrgang 1960. Nach dem Abitur mit Mathe und BWL-Leistungskurs begann ich zunächst mit einem Soziologie- und Philosophie-Studium. Über die Soziologie kam ich zur Statistik und lernte das Statistikprogramm SPSS kennen. Die Daten wurden damals von einem Siemens Prozessrechner verarbeitet, den wir als Studenten noch mit Lochkarten fütterten. SPSS war programmierbar, es hatte seine eigene Makro-Sprache, und so entdeckte ich meine Leidenschaft für das Programmieren.
Am Universitätsrechenzentrum in Heidelberg, konnte man verschiedene EDV-Seminare besuchen. So lernte ich die Programmiersprache Pascal. Programmieren musste man sich zu jener Zeit etwa so vorstellen: Man tippte seinen Code an einem Terminal in einen zeilenorientierten Editor. Zum Kompilieren und Linken musste ein selbstgeschriebenes JCL-Script ausgeführt werden. Danach musste man ca. eine Stunde warten, bis das eigene Listing im Druckerraum abholbereit war. Nur dadurch erhielt man einen Report über die Syntaxfehler. Programmieren war damals wirklich eine sehr mühselige Angelegenheit.
Zusammen mit zwei Freunden gründete ich noch während dieses Studiums eine Firma. Ich lernte zu dieser Zeit auch das Programmieren mit Turbo-Pascal, welches auf einem CP/M-Rechner lief. Wir tauften diesen Computer wegen seines knallroten Gehäuses liebevoll „RedBaron“. Wenig später begann das Zeitalter der sogenannten IBM-kompatiblen PCs. Wir importierten Spezial-Software für PCs unter anderem auch SPSS aus den USA. Wegen meiner späten Einberufung zum Zivildienst musste ich dann aber die Selbständigkeit beenden.
Danach folgte ein Informatik-Studium. Während und nach des Studiums arbeitete ich auch als Programmierer. Es wurde die Programmiersprache C eingesetzt. Die Programme liefen auf dem Betriebssystem OS/2 von IBM, welches bereits eine grafische Benutzeroberfläche mit echtem Multitasking hatte. Diese OS/2-Version war bereits ein 32-Bit Betriebssystem, das die Leistung des 80386-Prozessors voll ausnutzen konnte. Es gab also keine Speicherbegrenzung auf 640 KB wie beim sonst üblichen MS-DOS.
Während der Zeit als Steve Jobs, der bei Apple rausgeschmissen wurde, und er zusammen mit seinem Kumpel Steve Wozniak das Unternehmen NeXT-Computer aufbaute, schrieb ich Programme für diese Rechner (NeXTcube und NeXTstation). Sie hatten das UNIX-Betriebssystem NeXTStep und es gab einen revolutionär neuen Ansatz beim Programmieren: Eine objektorientierte grafische Entwicklungsumgebung mit der Programmiersprache Objective-C. Die GUI konnte man mit der Maus zusammenklicken und durch ziehen mit der Maus konnte man die Felder von der Oberfläche mit der Datenbank verbinden. Der Zeitaufwand für das Schreiben von Programmen und die Fehlerquote reduzierten sich drastisch.
Kurz dannach kam die Entwicklungsumgebung Delphi 1 auf den Markt und ich begann, als einer der Ersten damit zu arbeiten. Was für ein Rückschritt! Damit meine ich nicht Delphi. Das Konzept von Delphi ähnelte in jedem Detail dem von NeXT. Delphi war ein enormer Fortschritt gegenüber Boland Pascal 7.0. Der technische Rückschritt war das darunter liegende Windows Betriebssystem von Microsoft. Kein echtes Multitasking und nur 16 Bit Adressraum, wodurch Datenstrukturen auf eine maximale Länge von 64 KB beschränkt waren. Das war damals schon winzig.
Obwohl ich nebenbei auch andere Programmiersprachen kennengelernt habe, und obwohl Delphi jede Menge Fehler hat, bin ich dieser Entwicklungsumgebung treu geblieben.
Zuletzt lernte ich Test Driven Development (TDD) und damit auch Clean Code kennen. Das war für mich nach der objektorientierter Programmierung der zweite Paradigmenwechsel. Ich war begeistert und enorm motiviert mehr davon zu erfahren. Leider musste ich feststellen, dass nicht jeder, der TDD bereits ausprobierte auch genauso begeistert war wie ich. OK, ich war ja auch anfänglich skeptisch gegenüber OO. Damals glaubte ich kurzeitig, das sei eine Mode, die wieder vorüber geht. Bei TDD ist das jedoch etwas anderes. Jemand, der OO falsch einsetzt, landet letztlich wieder bei der strukturierten Programmierung und hat somit keine Nachteile gegenüber dem vorherigen Programmierstil. Dagegen hat jemand der TDD falsch einsetzt oftmals nur Nachteile. Man verzettelt sich und ist schließlich davon überzeugt, dass TDD nur ein einziger Zeitfresser sei.
Ich hoffe, dass ich mit diesem Blog dazu beitragen kann, dass sich TDD besser durchsetzt.
Gerne dürfen Sie mir auch eine Mail schreiben: manfred.sprenzel@software-sunshine-blog.de
