Die Bevorzugung von Throwaway Code gegenüber Designdokumenten

 (softwaredoug.com)
3 Punkte von GN⁺ 2024-12-16 | 1 Kommentare | Auf WhatsApp teilen

  • Wir stellen uns vor, dass Softwareentwicklung einem sauberen, geordneten Ablauf folgt

    • Man schreibt ein Designdokument und rollt kleine Änderungen per PR aus, um eine Funktion zu implementieren
    • Die Git-Historie wirkt sauber und ordentlich
    • Aber die Realität ist anders

  • Der Unterschied zwischen Designdokumenten und der tatsächlichen Implementierung

    • Ein Designdokument exakt umzusetzen, ist eine Illusion
    • Sobald man mit dem Coden beginnt, überarbeitet man den Inhalt des Designdokuments
    • Kein Plan überlebt den ersten Kontakt mit dem Gegner

  • Eine neue Design-Methodik: Eintauchen ins Coden

    • Mit einem Draft-PR wird ein Prototyp implementiert
    • Früh Feedback einholen und den Ansatz anpassen
    • Den Draft-PR als Dokumentation historischer Designideen nutzen
    • Bereit sein, den Draft-PR komplett zu verwerfen
    • Vom Draft-PR schrittweise zu gestuften PRs übergehen
    • Jeden PR schrittweise testen und die Robustheit verbessern

  • Die Bedeutung von Reife

    • Die Fähigkeit, eine gecodete Idee zu verwerfen, ist wichtig
    • Wichtiger als Codezeilen ist die Weitergabe von organisatorischem Wissen
    • Frühzeitig Einigkeit über die wichtigen Punkte herstellen, damit Prototyp-Arbeit nicht verschwendet wird

  • Wie man PRs als Dokumentation nutzt

    • PRs sind eine der besten Formen der Dokumentation für Entwickler
    • PRs sind historische Artefakte, die den Zustand zu einem bestimmten Zeitpunkt widerspiegeln
    • Designdokumente liefern oft Informationen, die nicht mit der Realität übereinstimmen

  • Die Bedeutung von Prototypen

    • Ein Prototyp ist mehr wert als 1000 Designdokumente
    • Wer Veränderungen vorantreiben will, muss das mit Code tun, nicht mit Dokumenten
    • Eine Organisation sollte Prototypen als Frage und nicht als Antwort betrachten

  • Die Nützlichkeit von Designdokumenten

    • Sie sind nützlich, um Feedback mit verschiedenen Stakeholdern zu organisieren und zu archivieren
    • Sie sind nützlich, wenn eine Idee zu konzeptionell oder zu langfristig ist
    • Sie sind nützlich, wenn es effizienter ist, Ideen schriftlich statt durch Coden auszudrücken
    • Sie sind nützlich, wenn einer Organisation die Disziplin fehlt, die erste Lösung zu verwerfen
    • Sie bieten ein Umfeld, in dem Junior-Mitarbeiter die Ideen von Senior-Entwicklern sicher hinterfragen können

  • Der falsche Einsatz von Designdokumenten

    • Sie werden eingesetzt, um den Prozess für weniger erfahrene Entwickler zu verlangsamen
    • Sie werden als Dokumentation verwendet, veralten aber schnell
    • Sie sollen alle Designprobleme lösen, doch die eigentlichen Probleme werden beim Coden entdeckt

  • Wenn ein Team Disziplin haben kann, ist Hacking deutlich effizienter als Design

    • Es wird empfohlen, eine solche Disziplin in der Organisation zu etablieren
    • Am Ende hat Code mehr Durchschlagskraft als Worte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-12-16
Hacker-News-Meinungen

  • Prototyping ist ein wichtiger Teil des Designprozesses, und es ist notwendig, das Problem zu definieren und die Lösung klar herauszuarbeiten

    • Manchmal reicht ein einfaches Dokument aus, manchmal sind jedoch viel Feedback und viele Iterationen nötig
    • Es gibt das Sprichwort: „Ein paar Wochen Coding können ein paar Stunden Planung sparen“

  • Schreiben ist nützlich, um ein Problem zu erkunden; manche haben erlebt, dass beim Schreiben neue Fragen aufkamen, obwohl sie dachten, das Problem bereits verstanden zu haben

    • Das erinnert an einen Fall, in dem ein Mentor mit Lucidchart sechs Monate Arbeit erklärte

  • Manche haben die Erfahrung gemacht, provisorische Lösungen zu verwenden, um ein Projekt rechtzeitig abzuschließen

    • Diese provisorischen Lösungen werden auch als Tools zur Unterstützung der Produktion verwendet und dienen als Ausweichpfad, falls die permanente Version eingestellt wird

  • Das größte Problem von Design-Dokumenten ist, dass sie niemand liest

    • Das Problem beim Prototyping ist, dass Leute es als endgültigen Code betrachten
    • Bevorzugt wird ein hybrider Ansatz: gründliche Planung und Dokumentation sowie Prototyp-Code in einer Qualität, die im Endprodukt verwendet werden kann

  • Es gibt einen großen Unterschied zwischen Feedback zu Code und zu Design

    • Design-Dokumente führen zu der „Warum“-Frage über den Problemraum
    • Wenn ein Prototyp funktioniert, wird es schwieriger, solche Fragen zu stellen

  • Wenn die Stellenbeschreibung darin besteht, viel Code zu schreiben, um zu sehen, was funktioniert, könnte GPT das schneller und günstiger ersetzen

    • Eine Einigung darüber zu erzielen, was gebaut werden soll, ist immer eine Herausforderung

  • Kaum jemand stellt sich vor, dass Softwareentwicklung einem sauberen und geordneten Ablauf folgt

    • Code schreiben ist dem Schreiben ähnlich; ein erster Entwurf ist immer schlecht, und guter Text wird oft stark überarbeitet

  • Manche haben schon gesehen, dass Code sich wie bei Jenga auftürmt, sodass ihn niemand anfassen möchte

  • Bevorzugt wird ein Prozess, bei dem fortlaufende Kommentar-Threads zur Dokumentation von Design-Entscheidungen genutzt werden

    • Dafür werden GitHub-Issues verwendet

  • Über diesen Ansatz wird noch nachgedacht, und im schlimmsten Fall kann viel Zeit verschwendet werden

    • Das Schreiben von Design-Dokumenten war am nützlichsten, wenn das Problem ausreichend durchdacht war, um die für eine korrekte Implementierung nötigen Eigenschaften festzulegen
    • Es war auch erfolgreich, partielle Lösungen zu implementieren und sie schrittweise zu verbessern