Wie programmieren

Beim Programmieren geht es um Datenzuweisungen. if else while spielen eine untergeordnete Rolle. Wenn die Daten richtig zugewiesen sind stimmt das Programm. Welche Abläufe dahinterstehen, ist NebenSache.

Diesen ersten Punkt betone ich deshalb, weil der "Programmablaufplan" das erste war, was ich gesehen habe, diese Darstellung ist immer noch präsent. Die Frage des "wie", welche Zweige und Schleifen etc. steht dort im Vordergrund. Nein, das ist es nicht.

Die Objektorientierung passt hier genau ins Bild.

Selbstverständlich sind Module sinnvoll zu definieren. Jedes Modul muss für sich selbst beschreibbar und eigenständig versteh- und testbar sein.

Das Refactoring wurde von mir früher immer mit einem aufdiktierten schlechten Gewissen betrieben. "Man soll doch bitte im Vorhinein …​", Lasten- und Pflichtenheft, "…​sich vorher im Klaren darüber sein…​", was zu einem Modul gehört, zuerst die Schnittstellen definieren.

Das Refactoring brachte auch Ärger mit dem Chef "…​ wieso ist denn schon wieder alles geändert". Zugebenerweise ist es eben notwendig und schwierig, die Anderen auch mitzunehmen.

Das Refactoring, also die Umstrukturierung, ist aber deshalb nötig, weil:

Das Thema Refactoring hat viel mit "agil" zu tun, bei Modularität sollte man an Dependencies denken.

Aus dem Fokus der Gesamtproblembearbeitung "die Software soll im Test auf Anlage laufen" geht es oft um kleine Bugs und deren Fixing. Dann wird solange überlegt und geändert, bis die Sache tut. Sollte danach noch etwas anderes geändert werden müssen (noch ein Bug), dann ist die getane Änderung "heilig". "Das ist getestet, ja nicht nochmal ändern" oder "do not touch a running system". Letzterer Spruch gilt dann, wenn jemand "schnell nur noch" einen Feinschliff an der funktionierenden Software machen möchte, kurz bevor er die Anlage verlassen will. Das kommt nicht gut an. Aber dieser Spruch ist falsch wenn es um Modularität und Entwicklung geht.

Wenn man sich auf die Modulebene bewegt, dann ist es wichtig dass das Modul stimmt und sich gut dokumentieren und beschreiben lässt. Das ist die erste Anforderung. Bietet ein Modul "immer schon" ein bestimmtes Schnittstellensignal, das aber eigentlich mit diesem Modul nichts zu tun hat, dann sollte man es in der Modulbearbeitung herausschmeißen (das Wort "entfernen" wäre hier zu schwach). Es gehört nicht dahin.

Nun, danach funktioniert das System nicht mehr, weil das Signal fehlt.

Es kommt nunmehr die zweite Überlegung: "Was ist das für ein Signal, wo kommt es her, wo geht es hin?". Es kann sogar sein, dass am Ende der Überlegung die Aussage steht: "Das Signal wird eigentlich gar nicht gebraucht", es handelt sich also um ein Relikt aus der Vergangenheit, dass nur formell irgendwo verarbeitet wird. Andere Variante ist, dieses Signal eben dem richtigen Modul zuzuordnen.

Wir sind hier wieder beim Refactoring, ungeliebt bei Chefs. Aber nur so kommt man zu einer soliden Softwarelösung die einige Jahr(zehnt)e bestand haben kann, und die letztlich über die Zeit Entwicklungs- und Pflegeaufwand spart.

Anderes Beispiel: In der Regelungstechnik spielt oft das Vorzeichen eine Rolle:

Das ist die Regelabweichung e gebildet aus Sollwert w und Istwert x. Wenn nun der Istwert von der Messung her passend in die andere Richtung wirkend ankommt, also beispielsweise als elektrischer Stromwert anders herum gepolt, und der Sollwert ist sowieso 0 oder kommt aus anderen Gründen auch genau vorzeichenverkehrt. Darf man dann programmieren:

Funktionieren tut dies, aber die Gleichung ist nicht erkennbar im Vergleich zur bekannten Gleichung der Regelabweichung. Die Tatsache, dass der Eingangswert negiert ankommt, ist irgendwo im Programm versteckt behandelt. Bei der nächsten Softwarekorrektur, einige Jahre später, anderer Kollege, führt das zu Irritationen. Wird der Sensor ausgetauscht, mit einem anderen Abbildungsfaktor und gedrehtem Vorzeichen, wird das Chaos nur noch größer.

Also:

ist der bessere Weg. Das Signal wird als negiert passend im Namen gekennzeichnet, bereits an der Input-Schnittstelle. Man kann dann später in einem Refactoring falls nötig eine Eingangsbehandlung dazusetzen, es bleibt übersichtlich:

Nun hat man es statt dessen mit dem factor in der Hand, allerdings mit etwas größerer Rechenzeit. Wenn der factor const ist und 1.0f oder -1.0f für die Zielsystemcompilierung, dann wird der Compiler passend optimierend eingreifen.

Folgende Erfahrung könnte wichtig sein:

Es ist bei heutigen schnellen PCs und Compilern relativ einfach, spezifische Befehle zum Datentest und Debugstop einzufügen. Man kann diese Befehle im Programm oft auch einfach drin lassen (kann sie später noch wieder gebrauchen) oder in C/++ mit bedingter Compilierung versehen. In Java sieht das bei mir oft wie folgt aus:

Debugutil.stop() ist eine leere Anweisung, lediglich eine BreakpointMöglichkeit. Die Aufbereitung und Abfrage ist etwas umfangreicher, daher zur Runtime nur insgesamt bedingt ausgeführt.

Dieser Begriff meint, das im normalen Programmablauf wichtige Zwischenwerte kontrolliert werden. Der Unterschied zum Anwendertest: Eben Zwischenwerte. Möglichkeiten sind Logfiles (werden zu lang), eben besser der Zugriff auf Daten, die eigentlich gekapselt sind (private in Objektorientierung).

Diese Daten sollten im normalen Programmablauf mit betrachtett werden, um unter den gegebenenen Bedingungen richtig entscheiden zu können, ob alles wie vorgesehen läuft.

Für dynamische Übergänge gibt es Traces (Spuren des Ablaufs) in einem Trace-System, vergleichbar mit einem Log. Der Unterschied zum hier definierten "Trace" ist: Der Log speichert alles, der Trace soll nur für bestimmte Situationen Daten speichern.

Hilfsmittel zur Datenbeobachtung, Trace und Log wurden vom Verfasser seit ca. 1995 systematisch entwickelt und eingesetzt: * 1995 ein Trace auf einer 16-bit-embedded Plattform, um im Störfall zu wissen, welche Daten angekommen sind und welche Messwerte es vor der Störung gegeben hat. Der Trace wurde getriggert mit der Störung, es gibt eine Nachlaufzeit aber insbesondere die Vorgeschichte im Zeitbereich von Millisekunden (für elektrische Regelungen). Wichtig dabei ist, dass bei einem Trigger auf den nächsten Trace-Buffer umgeschaltet wird, für die ggf. zeitlich kurz darauf folgende weitere Triggerung, oder wenn kein Bedienpersonal für Übertragung und Auswertung vor Ort ist.

Die Inspector-Lösung ist eben die Möglichkeit, zur Laufzeit (Runtime) auf alle internen Daten zuzugreifen. Das schließt das Eintragen von Test-Stimulis und Parameterwerten ein.

Unter Test soll nun der wirkliche unabhängige Test, nicht das entwicklungsbezogene Debuggen verstanden werden.

Grundsätzlich muss zwar zwischen Modul- und GesamtTest unterschieden werden, aber die Gesamtsoftware ist im größeren Kontext auch wieder nur ein Modul.

Beim Test muss beachtet werden:

Sprich, das Entwicklerteam braucht interne Daten auch von Tests, die nur aus Kundensicht durchgeführt werden.

Ein zweiter Aspekt des Tests:

a) ist insbesondere für die genaue Dokumentation (Testabnahme) wichtig, und auch für die Wiederholung von Tests nach Änderungen.

b) ist als Erfahrung relevant und kann Testfälle für a) verbessern oder hervorrufen.

b) ist auch eben der reine Praxistest, Feedback von Anwendern.

Der Test a) muss automatisch durchführbar sein. Das bedeutet, Software compilieren über batch-Ablauf, Laden, Parameter laden, starten, Testergeb

Ein Algorithmus, eine Datenaufbereitung, ist Bestandteil einer Operation x1() in class A1.

Nun wird in der Projektbearbeitung festgestellt, dass in einer anderen Operation x2() beispielsweise in selber Umgebung (class A1) oder unter ähnlichen Bedingungen fast genau die gleiche Datenaufbreitung ausgeführt wird, eingebettet in weitere dann unterschiedliche Anweisungen.

Nun gilt allgemein die Regel "Don’t repat yourself", also gleiche Algorithmen nicht mehrfach schreiben.

Die erste Frage ist: Sind diese beiden Teilalgorithmen nur zufällig ähnlich bis gleich (y = 2.5*x + b könnte in verschiedenen Situationen ähnlich auftreten ohne Zusammenhang) oder handelt es sich tatsächlich um die gleiche Intension der Datenaufbereitung (die Formel hat eine benennbare Bedeutung). Nur im letzten Fall sollten beide zusammengefasst werden nach der "Don’t repat yourself" Regel. Würde man im ersten Fall beide zusammenfassen nur weil sie gleich aussehen, ist der Ärger vorprogrammiert, wenn bei einer der Datenaufbereitungen zusammenhangslos dann eine Änderung nötig ist (!).

Das Herauslösen des Teilalgorithmus erfolgt wie folgend dargestellt.

Oft sieht das nicht so komplex aus wie in den obigen Punkten angeführt. Der Code ist einfach herauslösbar.

Geht man dabei systematisch vor, lässt den Compiler prüfen, dann ist das Ergebnis funktionsgleich. Man kann gleichmal in den Gesamttest gehen, ohne Einzelheiten nochmal zu debuggen.

Variable können global statisch, lokal statisch, als Instanzvariable oder als lokale oder Stackvariable definiert sein. Die Frage global statisch oder lokal statisch sei hier nicht betrachtet und zumeist auch nicht in Betrachtung. Siehe Keine Verwendung einfacher statischer Variable?.

Software wird oft von Kleinigkeiten bestimmt. Es gibt kleine Verbesserungswürdigkeiten. Lässt man diese unbeachtet, dann bleibt dies für die Zukunft verbesserungswürdig.

Einfaches Beispiel: Eine Suchabfrage hat bislang nur Namen beginnend mit Großbuchstaben berücksichtigt, weil dies die ursprüngliche Intension war. Im Laufe der Zeit wären zwar auch Anfangs-Kleinbuchstaben wünschenswert, aber es war eben nicht vorgesehen. Da dies nicht berücksichtigt wurde, gab es Workarrounds vor dem Aufruf, die den ersten Buchstaben nach Großbuchstaben wandeln, nur damit die Funktion so wie gegeben genutzt werden konnte. Das ist unschön. Weiter so über Jahre.

Die Verbesserung wäre einfach, die Kleinbuchstabenberücksichtigung einbauen. Die Funktion selbst wird damit nicht geändert für bestehende Anwendungsfälle, sondern nur erweitert. Bestehende Workarrounds müssen auch nicht nachgebessert werden, sie wären zwar nun unnötig, funktiontionieren aber dennoch weiter. Dies ist wichtig, denn eine Softwareänderung an einer Stelle sollte nie eine Änderung an einer anderen Stelle nach sich ziehen.

Nun gibt es zwei Möglichkeiten der Organisation:

Die Variante a) ist die offizielle und einzig anzuerkennende. Sie hat aber den Nachteil, dass die kleinen Änderungen eben liegenbleiben weil sie nicht entsprechend priorisiert sind. Ein zweiter sehr großer Nachteil ist: Änderungen haben manchmal Seiteneffekte, die übersehen werden. Wenn ein RfC "dran ist", dann bearbeitet man ihn nach Liste, hat aber in diesem Moment eventuell nicht den Gesamtfocus im Kopf. Es wird formal gearbeitet, der nächste RfC wartet schon. Mit einem guten Test erwischt man unerwünschte Seiteneffekte, die aber wieder Arbeit verursachen. Dann ist es manchmal besser, die RfC-Bearbeitung dennoch drin zu lassen (es ist verbessert), aber den Seiteneffekt, der nur in bestimmten Fällen auftritt, wiederum als RfC zu formulieren.  — Never ending story.

Die Variante b) gehört sich nicht, denn sie ist vollkommen desorganisiert. Die Software ist plötzlich und ungeplant geändert. …​. Aber: Selbstverständlich wird die Änderung danach einem Test unterzogen. Manchmal ist die Änderung aber so klein (und trotzdem wirksam), dass sie faktisch vollkommen überschaubar ist. Ein Test erfolgt innerhalb der normalen Nutzung, bzw. sowieso im nächsten Testlauf. Der bedeutende Vorteil ist: Die Änderung wird dann vollzogen, "wenn sie vor die Füße fällt". Gemeint ist, wenn man sowieso an diesem Modul arbeitet, also seine Funktionalität insgesamt im Kopf hat. Damit ist ein viel besserer Überblick gegeben als Basis für die kleine Änderung. Die notwendige Vorsicht beim Bewerten von impacts darf man dem verantwortungsvollen Programmierer schon zumuten. Last not Least gibt es ein Versionsmanagement, in dem man sich die Änderung ansehen kann und im Ernstfall sei es auch nur für einen Test genau diese Änderung rückgängig machen kann.

In beiden Fällen muss ein Release sowieso durch einen möglichst umfangreichen Test laufen. In beiden Fällen sollte ein Anwender auch auf "die alte Version" zurückschalten können, wenn unklare Verhaltensweisen festgestellt werden. Sowohl die Änderung über RfC als auch "by the way" kann fehlerhafte Impacts verursachen.

Die Variante b) "Ändern wenn es vor die Füße fällt" ist nicht geeignet für Softwareentwickler, die nur auf Auftragsbasis arbeiten. Sie könnte für die Verantwortlichen von Open Source Projekten aber auch für Key-Entwickler bei Firmen-Software passend sein. Wichtig ist, dass die Entwickler dafür Verantwortung übernehmen können und auch dürfen. "

Das Problem ist mir schon seit mindestens 1992 bewusst geworden.

Programmiert man in Assembler, dann ist jede Variable nur einmal kontextfrei vorhanden. Lediglich die Sichtbarkeit kann auf die jeweilige Quelle bezogen sein. Die einfachen Programmiersprachen, wie BASIC oder auch dBase sind genauso vorgegangen. Eine Variable gab es einfach, nach dem Kontext wurde nicht gefragt.

In C ist dies grundsätzlich ähnlich wie in Assembler, eben weil C eigentlich der Ersatz für Assembler sein sollte, zur Entstehungszeit wie auch heute. Also definiert man im alten C-Stil Variable einfach so im source-code. Für die Sichtbarkeit nur im eigenen Modul gibt es die Kennzeichnung static (irreführend, diese Bezeichnung besagt eher, dass es eine Statevariable ist) und extern in der Deklaration im Headerfile und eben nicht static in der Definition.

Zusätzlich gibt es in C die Stackvariablen, auch als lokale Variable bezeichnet. Man kann diese auch in manuell programmierten Assembler haben, in dem eben mit dem Stackpointer Register gearbeitet wird.

Was dabei vollkommen missachtet wird, ist die sogenannte "Wiedereintrittsfähigkeit" in den Code, was allerdings auch eine alte untaugliche Bezeichnung ist. Gemeint ist dass der selbe Code-Teil in mehreren parallelen Threads genutzt wird, oder evtl. auch rekursiv. Diese sogenannte Wiedereintrittsfähigkeit (Reentrancy) ist aber aus der Sicht von Anwendungen des frühen C eine Sonderbedingung.

Und so ist es oft heute noch in der Denkweise, wenn man mal einfach zu programmieren gelernt hat.

Es gibt ein viel einfacheres Prinzip, dass diese sogenannte Reentrancy von haus aus mitbringt, so dass man nicht mehr darüber nachdenken braucht, und das auf heutigen Controllern und Prozessoren aufgrund optimierender Compiler und einen leistungsfähigen Maschinenbefehlssatz effektiv funktioniert: Das ist die Objektorientierung. Man sollte nie nicht objektorientiert programmieren.

Was ist der Kern der Objektorientierung:

Das ist die grundlegende Basis der Objektorientierung. Auf Maschinenbefehle bezogen (Assembler) braucht man also ein Register, dass die Adresse der Daten enthält. Um auf die Daten zuzugreifen, sind Adressrechnungen erforderlich. Und genau diese werden von den modernen Prozessoren "by the way" nebenläufig ausgeführt. Zu Zeiten der Entstehung von C war das noch nicht so. Dennoch hat man in C die Grundlage der Objektorientierung, die struct, als Sprachmittel schon frühzeitig eingeführt.

Nicht objektorientiert ist:

Objektorientiert in C sieht das wie folgt aus:

Man braucht also die Referenz thiz genannt in der Funktion. Außerhalb zu klären ist wo die Daten liegen. Das ist Zusatzaufwand. Aber die Funktion ist sauber strukturiert, es gibt keine Konflikte, und die Reentrance ist geklärt.

Zu hoher Aufwand für eine einfache Aufgabenstellung?? Der Denkfehler liegt darin, dass die Aufgabenstellung nicht einfach bleibt sondern die Komplexität der Gesamtlösung wächst.

Die objektorientierte Variante hat einen höheren Grundaufwand, ist aber eine saubere Basis.

Nun, die Entscheidung für C++ statt C ist davon unbetroffen. Auch in C++ kann man mit solchen statisch globalen Variablen programmieren und in C kann man objektorientiert.

Dies sei die Kernaussage dieses Kapitels.