weniger schlecht programmieren.

esel

Bei der Lektüre von Weniger schlecht programmieren von Kathrin Passig und Johannes Jander hat mich immer wieder der Eindruck beschlichen, dass mich die beiden bespitzelt haben, um all meine Fehler im Buch zu verarbeiten. Wie kann es sein, dass mir schon fast alles passiert ist, was sie beschreiben? Vermutlich liegt das einfach nur daran, dass ich unoriginellerweise alle typischen Fehler mache („Du bist wie die anderen“).

Neben der im Gebrauch befindlichen Version von WordPress hatte ich zum Beispiel lange Zeit auch noch eine veraltete Version installiert, die ich komplett vergessen hatte. Erst eine nette E-Mail meines Webhosts machte mich auf die Sicherheitslücke aufmerksam. So viel zum Thema „Auch die Hintertür abschließen.“

Ich habe schon im PHP dieser Website in der produktiven Version herumgehackt und alles zerschossen. Ich hatte zwar ein Backup angelegt, aber aus irgendeinem Grund funktionierte das nicht. Die Seite war eine Weile weg, bis ich im Schweiße meines Angesichts zumindest den entscheidenden Fehler gefunden hatte und am Ende war dann nur noch die linke Spalte des Weblogs verschwunden. Die wiederum habe ich ohne professionelle Hilfe auch nicht wiederbekommen.

Das Buch ist voller hilfreicher Hinweise, wie etwa: „Der Lerneffekt ist größer, wenn der andere selbst bemerkt, was es zu verbessern gibt.“ Das stimmt so sehr und erinnerte mich daran, wie mir ein Bekannter zunächst bei der Steuererklärung geholfen hat, nachdem ich mich selbständig gemacht hatte, und er dann irgendwann meinte: „Den Rest versuch mal alleine. Aber ruf mich an, wenn Du dabei von Wein auf Whiskey umsteigst.“

~

Großer Vorteil des Buchs: es ist äußerst unterhaltsam geschrieben:

„Der alte Code war nicht nur schwer zu durchschauen, weil sein Autor damals noch schlechter programmierte als heute, sondern auch, weil er viele Sonderfälle und Nebenbedingungen abdecken und sich in eine vorhandene Umgebung einpassen musste. Die Hyäne, der Nacktmull und die Vogelspinne gelten gemeinhin nicht als gutaussehende Tiere, aber es gibt Gründe für ihr Aussehen.“

Ich musste dabei sofort an eine Sitzung im Gemeinsamen Bundesausschuss letzte Woche denken. Wir hatten in der vorigen Sitzung im Oktober einige Änderungen an der Dokumentation zu einer Richtlinie vorgenommen. Nach einer langwierigen Diskussion hatten wir uns dabei auf bestimmte Formulierungen geeinigt, mit denen alle Sonderfälle und Nebenbedingungen abgedeckt wurden. Zwei ständige Teilnehmer der Gruppe waren in dieser Oktober-Sitzung aber nicht dabei gewesen und zeigten sich letzte Woche dann sehr unzufrieden mit unseren Änderungen.

Wir legten die einzelnen Gründe für die Änderungen dar, was in eine unerfreuliche Reproduktion der Oktober-Diskussion mündete. Einerseits konnten die beiden Teilnehmer, die die vorige Sitzung verpasst hatten, anschließend unsere nacktmulligen Formulierungen besser verstehen, andererseits ergab sich aber bei allen Beteiligten eine neue Unzufriedenheit mit dem Text, der daraufhin letzte Woche wiederum nochmals überarbeitet wurde. (Man mag sich denken, wie groß aktuell meine Hoffnung ist, dass gänzlich Außenstehende unsere Vorgaben zur Dokumentation am Ende verstehen, geschweige denn schätzen werden.)

~

Dieses Problem hängt direkt zusammen mit der Wichtigkeit des Kommentierens. Auch hierzu gibt das Buch einen hilfreichen Tipp: „Als Faustregel kann man sich daran orientieren, dass ein Kommentar alles enthalten sollte, was man auch seinen Kollegen sagen würde, ginge man mit ihnen den Code [den Text] durch.“

Im Gemeinsamen Bundesausschuss werden die Richtlinien in den sogenannten Tragenden Gründen kommentiert. Die Tragenden Gründe erfreuen sich – weitestgehend zu unrecht, wie ich finde – keiner großen Beliebtheit. Während der Verhandlungen muss man zwar vorsichtig sein, dass einem nichts Wichtiges von der Richtlinie in die Tragenden Gründe verschoben wird, denn nur die Richtlinie ist rechtlich bindend, und in den Tragenden Gründen werden Dinge daher gerne beerdigt. Aber gerade wenn ich mich mit Richtlinien auseinandersetze, an denen ich selbst nicht mitgearbeitet habe, hilft mir das Lesen der Tragenden Gründe. Und aus dieser Erfahrung heraus versuche ich, mich beim Verfassen von Tragenden Gründen an obige Faustregel zu halten.

~

Worauf ich eigentlich hinaus will: In „Weniger schlecht programmieren“ geht es nur vordergründig um das Programmieren, in Wahrheit handelt es sich um einen hervorragenden Ratgeber für alle Lebenslagen. Hier meine Lieblingssätze:

  • Man braucht die Bereitschaft, geduldig Dinge nicht zu verstehen.
  • Es hilft, sich grundsätzlich von der Annahme zu trennen, man könne irgendetwas auf Anhieb entscheiden.
  • Wissen über ein Thema qualifiziert einen noch nicht automatisch dazu, es zu vermitteln.
  • Interesse ist ein scheues Tier, es kommt zum Menschen entweder freiwillig oder gar nicht.
  • Für abstrakte Prinzipien ist am Ende immer noch Zeit.
  • Es ist gar nicht so leicht, nur das zu protokollieren, was man tatsächlich sehen kann.
  • Metaphern führen besonders leicht zu Verwirrung und Missverständnissen.
  • Es ist ein Irrglaube, anzunehmen, man könne sich sofort wieder in die Aufgabe hineindenken und zusätzlich besser sein als beim letzten Mal.
  • Am Ende einer Fehlersuche wird man häufig feststellen, dass die Welt eigentlich von Anfang an voll war mit riesigen Hinweisschildern: „Zum Fehler bitte hier entlang!“
  • Die Lücke zwischen zwei Überzeugungen ist ein fruchtbarer Zustand. Aber es ist ungemütlich in diesem Zwischenbereich, und die Verlockung ist groß, so schnell wie möglich wieder den vermeintlich festen Boden einer neuen Überzeugung zu erreichen.
  • Jede Tatsache, die nicht unseren Erwartungen entspricht, vermittelt uns eine wichtige Botschaft, nämlich, dass wir das Problem entweder noch nicht wirklich verstanden haben oder uns sogar eine ganz falsche Vorstellung davon machen.
  • Wir brauchen einen vernünftigen Umgang mit unserer eigenen Fehlbarkeit und der anderer Menschen. Alles kann immer falsch sein und ist es meistens auch.
  • Nicht nur im Internet ist es häufig am klügsten, aufkommenden Streit durch Nichtbeachtung wieder einschlafen zu lassen – jede Antwort facht die Flammen nur weiter an, bringt Sie Ihrem Ziel nicht näher und zehrt an Ihren Nerven und Ihrer Zeit. Zusatzvorteil: Schon nach einigen Jahrzehnten der Übung erlangen Sie so die Gemütsverfassung eines buddhistischen Weisen.

~

Möglicherweise ermutigt mich das Buch sogar, wieder ins PHP dieser Seite einzusteigen und ein paar gewünschte Veränderungen an der linken Spalte vorzunehmen, zum Beispiel das Format des Archivs zu ändern. Aber: „Das mache ich dann später, wenn ich mal mehr Zeit habe!“

1 thought on “weniger schlecht programmieren.

  1. Antworten
    Gelesen im Dezember 2015 | - 4. Januar 2016

    […] Im Prinzip hat auch Monika Scheele-Knight schon alles gesagt, was man über dieses Buch wissen muss. Offensichtlich lassen sich viele Tipps zum besseren Programmieren auch ohne Probleme auf völlig andere Lebensbereiche anwenden. […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Scroll to top