2024: Wie ich programmiere

 (akkartik.name)
2 Punkte von GN⁺ 2024-08-06 | 1 Kommentare | Auf WhatsApp teilen
  • Ich habe darüber gesprochen, wie man Programme auswählt, die lange nutzbar bleiben, und wie man eine vertrauenswürdige Infrastruktur aufbaut, muss aber eingestehen, dass ich darin immer noch nicht besonders gut bin
  • Im letzten Monat habe ich den Kern eines Programms, das ich in den vergangenen zwei Jahren benutzt habe, neu geschrieben und dabei auf die Veränderungen meines Programmierens im Laufe meines Lebens zurückgeblickt

2015

  • Ich stand Abstraktionen skeptisch gegenüber und legte Wert auf Tests und Versionsverwaltung
  • Ich hielt den Missbrauch von Abstraktionen und den Mangel an Tests/Versionsverwaltung für die Ursache der Probleme
  • Ich entwarf die Plattform Mu1 mit Tests und Layern als grundlegenden Einschränkungen

2017

  • Beginn der Überarbeitung von Mu1 zum heutigen Mu
  • Anfangs nutzte ich alle neuen Ideen zu Tests und Layern, stellte ihre Nutzung aber nach und nach ein
  • Mu hat viele Tests, aber in herkömmlicher Form, und die Layer-Infrastruktur wurde nicht portiert

2022

  • Beginn der Arbeit an Freewheeling Apps
  • Zunächst ohne Tests gestartet, dann aber gründliche Tests für die Kernteile des Texteditors geschrieben
  • Der Rest ließ sich nur schwer testen, funktionierte aber gut

2024

  • Vor einem Monat habe ich alle Tests gelöscht
  • Ich habe den Texteditor radikal überarbeitet – auf eine Weise, bei der ich mir Sorgen über Merge-Konflikte mit anderen Freewheeling Apps gemacht hatte
  • Ich mache mir keine Gedanken mehr über Versionsverwaltung
  • Ich habe Tests und Versionen aufgegeben und dadurch ein deutlich besseres Programm geschaffen

Meine aktuelle, integrierte Sicht auf nachhaltiges Programmieren

  1. Nachhaltig für viele Menschen zu entwickeln ist zu schwierig, also sollte man es gar nicht erst versuchen
  2. Die meiste Software ist von Anreizen infiziert, kurzfristig vielen Menschen dienen zu wollen. Konzentriere dich auf Software mit weniger Logos, die leicht zu bauen ist, wenige Abhängigkeiten hat und keine automatischen Updates durchführt
  3. Kleine Änderungen im Kontext können grundlegend verändern, wie gut ein Programm zu seinem Kontext passt
  4. Neue Programme führen uns auf die eine oder andere Weise ins Unbekannte. Oft wissen wir nicht genau, was wir eigentlich tun, egal in welche Richtung wir gehen
  5. Typen, Abstraktionen, Tests, Versionen, Zustandsmaschinen, Immutability, formale Analyse usw. sind Werkzeuge, die man in unbekanntem Gelände einsetzen kann
  6. Unvermeidlich wird man einige dieser Werkzeuge übermäßig einsetzen. Der ideale Einsatz ist viel geringer, als wir denken. Übernutzung ist technische Schuld
  7. Wenn sich das Verständnis des Kontexts stabilisiert, ist es wertvoll, einen beträchtlichen Teil des Programms wegzuwerfen und von vorn zu beginnen
  8. Vor dem Neuschreiben muss man alles, was man vom Programm will, und alle Szenarien, die das Programm bewältigen muss, gleichzeitig im Kopf haben
  9. Baue alles auf einmal
  • Tests und Versionsverwaltung stehen dem Erreichen des Endpunkts dieser Entwicklung im Weg
  • Tests lassen einen Bedenken vergessen, und Versionsverwaltung lässt einen an der Vergangenheit hängen

Meinung von GN⁺

  • Wenn ein Programm zu komplex wird, kann es unmöglich werden, in Schritt 8 alles im Kopf zu behalten. Das gilt für die meiste Software, besonders für Software, die von mehr als einer Person geschrieben wurde
  • Nicht jede Software muss zwangsläufig Schritt 9 erreichen. Viele Freewheeling Apps sind einfach genug und entwickeln sich langsam genug, dass sie sich schon bei nur wenigen Nutzern zu einem bugfreien Zustand stabilisieren können – unabhängig von frühen Designentscheidungen
  • Um Schritt 9 zu erreichen, ist datenorientiertes Design eindeutig hilfreich. Es ist kein Werkzeug, das man blind anwenden kann, sondern eine Denkweise, die über immediate data structure choices hinaus auf das große Ganze schaut, wie ein Programm auf Daten zugreift
  • Diese Schritte sind vielleicht nicht vollständig richtig. Möglicherweise werden Werkzeuge unterschätzt, mit denen man weniger Erfahrung hat
  • Ich frage mich, welche Schritte es jenseits dieser Schritte noch geben könnte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-06
Hacker-News-Kommentare

  • Ohne Tests sieht man Probleme nicht, sodass es so wirkt, als gäbe es sie nicht

    • Beim Testen wurden immer Bugs gefunden
    • Wenn man Tests löscht, täuscht man sich selbst
    • Nach dem Lesen der Seite entsteht der Eindruck, dass der Autor von Mutations-/Konfigurationsmanagement erschöpft ist
    • Man kann nur Geld verdienen, wenn man viele Nutzer hat

  • Durch den Verzicht auf Tests und Versionen entstand ein besseres Programm

    • 2024 keinen Source-Code-Management zu verwenden, ist nicht nachvollziehbar
    • Die Funktionen, auf mehreren Geräten zu arbeiten, die Historie einzusehen, Rollbacks durchzuführen und Branches zu erstellen, sind sehr nützlich

  • Zuerst dachte ich, der Autor liege falsch, aber es gibt gute Einsichten

    • Dieser Workflow passt gut zum Autor
    • Er dürfte erlebt haben, dass Git oder automatisierte Tests die Produktivität senken
    • Es gibt auch einfache Alternativen (z. B. Dropbox, FTP)
    • Der Autor erstellt gern kleine Programme
    • Automatisierte Tests sind nützlich, aber im Fall des Autors zeigt sich ihr Wert möglicherweise nicht

  • Versionsverwaltung und automatisierte Tests lösen reale Probleme

    • Heutzutage ein Projekt ohne Versionsverwaltung zu beginnen, ist verrückt
    • Automatisierte Tests sind Best Practice
    • Für den spezifischen Anwendungsfall des Autors könnte es vernünftig sein

  • Beim Schreiben/Refactoring großer Programme ist es wichtig, zu schreiben, wegzuwerfen und neu zu schreiben

  • Dieser Artikel ist verwirrend

    • Ich frage mich, warum er als Erster hochgevotet wurde

  • Kleine Änderungen können die Eignung eines Programms stark verändern

    • Es gibt das Beispiel von K9 Mail
    • K9 Mail begann mit einer unkonventionellen UI
    • Viele Nutzer waren mit der neuen UI unzufrieden
    • Eine kleine Änderung zerstörte die Eignung der App
    • Ich verwende noch immer die alte Version

  • Allein Software zu entwickeln und im Team zu entwickeln, ist völlig unterschiedlich

    • Tests sind ein Mittel, nicht das Ziel
    • Wenn man zuversichtlich ist, testet man weniger
    • Für wichtige Teile werden Integrationstests hinzugefügt
    • Für das Design neuer APIs sind Unit-Tests nützlich

  • 2022 begann die Arbeit an Freewheeling Apps

    • Das Fehlen von Tests war frustrierend
    • Eine Test-Suite gibt Vertrauen, das System weiterzuentwickeln
    • Mit zunehmender funktionaler Komplexität werden Tests schwieriger
    • 2024 wurden alle Tests gelöscht
    • Diese Philosophie gilt nur für eine einzelne Person

  • Ich stimme nicht zu, dass kleine Änderungen die Eignung eines Programms stark verändern können

    • Kurzfristiges Denken dient dazu, sich an kleine Änderungen anzupassen

  • Ich mag den Autor und mag das Mu-Projekt

    • Es ist eine moderne Lisp-Maschine

  • Ich bin von der Komplexität des Software-Engineerings überwältigt

    • Alle Ideen zurückzuweisen, ist keine Lösung
    • Man sollte Tests schreiben, VCS verwenden und Abstraktionen nutzen
    • Man sollte wissen, warum man sie verwendet, und sie neu bewerten, wenn es keinen Grund dafür gibt