Was ist eigentlich Softwarequalität?

Nicht jedes Programm ist gleich gut und welche Fähigkeiten sollte eigentlich ein Programmierer haben? Von mir zusammengefasst für (Einsteiger-)Programmierer und Anwender. Auch finden hier Programmierinteressierte Grundlageninfos und Links.

Vorab: dieser Artikel stellt meine eigene Meinung da, und ist einer unter vielen Artikeln zum Thema.

Der Junge muss an die frische Luft…

Mit 9 Jahren habe ich meine ersten Programme in Basic auf dem C64 geschrieben. Während andere Klassenkameraden sich mit den damals üblichen C64-Spielen beschäftigten, fand ich es total interessant, irgendwelche farbigen Linien auf den Bildschirm zu bringen, oder meinen Computer Fragen beantworten lassen. Den damals noch gern genutzte Befehl GOTO (Sprungbefehl zu einer bestimmten Stelle im Programm) habe ich benutzt, um das Programm endlos laufen zu lassen – legendär mein Chatbot, der immer wieder fragte „Erzähle mir mehr davon“ oder in Variation „Das ist interessant, erzähle mir mehr davon!“ Das war weder sinnvoll, noch hat es mir irgendwelche Lorbeeren eingebracht.

Später (mit 14), auf dem PC regte mich die Gamification bei bestehenden Vokabellernprogrammen auf. Nach 1 bis 5 richtig beantworteten Vokabel(n) kam dann zur Belohnung ein Tierbild. Erstens war die Anzahl der Bilder sehr stark begrenzt- dadurch wiederholten diese sich zu oft bei 100 Vokabeln. Andererseits konnte ich das Anzeigen der Bilder nicht abgeschaltet oder verkürzt werden. Ich musste aber die Vokabeln schnell lernen (Medienzeit war zu schnell vorbei).
Also programmierte ich mein eigenes Vokabellernprogramm mit Turbo Pascal. Dabei habe ich folgende Punkte berücksichtigt:

  1. es musste möglich sein, die Vokabeln schnell einzugeben, ggfls auch mit externen Programmen. Ich habe mich dann für das CSV-Format entschieden, da dieses auch einfach mit einem Texteditor bearbeitet werden kann.
  2. Ich habe die Konfigurationen in eine externe Datei ausgelagert (ebenfalls CSV)
  3. es gab die Möglichkeit, die Auswertungstexte anzupassen. Die Standardtexte wären für die meisten viel zu kritisch gewesen (eine gute Bewertung gab es erst ab 95%, die anderen Texte möchte ich hier nicht zitieren, die waren doch sehr beleidigend 😉…)
  4. Es gab die Möglichkeit, die Vokabeln in beide Richtungen zu lernen
  5. die Lernmethode war „jede Vokabel muss mindestens einmal pro Durchgang richtig eingegeben werden“
  6. die nächste Vokabel wurde per Zufallsgenerator ausgewählt
  7. es gab ein Tastenkürzel, um die Vokabel in der CSV-Datei während der Anzeige zu korrigieren, falls bei der ursprünglichen Eingabe ein Fehler unterlaufen ist

Dabei hat niemand in meiner Umgebung verstanden, warum ich programiere, wo es doch übliche Wege gab, Vokabeln zu lernen (Lernkarten, Klapplernen, etc). Keiner hat verstanden, dass es mich aufgeregt hat, dass man in so viel Zeit nur so wenig Durchgänge beim Lernen geschafft hat- mein Ziel war: alle Vokabeln möglichst schnell zu lernen.
Aus intrinsischer Motivation eine Aufgabe zu lösen, um mehr Zeit für die wichtigen Dinge zu haben.
Die meisten (älteren) Programmierer:innen werden einen ähnlichen Lebenslauf haben, die Programmiersprachen lassen sich dabei an die damals üblichen Sprachen anpassen.

Das Vokabellernprogramm müsste in diesem Jahr eigentlich 30-jähriges Jubiläum haben. Auch wenn ich dadurch viele Dinge gelernt habe, wird heute nicht mehr so programmiert. Wir sind inzwischen weit weg von EVA-Prinzip (Eingabe-Verarbeitung-Ausgabe). Heute laufen verschiedene Prozesse parallel, die von dem Nutzer angestoßen werden.

Die Stufen der Evolution

Eigentlich könnte man gut anhand der Programmiersprache PHP die Evolution des Programmierens beschreiben. (Ja, ich weiß, manche sagen, PHP ist keine Programmiersprache, sondern eine Scriptsprache- aber wir wollen jetzt mal nicht päpstlicher als der Papst werden.) Auch kräuseln sich bei den meisten erfahrenen Programmieren die Fußnägel, wenn ich PHP als Beispiel anführe. Aber, PHP hat eine sehr niedrige Einstiegshürde, man kommt sehr schnell zu einem Ziel.

PHP hat einen riesigen Entwicklungsprozess hinter sich. Es ist heute zwar immer noch möglich, imperativ zu programmieren (=Programm wird von oben nach unten ausgeführt) und sogar auch Sprungmarken zu nutzen 🤢 – aber das machen wir besser nicht mehr. PHP kann aber auch auch für komplizierte und „höherwertige“ Softwareprojekte eingesetzt werden. Verschiedene (PHP-)Programmierende können also sich in verschiedenen Stufen befinden.

Stufe 1 – der Einstieg

Meinem Verständnis nach entspricht diese Stufe dem Erlernen der Syntax (also sowas wie den Vokabeln)- muss ich die Zeilen einrücken, mit Semikolon beenden oder geschweifte Klammern setzen? Dazu gehört auch zu verstehen, was imperative Programmierung ist.

Zusätzlich gehört für mich dazu, Kontrollstrukturen zu kennen

Das erscheint schon eine ganze Menge, das sind aber auch die Grundlagen des Programmierens, diese sind in allen Programmiersprachen mehr oder weniger gleich (wie gesagt, bis auf unterschiedliche Syntax).

Auch wenn ich mir diese Kenntnisse früher selbst erarbeiten musste, heute wird so etwas im Unterricht bis zur 7. Klasse in den Schulen unterrichtet.

Stufe 2 – weniger ist mehr

Meinen Auszubildenden habe ich immer erzählt „Ein guter Programmierer ist faul- nicht dumm, aber stinkefaul.“ Soll heißen, jede Zeile, die ich code (programmiere), ist eine Zeile zuviel. Ich überlege vorher, wie ich etwas lösen will. Ich vermeide Wiederholungen. Sowohl interne (also in meinem eigenen Code), als auch externe – ich hole mir Ideen woanders her. Gibt es schon passende Lösungen? Was haben andere anders programmiert? Auf welche Probleme sind diese dabei getroffen? Es geht hier also um effizientes Programmieren und auch darum, nicht das Rad neu zu erfinden.

Außerdem gehören für mich die sogenannten Regeln der boolschen Algebra dazu. Mit Hilfe dieser Regeln können beliebige abstrahierte Probleme in vereinfachte Form gebracht werden.

Hier ein einfaches Beispiel: Nehmen wir an, wir möchten aus einer Tabelle Personen.xls alle Personen aufgelistet bekommen, die entweder „Müller“ als Nachnamen tragen oder Müller heißen und aus Köln kommen.
Das ließe sich vereinfachen in „Gebe mir alle Personen, die Müller als Nachnamen tragen“- die Angabe „aus Köln kommen“ ist oboslet (überflüssig) und würde unnötige Rechenzeit verschwenden.

Während meines Unterrichts bei einem Schulungsträger für IT-Berufe habe ich immer gesagt: „Es gibt zwei Arten von ITlern: die die programmieren verstehen und die, die Leitungen verlegen.“ 😜

Auch die Vermeidung von doppelten Code gehört dazu. „Doppelter Code ist Scheißcode.“ „Redundanz führt zu Inkonsistenz.“ Alles Sprüche die ich meinen Azubis sage.

Inzwischen sind die Entwicklungsumgebungen (IDE) so schlau, dass sie schlechten Code anzeigen. Natürlich kann eine IDE nicht wissen, wann eine boolsche Algebra das tut, was wir wollen. Die IDE kann aber unnötige Redundanzen erkennen.

Soll heißen, auch die Kenntnisse der 2. Stufe sind nicht so viel wert, aber sie müssen gelernt werden.

Stufe 3 – eine Datei alleine macht noch keinen guten Code

In Stufe 3 geht es darum, Code sinnvoll in verschiedene Dateien aufteilen zu können. Ich habe dieses Stadium auch irgendwann so ca 2003 erreicht. In PHP ist es möglich, HTML und PHP-Anweisungen innerhalb einer Datei zu mischen. Aber nur weil man es kann, macht es ja noch lange keinen Sinn.

Mindestens die PHP-Anweisungen sollten von dem „normalen“ HTML getrennt werden. Früher hat man dazu ein Templatesystem verwendet. Die Logik wiederum war in ein PHP-Dateien, die in die HTML-Dateien weitere Texte eingefügt haben. Das machte die Wartung einfacher.

Eine andere Aufteilungsmöglichkeit entsteht durch sogenanntes objektorientiertes Programmieren. Hierbei wird definiert, dass es Objekte gibt, die bestimmte Eigenschaften haben. Diese Eigenschaften lassen sich lesen, schreiben oder auf andere Art manipulieren.

Interessanter Hinweis am Rande: auch hierbei können IDEs Arbeit abnehmen.

Stufe 4 – Die Räder der anderen verwenden…

Warum soll ich mir eigentlich die Mühe machen, solche Dinge wie ein ORM für Datenbankzugriffe oder ein Templatesystem selbst zu programmieren? Egal, wie gut ich bin, andere sind besser- oder es sind mehr Leute, die genausogut wie ich selbst auch bin und auch mehr Zeit haben. Ich nehme also einfach ein Framework, dass mir die Funktionen bietet, die ich brauche. Natürlich sind da mehr Funktionen vorhanden, als ich jemals nutzen werde, aber was solls? Solange, wie nicht alles gleichzeitig in den Arbeitsspeicher geladen wird, ist das egal. Festplattenspeicher kostet fast nichts. Und ob da noch ein paar Dateien mehr oder weniger rumliegen, soll mir herzlich egal sein. Wenn ich ein richtiges Framework auswähle, muss ich mir um Sicherheitsaktualisierungen keine Gedanken machen.
Wenn doch mal etwas nicht funktioniert, kann ich jemanden schreiben, der sich darum kümmert. Falls ich den Fehler selbst beheben kann, kann ich diese Änderung an das Team des Frameworks schicken, diese sind dafür dankbar. (Geben und Nehmen-Prinzip in der OpenSource-Gemeinschaft)

Stufe 4 heißt, zu verstehen, warum ein Framework sinnvoll ist, und das Framework auch benutzen können. Zudem gibt mir das Framework vor, wo ich was ablegen muss. Das sinnvolle Aufteilen von Code in verschiedene Dateien hat mir jemand schon vorweg genommen. Gut ist, wenn ich das nicht als enges Korsett empfinde, sondern mich darauf einlasse und damit arbeiten kann. Im Endeffekt spart mir das viel Zeit (und meinem Arbeitgeber viel Geld). Vielleicht nicht in der ersten Stunde, auf lange Sicht schon.

Stufe 5 – Wie solls ich machen und wie nicht?

Es gibt immer unzählige Wege, Aufgaben zu lösen. Gerade in der IT werden Anfänger häufig von der Anzahl der Möglichkeit erschlagen.

Dabei gibt es Möglichkeiten, die fast immer richtig sind (Design Pattern) und Möglichkeiten, die fast immer falsch sind (Anti-Pattern). Jemand in Stufe 5 sollte diese kennen, benennen, unterscheiden und auswählen können.

Clean Code ist ebenfalls ein Schlagwort. Natürlich muss man nicht Clean Code bis zum weißen Grad können, aber man sollte schon wissen, was das SOLID-Prinzip ist.

Ab jetzt fängt für mein Verständnis erst ein Programmierer an. Alles vorher gehört meinem Verständnis nach zur Ausbildung.

Stufe 6 – Qualität messen können

Um die Eingangsfrage aufzulösen- Was ist für Sie Qualität?

Kann man die sehen/lesen/schmecken ?

Die eigenen Sinne können ganz schön täuschen. Im technischen Umgebungen sollte Qualität immer messbar sein. Nach meinem Verständnis gehören hierzu zwei Dinge: Performance und das Vermeiden von Fehlern. Letzteres lässt sich relativ gut durch sogenannte automatisierte Tests abdecken. Ein Programm sollte nicht abstürzen oder sinnlose Ausgaben geben, nur weil ich als Anwender eine Eingabefeld falsch verstanden habe oder der Programmierer nicht damit gerechnet hat, dass es mehr als 26 verschiedene Zeichen in Namen geben kann.

Der Königsweg schon seit ca 10 Jahren ist das sogenannte TTD= test driven development. Also zuerst werden Tests geschrieben, danach wird erst die eigentliche Funktion programmiert. Programmierer:innen der alten Schule müssen sich dabei ziemlich umstellen, aber dieser Weg hat unzählige Vorteile- vor allem die dadurch gestiegene Qualität. Ich sehe jetzt wieder die „alten Hasen/Häsinnen“ vor mir, die mir widersprechen wollen. Die Sätze fangen meistens mit „Finde ich auch gut, aber…“ oder „Ja, aber…“ an. Das ist nur ein wehren und Verteidigen der alten Techniken. „Haben wir immer so gemacht.“ „Ist nicht notwendig, weil…“ OK, setzen und in Stufe 5 bleiben- alle anderen: das wäre jetzt State of the Art.

Es gibt auch entsprechende Vorschriften, nach denen Software in bestimmten Bereichen oder für spezielle Kunden geschrieben sein muss. Siehe auch BSI-IT-Grundschutz Abschnitt CON.8

Stufe 7 – höhere Programmiertechniken verstehen und anwenden können

Bis jetzt habe ich nur das Lernen von bestimmten Techniken genannt, aber für das Große und Ganze gab es noch keine Stufe. Diese führe ich jetzt ein. Wir begeben uns langsam aber sicher in die Richtung von Softwarearchitektur.

Wichtige Stichwörter sind hier „großer Schlammball“ vs „hexagone Architektur“. Welches hiervon besser ist, lasse ich jetzt mal offen…
Auch sollte man erklären können, dass Domain Driven Design eine Möglichkeit ist, mit der man Probleme lösen kann, die jetzt noch nicht da sind, die aber in Zukunft auftreten werden. Bei Nichtbeachtung hat man ein Produkt, dass in wenigen Jahren komplett neu geschrieben werden muss.
Verstehen sollten Programmierer:innen dieser Stufe, dass Kommunikation der Schlüssel ist. Sowohl Kommunikation zwischen der einzelnen Elemente als auch bei interdisziplinären Teams. Nicht für alle Nutzer:innen ist Löschen das gleiche wie für uns auf technischer Ebene. Vielleicht gibt es rechtliche Bestimmungen, weshalb nicht gelöscht werden darf.

Also trenne ich den technischen Teil vom Nutzerteil. Im DDD-Sprech führt der Nutzer ein „command“ aus, was ein „Event“ vom System zur Folge hat. Das sind zwei verschiedene Teile der Anwendung. Den Command-Teil muss ich zwingend im „Sprech“ des Nutzers erfolgen. (OK, aufmerksame Lesende würden jetzt einwerfen, dass ich DDD mit CQRS verwechsele, aber sei’s drum.)

Auch sollte man den Unterschied zwischen Entity und Value Object kennen und auch richtig auswählen und anwenden können.

Die Begriffe Microservices und Self-Containes Systems sollten auch richtig von einander getrennt und sinnvoll ausgewählt können. Ach, und habe ich eigentlich schon von Containern VS virtuellen Maschinen gesprochen?

OK, ich gebe zu, das war ein bischen viel Fachbegriffe, Anwender:innen können sich diese ja auch mal von Programmierenden erklären lassen und die Antworten mit denen von Wikipedia vergleichen- Überraschungen und Spaß (oder Schrecken) sind garantiert! Das hilft auf jeden Fall, die „Fachleute“ einzuschätzen.

Stufe 8 – es gibt noch mehr?

Klaro, es muss ja auch die Fachleute geben, die solche Techniken, Modelle und Architekturen entwickeln können. Außerdem können diese Fachleute Ihre Modelle gegen alle Arten von fachlicher Kritik verteidigen- auch bei Vorträgen und in Unternehmen. Diese gehören für mich in Stufe 8. Sie kennen jemanden davon persönlich- Glückwunsch!

Fazit

Ich selbst ordne mich zwischen Stufe 5 und 6 an, werde mich in nächster Zeit aber um TTD kümmern, da Programmierung meiner Meinung nach spätestens jetzt so umgesetzt werden muss. Ein Produkt ohne Tests geht überhaupt nicht.

Interessant waren auch die Themen DDD- das werde ich hoffentlich direkt mit umsetzen können.

(Übrigens, das Beitragsbild ist unter CC-Lizenz veröffentlicht und von hier: https://freesvg.org/male-programmer-working-with-five-screens-vector-image )

Schreibe einen Kommentar

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

Diese Seite verwendet Cookies, um die Nutzerfreundlichkeit zu verbessern. Mit der weiteren Verwendung stimmst du dem zu.

Datenschutzerklärung