Kaltblütige Software

 (dubroy.com)
3 Punkte von GN⁺ 2023-12-29 | 1 Kommentare | Auf WhatsApp teilen

Software mit kaltem Blut

  • Im Jahr 2004 besucht der Autor, der Informatik studiert, eine Vorlesung zur Naturgeschichte, als der Professor ein eingefrorenes Jungtier einer Schmuckschildkröte zeigt.
  • Diese Schildkröte ist eine der wenigen Arten, die selbst im gefrorenen Zustand überleben können, und ein kaltblütiges Tier, das seinen Stoffwechsel bei niedrigen Temperaturen regulieren kann.
  • Während der Vorlesung beobachtet der Autor, wie sich die Schildkröte langsam bewegt und wieder zum Leben erwacht, was sein Verständnis für kaltblütige Tiere vertieft.

Die Dichotomie von Softwareprojekten

  • Auch Softwareprojekte lassen sich in warmblütige und kaltblütige Projekte einteilen.
  • Warmblütige Projekte benötigen kontinuierliche Aktivität; wenn diese ausbleibt, entstehen Probleme.
  • Kaltblütige Projekte können auch nach längeren Phasen geringer Aktivität wieder aufgenommen werden und sofort dort anknüpfen, wo sie zuvor standen.

Kaltblütige Software im Blog

  • Die Software, die den Blog des Autors betreibt, ist kaltblütige Software.
  • Dieses vor 12 Jahren gestartete Projekt ist einfach, hängt nicht von externen Diensten ab, und alle Abhängigkeiten sind im Projekt-Repository enthalten.
  • Abgesehen von einigen kleinen Verbesserungen funktioniert es ohne Änderungen zuverlässig und wird voraussichtlich auch in den nächsten 12 Jahren weiterlaufen.

Meinung von GN⁺

  • Das Konzept der kaltblütigen Software hat wichtige Auswirkungen auf die Nachhaltigkeit und Wartbarkeit von Projekten.
  • Der Text liefert Einblicke, wie die Wahl des Technologie-Stacks die Lebensfähigkeit eines Projekts beeinflusst.
  • Die Erfahrungen des Autors geben Softwareentwicklern Hinweise darauf, wie sich langfristig stabile Systeme aufbauen lassen.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-29
Hacker-News-Kommentar

  • Im Node- und JavaScript-Ökosystem gibt es das Express-Web-Framework. Der aktuelle Hauptversionszweig 4.x.x ist inzwischen über 10 Jahre alt und wird pro Woche mehr als 17 Millionen Mal heruntergeladen. Es fehlen zwar einige Funktionen und die Performance ist nicht die beste, aber es ermöglicht eine schnelle und stabile Entwicklung, und viele Entwickler bevorzugen es, weil sie langfristig planen können, ohne sich über API-Änderungen oder fehlende Sicherheitspatches Sorgen machen zu müssen. Die Sprache Go bietet dank ihrer umfangreichen Standardbibliothek und ihres Kompatibilitätsversprechens noch bessere Stabilität, sodass auch Programme, die über 10 Jahre alt sind, weiterhin laufen.

  • Wenn Software auch ohne Updates gut funktioniert, wurde sie von Anfang an richtig gebaut. Bei Software, die man nur selbst verwendet, ist das vergleichsweise einfach, weil sich die eigenen Vorlieben nicht stark ändern. Wenn man jedoch Software für andere schreibt, können die Anforderungen anders sein und unerwartete Probleme auftreten. Zum Beispiel kann es bei der Verarbeitung großer Dateien zu Abstürzen kommen, und um das zu beheben, muss man möglicherweise die Hälfte der Software neu schreiben. Das ist das stärkste Gegenargument gegen die Behauptung, Software sei automatisch besser, nur weil sie sich nicht häufig ändert.

  • Python ist wegen seiner fortlaufenden inkompatiblen Änderungen ein schlechtes Beispiel. Go oder Java sind dagegen Beispiele dafür, dass auch 10 Jahre alter Code mit modernen Tools gut funktioniert. Perl ist ein noch besseres Beispiel, weil selbst 30 Jahre alter Code weiterhin problemlos läuft.

  • Ich arbeite mit IBM-Mainframes (z/OS). IBM ist mit Abstand am besten darin, Abwärtskompatibilität zu erhalten. Microsoft (Windows) liegt auf Platz zwei, Linux mit seiner Kernel-ABI auf Platz drei. Bei den meisten anderen Systemen ist mangelnde Kompatibilität ein häufiges Problem, besonders bei OSS, wo man oft keine Zeit in deren Erhalt investieren will.

  • Abhängigkeiten können eine App zu "warmblütiger" Software machen, aber Docker oder Containerisierung können diese Probleme bis zu einem gewissen Grad lösen. Wenn ich Bibliotheken für ein Projekt auswähle, recherchiere ich gründlich, ob es sich um eine "kaltblütige" Bibliothek handelt.

  • Viele Engineer schauen auf GitHub bei der Suche nach Bibliotheken auf den Zeitpunkt des letzten Commits. Je aktueller der Commit, desto besser unterstützt sei das Projekt, so die Annahme. Aber ein archiviertes Projekt zu finden, das lange stabil gepflegt wurde und keine Bugs hat, ist wie das Finden eines versteckten Juwels im Secondhandladen.

  • Ich pflege mein eigenes Side-Project. Es begann vor 12 bis 13 Jahren und wurde in PHP, Laravel und Symfony neu geschrieben. Es war sehr wertvoll, um zu lernen, wie man ein Projekt langfristig wartbar hält. Zum Beispiel suche ich gezielt nach Gelegenheiten zur Vereinfachung, etwa von Vagrant zu Docker oder von Vue + Axios + Webpack hin zu Htmx. Kürzlich habe ich auf PHP 8.2 und Symfony 7 aktualisiert und ChatGPT-basierte Funktionen integriert.

  • Ich habe es satt, dass mobile Apps in den letzten Jahren alle paar Stunden Patch-Arbeit brauchen. Der Autor beschreibt seinen statischen Site-Generator als "kaltblütig"; er läuft auf Python 2, aber die Installation von Python 2 wird zunehmend schwieriger.

  • Ein SDK, das ich 1994/95 geschrieben habe, war noch im Einsatz, als ich 2017 das Unternehmen verließ. Es wurde in ANSI C geschrieben, und auch Dinge, die ich in PHP (5) geschrieben habe, laufen unter PHP 8.2 noch gut. Solche Dinge sind allerdings langweilig und haben wenig Buzz.

  • Neben dem, was im Artikel erwähnt wird, ist auch ein inhärent sicheres Bedrohungsmodell wichtig. Eine komplette Website ist zum Beispiel von Natur aus "warmblütig", weil sie sich ständig mit Angreifern, Spam-Bots usw. auseinandersetzen muss. Statische Seiten wie Tiddlywiki sind dagegen viel besser, weil sie nicht ins Web gestellt werden müssen und der Browser eine sehr stabile Plattform ist.