README Driven Development (2010)

• README-gesteuerte Entwicklung: ein Ansatz, bei dem bei der Softwareentwicklung zuerst das README geschrieben wird
• Man hört viel über verschiedene Entwicklungsmethoden und -techniken wie TDD, BDD, Extreme Programming und SCRUM
  • Aber wenn die Software, die wir entwickeln, die Bedürfnisse der Nutzer nicht erfüllt, ist all das bedeutungslos
  • Selbst eine perfekte Implementierung ist wertlos, wenn sie einer falschen Spezifikation folgt, und auch eine schöne, aber undokumentierte Bibliothek ist fast wertlos
  • Wenn Software das falsche Problem löst oder man nicht herausfinden kann, wie sie zu benutzen ist, entsteht ein ernstes Problem

Lösung: Zuerst das README schreiben

• Warum man zuerst das README schreiben sollte
  • Bevor man Code, Tests, Stories usw. schreibt, sollte man zuerst das README verfassen
  • Das Schreiben des README ist ein notwendiger Schritt, um gute Software zu erstellen
  • Solange man die Software nicht schriftlich beschrieben hat, ist nicht klar, was man überhaupt programmieren wird
  • Durch das README kann man systematisch über das Projekt nachdenken
• Vorteile eines README-first-Ansatzes:
  • Gelegenheit, systematisch über das Projekt nachzudenken:
    • Man kann systematisch über das Projekt nachdenken, ohne Code ändern zu müssen
    • Vor dem Codieren kann man sich Gedanken über die Struktur des Projekts und die enthaltenen APIs machen
  • Hochwertige Dokumentation sicherstellen:
    • Man kann die Dokumentation zu einem frühen Zeitpunkt des Projekts schreiben, wenn Motivation und Interesse noch hoch sind
    • Das README später zu schreiben ist langweilig, und dabei können wichtige Details übersehen werden
  • Höhere Effizienz in der Teamarbeit:
    • Andere Entwickler im Team können schon vor Fertigstellung des Projekts Informationen über die Schnittstelle erhalten und selbstbewusst mit anderen Aufgaben beginnen
    • Arbeitet man ohne klare Schnittstelle, kann eine umfangreiche Überarbeitung des Codes nötig werden
  • Eine Grundlage für konkrete Diskussionen bieten:
    • Schon durch den einfachen Akt, einen vorgeschlagenen Lösungsansatz als Text festzuhalten, können alle mit einer klaren Vorstellung diskutieren
• Merkmale von README Driven Development (RDD):
  • RDD kann als Teilmenge oder eingeschränkte Version von Documentation Driven Development (DDD) betrachtet werden
  • RDD begrenzt das Designdokument auf eine einzelne Datei und verhindert so Probleme durch übermäßiges Spezifizieren
  • Es fördert die Pflege kleiner, modularer Bibliotheken

Fazit

• Betrachte den Prozess des Schreibens eines README als echten „kreativen Akt“
• In diesem Dokument sollten all deine originellen Ideen zum Ausdruck kommen, und das Dokument selbst sollte als Beleg für Kreativität und Ausdruckskraft dienen
• Das README sollte das wichtigste Dokument in der Codebasis sein, und es zuerst zu schreiben ist der richtige Ansatz

[princox]

Ob Software, Roman oder Film – wenn man jede Form von kreativem Werk vorab auf dem Papier entwirft und plant, kann man wohl leichter auch die detaillierteren Aspekte im Blick behalten. :)

[markman]

Ich habe das Allereinfachste die ganze Zeit über vergessen, aber jetzt sollte ich es wirklich in die Praxis umsetzen.

[halfenif]

Wir haben beschlossen, es „Grunddesign“ zu nennen.

[gargoyle92]

Das ähnelt unbeabsichtigt der Art und dem Kontext, in dem ich arbeite.
Dieser Teil scheint in Form eines "README" als Ergebnis herauszukommen.

Wenn ich arbeite, schreibe ich What, Why, How usw. klar auf und gehe dann voran, während ich die Form der noch zu erledigenden Aufgaben nach und nach festlege — insofern ist es ähnlich.

[kandk]

README-gesteuerte Entwicklung

[dbs0829]

Wir sind eine Forschungsorganisation, daher habe ich oft darüber nachgedacht, wie wir Forschungsergebnisse in Form von Code veröffentlichen können. README-Driven Development scheint daher gut zu uns zu passen. Es wirkt wie ein Ansatz, über den man schon in der Anfangsphase eines Forschungsvorhabens nachdenken sollte.

[jamsya]

Ähnlich mache ich es auch beim Backend: Ich schaue mir den Bildschirm an und schreibe zuerst grob die API-Dokumentation.
Das hat ziemlich dabei geholfen, Trial-and-Error zu reduzieren.

[bbulbum]

Irgendwie wirkt es so, als würde das die Bedeutung unterstreichen, das zu lösende Problem zuerst präzise zu definieren.

[xguru]

Der Artikel ist zwar aus dem Jahr 2010, aber ich habe ihn beim Lesen eines anderen Beitrags entdeckt und dachte, ich teile ihn mal.