ds-blueprint

ds-blueprint

本体を書く前にコードの形を固め、モデルがその場で計画を作り出すのではなく、計画を埋めるようにします。

手順

1. まず全体を把握します。新しいコードが触れるすべてのモジュールを読みます。それらがどのように連携するか説明できない場合は、先に /ds-explain を実行します。周囲にシステムがないコードの場合に限り、この手順を省略します。
2. 構造の異なるスケッチを少なくとも 2 つ作成します。各スケッチは、型、シグネチャ、モジュール境界、「not implemented」を発生させるスタブ本体、短い疑似コードを含む実際のファイルで構成します。設計が重要な場合は、/ds-best-of-n を使って並行して作成します。
3. スケッチを比較します。公開範囲が小さく、内部に多くを隠せるものを優先します。単一ファイルだけを見ると正しそうな変更が、リポジトリ全体でも正しいものを優先します。採用しなかった案とその理由を記録します。
4. 選んだスケッチに対して型チェッカーまたはコンパイラーを実行します。出力を貼り付けます。スタブはコンパイルできなければなりません。
5. 選んだスケッチをユーザーに提示し、実装を埋める前に合意を待ちます。無人実行の場合は、代わりに /ds-ledger で選択を記録します。
6. スタブを 1 つずつ実装します。実装のたびに型チェッカーと関連するテストを実行します。スケッチが間違っていると判明した場合は、作業を止め、本体だけでなくスケッチを修正します。
7. 残ったスタブ、使われていないスケッチ、未使用の型を削除します。「not implemented」を grep し、残っていないことを確認します。

次の場合に停止します

• すべてのスタブを実装し、型チェッカーとテストが成功し、その出力も提示されている場合。
• または実装中にスケッチの修正が 3 回必要になった場合。この場合は停止し、ユーザーと再設計します。

ルール

• シグネチャを変更できるのは、手順 6 の修正手順を通じてのみです。黙って変更してはいけません。
• 各スケッチファイルは、一度に読み通せる小ささに保ちます。
• 証拠となるのはコンパイラーとテストの出力であり、「動くはずです」という説明ではありません。