Programmierprinzipien

Zweck

Um nützliche und dennoch preiswerte Programme und Anwendungen erstellen zu können, sollte man eine Reihe von Programmierprinzipien beachten.

Bevor die Programmierprinzipen näher beschrieben werden können, sollen erst die Ziele genannt werden, die mit diesen Prinzipien erreicht werden sollen.

Ziele

Ziel eines jeden Softwareentwicklungs-Vorhaben sollte die Erstellung von Software sein, die zwei Eigenschaften aufweist:

nützlich (useful)

Die Software sollte für den Benutzer nützlich sein.

preiswert (inexpensive)

Die Software sollte so geringe Kosten und Folgekosten verursachen wie möglich.

Software-Eigenschaften zur Erfüllung der beiden Ziele

Um die beiden vorgenannten Ziele zu erreichen, sollte ein Softwarepaket folgende Eigenschaften haben:

Spezifikation existiert (Specification exists)

Um die Nützlichkeit und die Korrektheit des Softwarepakets beurteilen zu können, sollte eine Spezifikation vorliegen, die detailliert die Aufgaben und Eigenschaften des Paketes beschreibt.
⇒ Nützlichkeit (ist abschätzbar)

korrekt (correct)

Die Implementierung des Paketes sollte korrekt sein, es sollte also die Spezifikation in allen Punkten erfüllen.
⇒ keine Kosten durch falsches oder unerwartetes Verhalten

robust (robust)

Das Softwarepaket sollte auch in abnormalen (nicht-spezifizierten) Situationen stabil laufen.
⇒ keine Kosten durch Inkonsitenzen
⇒ geringe Kosten bei Bedienungsfehlern und Systemausfällen

benutzbar (usable)

Das Softwarepaket sollte einfach zu erlernen und zu benutzen sein.
⇒ Nützlichkeit wird verbessert
⇒ geringe Schulungskosten
⇒ geringe Kosten durch Falschnutzung
⇒ keine Kosten durch frustierte Benutzer

sicher (secure)

Unautorisierter Zugriff auf Daten oder Programme sollte unmöglich sein.
⇒ keine Kosten durch Sicherheitsmängel

effizient (efficient)

Das Softwarepakt sollte eine möglichst gute Laufzeit- und Speichereffizienz aufweisen, d.h. die vorhandenen Ressourcen möglichst gut ausnutzen.
⇒ geringe Kosten durch geringe Hardwareanforderungen

wartbar (maintainable)

Das Softwarepaket sollte leicht an neue Gegebenheiten angepasst werden können. Fehler sollen leicht behoben werden können (da sie sich nie ganz vermeiden lassen).
⇒ geringe Wartungskosten

Für die Eigenschaft „wartbar“ gibt es drei Spezialfälle, die hier gesondert genannt werden sollen:

kompatibel (compatible)

Das Softwarepaket sollte komaptibel zu bestehenden Systemen sein, es sollte also standardisierte Schnittstellen unterstützen.
⇒ geringe Intergrations- und Anpassungskosten

portabel (portable)

Das Softwarepaket sollte einfach auf neue Systeme portiert werden können.
⇒ geringe Kosten bei Änderung der Hardwareumgebung

erweiterbar (extensible)

Erweiterungen der Spezifikation sollten schnell implementiert werden können.
⇒ geringe Wartungskosten

Programmierprinzipien

Um die vorgenannten Ziele zu erreichen, sollten folgende Programmierprinzipien beachtet werden:

Schreibe überprüfbaren Code (Überprüfbarkeit, Veriafiablity)

Die Korrektheit eines Softwarepakets sollte plattformunabhängig sein und automatisch überprüft werden können. Viele Programmierparadigmen und auch Projekttechniken verlangen zu diesem Zweck, dass gleichzeitig mit der Software auch passende Softwaretests implementiert werden. Noch besser ist es, wenn die Semantik des Programmes formal spezifiert und überprüft werden kann (Abstrakte Datentypen, Integritätsbedingungen, ...)
⇒ Korrektheit (insbesondere, wenn die Erfüllung der Spezifikation formal nachgewisen wird)
⇒ Robustheit (wegen ausführlicher Tests)
⇒Portierbarkeit (wegen der Plattformunabhängigkeit)

Schreibe lesbaren Code (Lesbarkeit, Readability)

Der Programmcode sollte so einfach wie möglich gelesen und verstanden werden können. Das heißt der Code sollte sauber formartiert werden, es sollten sprechende Bezeichner verwendet werden, es sollten sinnvolle Kommentare eingefügt werden etc.
⇒Überprüfbarkeit (durch Programmierer und nicht nur durch Compiler u.Ä.) (⇒ Korrektheit, Robustheit)
⇒Wartbarkeit (da die Programme auch von anderen Programmierern verstanden werden)
⇒Erweiterbarkeit (da die Programme auch von anderen Programmierern verstanden werden)

Verwende eine Programmiersprache und -umgebung, die dich beim Schreiben des Codes unterstützt (Schreibbarkeit, Writability)

Der Programmcode sollte so einfach wie möglich geschrieben werden können. Zum einen sollte es die Programmiersprache ermöglichen, einfachen und eleganten Code zu schreiben. Und zum anderen sollten die Programmwerkzeuge einen bei der Erstellung des Codes möglichst gut unterstützen.
⇒Korrektheit (Fehler/Warnungen werden von der Programmierungebung zeitnah gemeldet; der Code oder zumindest ein Codegerüst wird automatisch aus der Spezifikation generiert)
⇒Lesbarkeit (⇒ Überprüfbarkeit, Korrektheit, Robustheit, Wartbarkeit, Erweiterbarkeit)

Schreibe stetigen Code (Stetigkeit, Continuity)

Schreibe den Code so, dass kleine Änderungen an der Spezifikation auch nur kleine Änderungen am Code zur Folge haben.
⇒Warbarkeit (insb. Erweiterberkeit)
⇒Wiederverwendbarkeit (siehe unten)

Teile und herrsche (Divide et impera, Modularität, Modularity)

Ein komplexes Problem (Vorhaben, Projekt, ...) kann man nur dadurch in den Griff bekommen, dass man es solange in kleinere, möglichst unabhängige Teilprobleme (Teilvorhaben, Phasen, Vorgänge, ...) zerlegt, bis diese lösbar (= beherrschbar) sind. Ein Programm sollte daher modularisiert werden. Jedes Modul sollte möglichst nur eine einzige Aufgabe erfüllen.
⇒Warbarkeit (insbesondere Erweiterbarkeit)
⇒Wiederverwendbarkeit (siehe unten)
⇒Überprüfbarkeit (⇒ Korrektheit, Robustheit)
⇒Lesbarkeit (kann bei extensiver Nutzung auch leiden)

Separation of concerns

Bei der Modularisirung eines Softwarepakets sollte man darauf achten, dass jede konkrete Aufgabe von genau einem Modul erfüllt wird. Man muss also die „Verantwortlichkeiten“ unter den Modulen aufteilen, sonst gehen die Vorteile der Modularisierung wieder verloren.

Single responsibility principle

Bei der objektorientierten Programmierung treibt man die Modularisierung manchmal sogar so weit, dass nicht nur für jede Aufgabe höchstens ein Objekt zuständig ist (Separations of Conerns), sondern dass umgekehrt auch jedes Objekt für genau eine Aufgabe zuständig ist (Single responsibility principle).

Separation of concerns, Single responsibility principle,

Quellen

• Kowarschick, W.: Multimedia-Programmierung

Siehe auch

• Software-Engineering

Dieser Artikel ist GlossarWiki-konform.