joshavg

Über die Wartung von Code: S.O.L.I.D. oder S.T.A.B.L.E.

Erklärtes Ziel der objektorientierten Programmierung ist bekanntermaßen, die reale Welt mit Objekten nachzustellen. Objekte stellen dabei meist Sammlungen von Eigenschaften dar, die Fähigkeiten besitzen. Dass, und warum, bei der Umsetzung eines solchen Objektmodells einiges schiefgehen kann, muss man sicherlich niemandem erklären.

Um dieser Tendenz entgegenzuarbeiten, es wird an der Stelle auch gerne von Erosion gesprochen, wurden von Robert C. Martin fünf Prinzipien für ein gutes objektorientiertes Design entwickelt, die jeder Programmierer kennen sollte. Zusammengefasst werden sie als SOLID:

  1. Single responsibility principle
    Eine Komponente sollte genau eine Zuständigkeit besitzen.
  2. Open closed principle
    Komponenten sollten offen für Erweiterungen, aber geschlossen für Veränderungen sein.
  3. Liskov substitution principle
    Objekte sollten durch Instanzen ihrer Kinder ersetzbar sein, ohne die Korrektheit des Programms zu beeinflussen. Benannt nach Barbara Liskov.
  4. Interface segregation principle
    Ein Objekt sollte nicht gezwungen sein, Schnittstellen zu besitzen, die es nicht benötigt.
  5. Dependency inversion principle
    Abstrakte Objekte sollten nicht von konkreten abhängig sein.

Diese fünf Prinzipien, so man sie denn korrekt befolgt, führen zu einem prinzipiell wartbaren und gut verständlichem Softwareprojekt. Nun ist es allerdings so, dass es einen weiteren Grundsatz gibt:

Software wird öfter gelesen als ausgeführt.

Das bedeutet, dass in die Wartung großer Projekte sehr viel Zeit reinfießt; und weil Wartung viel Geld kostet und die User sich an ihre Software gewöhnt haben und, und, und... starten Projekte selten auf der sprichwörtlichen grünen Wiese, fangen also selten bei 0 an. Das beudetet, man findet oftamls über Jahre gewachsene Strukturen vor, die unter den verschiedensten Faktoren entwickelt wurden und von Entwicklern verschiedensten Könnens gewartet werden.

Was das mit SOLID zu tun hat? Die oben genannten Prinzipien sind sehr grundlegende, tiefgreifende architektonische Richtlinien. Es bedeutet viel Aufwand sowohl in Sachen Programmierung als auch Testen, ein Dependency inversion principle in ein Projekt einzubauen, das bereits seit fünf Jahren prima ohne auskommt. Wie schon an der Formulierung zu erkennen ist, ist der Mehrwert oftmals auch zweifelhalt gering. Woran soll man sich nun also halten, was ist die Mao-Bibel des Legacy-Entwicklers?

Die Softwareentwicklerin Sarah Mei aus den USA schlug für die Wartung von bestehender Software eine andere Abkürzung vor, STABLE:

  1. Smell your code
    Wie man an einem Wein zuerst riecht, soll man sich mit der Codebasis, an er man arbeiten soll, vorher vertraut machen. Was sind bekannte Probleme, was kann man schnell verbessern?
  2. Tiny problems first
    In gewachsenen Projekten gibt es viele Probleme, vieles riecht. Statt den großen Umbau, mit dem man erst Tage später vielleicht fertig ist, zu starten, sollte man die kleinen Probleme zuerst angehen. Erst wenn man die ganzen kleinen Ärgernisse beseitigt hat, kann man das große Ganze korrekt einschätzen.
  3. Augment tests
    Bevor man große Komponenten anfasst und von Problemen bereinigt, muss man das korrekte Verhalten definieren und mit automatischen Tests validieren. Erst dann kann man sicher Korrekturen vornehmen.
  4. Back up
    Sind Objekte zu abstrakt und Funktionen zu verkapselt, sollte die Codebasis erstmal in eine einfachere Form, beispielsweise prozedural, gebracht werden. Danach kann man sich um all die Duplikationen und Kapselungen kümmern und so ein neues Design entwerfen.
  5. Leave it better than you found it
    Auch unter dem Namen Pfadfinderregel bekannt. Code, den man verwüstet vorfindet, aber an dem man nicht unbedingt Änderungen vornehmen muss, sollte man trotzdem aufräumen und so für den nächsten Entwickler, vielleicht man selbst, besser hinterlassen.
  6. Expect good reasons
    Man sollte immer davon ausgehen, dass Entwickler gute Gründe für das haben, was sie tun. Vielleicht steckt hinter abstrusen Konstruktionen ein tieferer Sinn oder eine Funktion, die man so nicht erahnt hätte. Außerdem ist es gut für die Teammoral, wenn man nicht sofort seinen Kollegen anschimpft, warum Code aussieht, wie er es tut.

Vielleicht können mehr Entwicklerteams diese Prinzipien beachten, wenn sie es mal wieder mit urtümlichen Code nach alter Väter Sitte zu tun haben. Die Folien, inklusive Transkript, des hervorragenden Vortrags, von dem ich diese Informationen habe, sind hier zu finden: Speakerdeck.

Epigramme von Alan J. Perlis

1982 verfasste der US-amerikanische Informatiker Alan J. Perlis etwas über 100 Epigramme über das Programmieren. Meine Quelle hierfür ist ein Eintrag bei archive.org. Hier einige ins Deutsche übersetzt:

1: One man's constant is another man's variable.

Was für den einen eine Konstante ist, ist für den anderen eine Variable.

5: If a program manipulates a large amount of data, it does so in a small number of ways.

Verändert ein Programm große Mengen an Daten, tut es dies in einer geringen Menge an unterschiedlichen Schritten.

6: Symmetry is a complexity reducing concept; seek it everywhere.

Symmetrie ist ein Konzept, das Komplexität verringert. Strebe danach.

7: It is easier to write an incorrect program than understand a correct one.

Es ist einfacher, ein falsches Programm zu schreiben, als ein falsches zu verstehen.

40: There are two ways to write error-free programs; only the third one works.

Es gibt zwei Möglichkeiten, ein fehlerfreies Programm zu schreiben. Nur die dritte funktioniert.

63: When we write programs that "learn", it turns out we do and they don't.

Wenn wir Programme schreiben, die "lernen", stellt sich heraus, dass wir diejenigen sind, die lernen.

79: A year spent in artificial intelligence is enough to make one believe in God.

Ein Jahr im Bereich Künstliche Intelligenz zu verbringen, ist genug, einen an Gott glauben zu lassen.

104: The proof of a system's value is its existence.

Der Beweis für den Wert eines Systems ist dessen Existenz

114: Within a computer natural language is unnatural.

Innerhalb eines Computers sind natürliche Sprachen unnatürlich.

Neustart der Seite

Nach langer Zeit der Inaktivität und technischer Stagnation habe ich diese Seite auf eine neue technische Basis gebracht. Diesmal basiert diese Seite nicht mehr auf meinem selbst gebauten CMS, sondern ist technisch und optisch bewusst schlicht gehalten. Es handelt sich um picocms, einem CMS ohne Datenbank. Stattdessen werden Beiträge in markdown-Dateien verfasst und abgespeichert. Das Seitentemplate wird mit Hilfe von twig-Templates gestaltet. Diese Templateengine stammt von den Machern von symfony, sensiolabs, und ist sehr durchdacht, umfangreich und gut zu benutzen. Insgesamt erscheint mit picocms sehr durchdacht und, wenn teilweise auch leicht umständlich, gut benutzbar. Hinzu kommen meine persönlichen Präferenzen in Sachen Templating und Auszeichnungssprache. Insgesamt also eine vielversprechende Wahl.

Zum Inhalt der Seite: Die alten Unterseiten werden verschwinden. Der Inhalt ist einfach veraltet und nicht mehr interessant. Ich kann mich mit denen nicht mehr identifizieren. Stattdessen soll diese Seite zu einem Blog werden. Mal schauen, wie sich das so entwickelt.

Was ist ein Yottabyte?

Was ist ein Yottabyte? Wieviel ist das? Wie kann man sich so eine Zahl vor Augen halten?

Zur Verdeutlichung, die Reihenfolge der Binärpräfixe ist:

  1. Kilo
  2. Mega
  3. Giga
  4. Tera
  5. Peta
  6. Exa
  7. Zetta
  8. Yotta

Wie kann man so eine gigantische Menge von Bytes nachstellen? Die Überlegung stammt von Anfang 2011, da waren Terabytefestplatten so langsam üblich. Also nimmt man eine entsprechend große Menge solcher Datenträger und vergleicht diese mit bekannten Größen.

Die nachfolgende Liste an Rechnungen und Beispielen haben keinerlei Anspruch auf Korrektheit, Praxisnähe oder Machbarkeit. Als Berechnungsgrundlage dient meine alte eigene 1TB-Festplatte - Typ Samsung HD 103 SJ.

Wer kann sich jetzt ein Yottabyte vorstellen?