name: designing-before-building description: Verwenden Sie dies, wenn Sie eine Funktion beginnen, einen nicht-trivialen Fehler beheben oder Implementierungscode schreiben möchten – bevor Code existiert. Symptome: "Das ist einfach, ich programmiere es einfach", zum Editor greifen, bevor ein Design genehmigt ist, oder eine Idee, die noch nicht in eine Spezifikation und einen Plan umgewandelt wurde.
Design vor dem Bauen
Überblick
Die Arbeit durchläuft fünf Stufen in dieser Reihenfolge: Brainstorm → Spezifikation → Plan → Ausführen → Aufzeichnen. Keine Implementierung beginnt, bevor ein Design formuliert und genehmigt ist. Die einfachste Aufgabe ist die, bei der ungeprüfte Annahmen am meisten kosten.
Den Buchstaben dieser Regel zu verletzen, verletzt auch ihren Geist. "Ich designe während des Codierens" ist kein Design.
Die fünf Stufen
- Brainstorm. Erkunden Sie Absicht, Einschränkungen, Erfolgskriterien. Stellen Sie eine Frage nach der anderen. Schlagen Sie 2–3 Ansätze mit Kompromissen und einer Empfehlung vor. Einigen Sie sich auf ein Design und holen Sie explizite Genehmigung ein. Hier kein Code.
- Spezifikation. Schreiben Sie das genehmigte Design in ein datiertes Dokument. Die Spezifikation ist der Vertrag für das, was gebaut wird.
- Plan. Zerlegen Sie die Spezifikation in einen geordneten, überprüfbaren Implementierungsplan, bevor Sie Code anfassen.
- Ausführen. Implementieren Sie gemäß Plan mit Überprüfungs-Meilensteinen.
- Aufzeichnen. Destillieren Sie, was gebaut wurde und warum, in einen Entscheidungsnachweis (siehe
recording-decisions).
Große Vorhaben zerlegen. Wenn eine Anfrage mehrere unabhängige Subsysteme umfasst, stoppen Sie und zerlegen Sie, bevor Sie Details verfeinern. Jedes Unterprojekt durchläuft seinen eigenen Zyklus, aufgebaut in Abhängigkeitsreihenfolge.
Wann NICHT verwenden
Wirklich triviale, umkehrbare Bearbeitungen (ein Tippfehler, eine Logzeile, ein Konfigurationswert) überspringen direkt zur Ausführung. Der Test: Würde eine falsche Annahme hier mehr kosten als der Design-Schritt? Wenn ja, zuerst designen.
Häufige Ausreden
| Ausrede | Realität |
|---|---|
| "Das ist zu einfach, um ein Design zu brauchen" | Einfache Aufgaben verbergen Annahmen. Ein paar Sätze Design sind billig; ein Neuschreiben nicht. |
| "Ich designe während des Codierens" | Code, der vor dem endgültigen Design geschrieben wurde, ist Code, der neu geschrieben wird. Design ist ein separater Akt. |
| "Der Benutzer hat mir gesagt, was zu bauen ist, das IST das Design" | Eine Anfrage sagt was, nicht wie. Das Wie ist das Design. |
| "Das zuerst Erkunden der Codebasis zeigt mir den Ansatz" | Erkundung informiert Design; sie ersetzt nicht die Genehmigung eines Designs. |
| "Wir haben es eilig" | Eile ist genau dann, wenn übersprungenes Design Wegwerfarbeit produziert. |
Rote Flaggen — STOPP
- Den Editor öffnen, bevor ein genehmigtes Design existiert
- "Lass mich schnell einen Prototypen bauen" (ein Prototyp ohne Spezifikation ist ungeprüfter Umfang)
- Eine Änderung über mehrere Dateien ohne Plan beginnen
- Die einzeilige Anfrage des Benutzers als fertige Spezifikation behandeln
All dies bedeutet: Stopp, designen, Genehmigung einholen, dann bauen.
Vollständige Begründung: Artikel I der Verfassung, gebündelt in engineering-constitution/references/engineering-constitution.md.