Kaisler Mess- und Datentechnik

Die 10 Gebote eines sentimentalen Programmierers


  1. Bevor man beginnt, ein Programm einzutippen, sollte es in seiner Grundstruktur vollständig ausgearbeitet und dokumentiert sein. Man baut ja auch kein Haus, indem man planlos anfängt zu mauern und dann später irgendwann entscheidet, ein paar Stockwerke hinzuzufügen.
  2. Abhängigkeiten, die nur zusammen einen Sinn ergeben, müssen auch zusammenhängend programmiert sein, und jeder logische oder sinnliche Zusammenhang darf in einem Programm auch nur einmal vorhanden sein. Wer diese Regel verletzt wird irgendwann unweigerlich vor dem Problem stehen, dass durch eine einfache Anpassung einer geänderten Geschäftslogik manchmal widersprüchliche Ergebnisse generiert werden.
  3. Ein Programm sollte grundsätzlich orthogonal gebaut werden, was bedeutet, dass es in mehrere vollständig voneinander unabhängige, einzeln auswechselbare und einzeln pflegbare Module aufgebaut wird. Auch wenn es noch so lange dauert, dies ständig zu realisieren, so zahlt es sich bis zum Lebensende der Software fast immer aus.
  4. Ein logischer Block oder eine Methode darf maximal nur soviel Zeilen haben, wie auf einer Bildschirmseite dargestellt werden können. Wer diese Granularität vergrößert, wird spätestens unter erhöhtem Druck nicht mehr in der Lage sein, die einfachsten Änderungen durchzuführen. Denn der "Scope" auf einzelne Programmsegmente wird nach dem Bau der Software mit der Zeit kontinuierlich kleiner.
  5. Der zurzeit gültige Standard beim Bedienen von Software ist konsequent einzuhalten. Nur die ganz "Großen" können es sich leisten diese gewohnten Strukturen zu verlassen. Wie wir aber wissen, häufig zum Ärgerniss aller Anderen, denn vieles wird einfach nur anders, aber nicht auch besser. Wer ändert ohne gleichzeitig zu verbessern, sollte beginnen sich selbst zu ändern. Nur dann besteht eine faire Chance, dass es irgendwann auch besser wird.
  6. Sämtliche Namen und Bezeichner in einem Programm müssen dem natürlichen Denken entsprechen und sollten in ihrer Art konsequent und eindeutig sein. Eine dokumentierte Liste mir den CSDs (Code Standard Definitions) darf in keinem Verzeichnis von Quellcode fehlen. Noch besser ist natürlich ein zentrales Skrip mit immer wiederkehrenden Definitionen, die auch in allen Projekten konsequent eingehalten werden.
  7. Ein Programmierer spricht beim Kunden niemals über die Probleme und Schwierigkeiten seiner Arbeit, sondern immer nur über die Probleme, die der Kunde gelöst haben will. Wenn jeder Musiker immer wieder darüber sprechen würde, wie viele Monate er für eine kurze Passage geübt hat, würde ja auch keiner mehr Musik hören wollen.
  8. Jede Software wird grundsätzlich mindestens zweimal gebaut. Mindestens eine Version zum Entwickeln und Testen und mindestens eine weitere Version zum Ausliefern. Und beide Versionen muss man parallel pflegen, und um so konsquenter, jä länger der geplante oder sogar der reale Lebenszyklus dieser Software ist.
  9. Obwohl es bei den ganz "Großen" durchaus üblich ist, kann sich ein Software-Team keine "Bananan-Software" leisten, denn Software, die überwiegend beim Kunden reift, ist eine rein frustrierende Geduldsprobe für ihn. Lieber viel zu spät, als etwas zu früh ausliefern, denn der Erfolg und Spaß mit schnell funktionierender Software lebt deutlich länger, als die kurze Freude mit nachhaltigem Frust einer zu schnellen Lieferung.
  10. Software ist frühestens dann fertig, wenn sie fehlerfrei arbeitet, dokumentiert ist und vor allem erst dann, wenn die Erwartungen des Kunden erfüllt sind. Unerfüllte Erwartungen des Kunden lassen erkennen, dass der Programmierer die Probleme des Kunden nicht ausreichend verstanden hat.

Ursprung aus dem Jahre 1999, mit Zusatzbemerkungen erweitert in 2013, Peter Kaisler