Inhaltsverzeichnis
10. Code
- Themen
- Ziel der Programmierung: Intellektuelle Beherrschung komplexer Zusammenhänge
- Die Aufgabe von Code: Kommunikation
- Software-Entropie
- Glossar
- Kapitel bei Springer
- https://link.springer.com/chapter/10.1007/978-3-662-71607-6_10
Zentrale Aspekte
- Ziel der Programmierung:
intellektuelle Beherrschung komplexer Zusammenhänge - Programmierer kommunizieren durch ihren Code.
Man kann nicht nicht, nur unzureichend kommunizieren. - Die Qualität von Code nimmt über die Dauer der Entwicklung
eines Projekts meist ab (Software-Entropie). - Die Lösung ist nicht der große Neuentwurf,
sondern die kontinuierliche Verbesserung im Kleinen. - Code-Qualität ist eine Frage der persönlichen Einstellung
und Wertschätzung des Lesers/Nutzers.
Zusammenfassung
Programmierung ist für alle nichttrivialen Probleme ein derart komplexes Unterfangen, dass wir als Menschen damit überfordert sind. Das eine große Ziel der gesamten Softwaretechnik seit der Softwarekrise in den 1960er Jahren war und ist es, Softwareentwicklung intellektuell beherrschbar(er) zu machen. Einen wesentlichen Anteil daran hat die Lesbarkeit des Quellcodes.
Programmierer kommunizieren durch ihren Code. Man kann nicht nicht, nur unzureichend kommunizieren. Wer das versteht und einsieht, dass sie oder er am ehesten den eigenen Code wieder lesen wird, wird versuchen, an der Lesbarkeit zu arbeiten. Codequalität ist letztlich eine Frage der persönlichen Einstellung und Disziplin und der Wertschätzung des Lesers bzw. der Nutzerin.
Erschwerend kommt hinzu: Die Qualität von Code nimmt über die Dauer der Entwicklung eines Projekts meist ab: ein als Software-Entropie bekanntes Phänomen. Die Lösung ist gerade *nicht* der große Neuentwurf, zumal das die Ursache des Problems (unsere Unfähigkeit, sauberen Code zu schreiben) nicht behebt. Nur die kontinuierliche Verbesserung im Kleinen und die eigene in der Praxis gewonnene Erfahrung haben Aussicht auf Erfolg. Das erfordert einmal mehr Problembewusstsein, die Bereitschaft, sich Strategien anzueignen, und die persönliche Disziplin, diese Strategien auch im Alltag einzusetzen.
Codequalität und insbesondere Lesbarkeit ist für wissenschaftliche Software nicht optional, sondern notwendige Voraussetzung für die Wissenschaftlichkeit: Ohne Nachvollziehbarkeit keine Wissenschaft.
Fragen zur Vertiefung und Wiederholung
Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, es werden aber keine Antworten zur Verfügung gestellt.
- Was ist das inhärente Problem jedes größeren Softwareprojekts? Welche Zielstellung ergibt sich daraus für Programmierkonzepte?
- Was ist die primäre Aufgabe von Code (neben der korrekten Ausführung)?
- Nennen Sie drei zentrale Aspekte „sauberen Codes“.
- Welchen Zusammenhang gibt es zwischen „sauberem Code“ und Kriterien der Wissenschaftlichkeit? Warum ist „sauberer Code“ von so großer Bedeutung für die Entwicklung von Software zur wissenschaftlichen Datenverarbeitung?
- Was versteht man unter dem Begriff „Software-Entropie“? Wie unterscheidet er sich grundlegend vom Konzept aus der Thermodynamik?
- Warum ist der große Neuentwurf meist keine Lösung für das Problem der Software-Entropie? Was wäre eine Alternative?
Weiterführende Literatur/Links
Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.
Es gibt viele Bücher, die sich mit Codequalität und seinen diversen Aspekten beschäftigen. Ein Buch, das sich explizit mit sauberem Code befasst, ist „Clean Code“ von Robert C. Martin {[martin-rc-2008]}. Aus einer ähnlichen Perspektive gehen Andrew Hunt und David Thomas in ihrem Buch „The Pragmatic Programmer“ {[hunt-a-1999,thomas-d-2020]} auf diese Aspekte ein. Hierher stammt auch der Verweis auf die „Broken-Window-Theorie“.
Ein sehr umfangreiches Buch, das nicht aus dem Dunstkreis der agilen Methoden kommt, ist Steve McConnells „Code Complete“ {[mcconnell-s-2004]}, mit ca. 1000 Seiten allerdings eher schwergewichtig.
Sehr kurz und knapp und mit einem klaren Fokus auf C, C++ und Java ist „The Practice of Programming“ von Brian Kernighan und Rob Pike {[kernighan-bw-1999]}. Viele gute Hinweise finden sich auch in „The Art of UNIX Programming“ von Eric S. Raymond {[raymond-es-2004]}, hier sicherlich vor dem Hintergrund der UNIX-Programmierung, wie der Buchtitel schon verrät. Gute Hinweise speziell zur Entwicklung von Software in den Naturwissenschaften, die stark auf numerischen Berechnungen basiert, liefert {[oliveira-s-2006]}.
Spezifisch für den Python-Kontext geschrieben und bewusst nicht abwägend, sondern direkt (opinionated) ist „The Hitchhiker's Guide to Python“ {[reitz-k-2016]}. Das entsprechende Kapitel fasst dafür auf sehr knappem Raum viele gute Regeln zusammen. Ebenfalls auf Python bezogen, aber spezifischer und sich an erfahrenere Programmierer richtend sind {[bader-d-2019,slatkin-b-2015]}
Ein Klassiker ist das Buch „The Elements of Programming Style“ von Kernighan und Plaugher {[kernighan-bw-1978]}, das nicht nur mit seinem Titel eine Reminiszenz an „The Elements of Style“ von Strunk und White {[strunk-w-2000]} ist. An diesen beiden Büchern sieht man, dass Klarheit im Ausdruck und guter Stil zeitlos und unabhängig von der konkreten (Programmier-)Sprache sind – und die wesentlichen Zutaten bereits vor Jahrzehnten bekannt waren. Der Strunk&White wird in der Python-Gemeinde als Referenz für die sprachliche Qualität von Kommentaren herangezogen.
Darüber hinaus gibt es viele hilfreiche andere Bücher. Nichtnennung bedeutet nicht, dass sie schlechter, sondern ggf. nur, dass sie dem Autor nicht bekannt sind.
<bibtex bibliography> sort=true </bibtex>
Gründe für Refactoring und gegen das Neuschreiben
Joel Spolski, u.a. Mitgründer der Plattform Stack Overflow, hat im Jahr 2000 in einem Artikel mit dem Titel Things You Should Never Do, Part I beschrieben, welchen Fehler Netscape machte - nämlich die komplette Code-Basis wegzuwerfen und neu zu schreiben -, was mit drei Jahren Stillstand und einem vollkommenen Verschwinden des vorher führenden Webbrowsers endete.
