設計ドキュメントより Throwaway Code が好まれる現象
(softwaredoug.com)-
私たちは、ソフトウェア開発がクリーンで秩序ある流れに従うことを思い描く
- 設計ドキュメントを書き、小さな変更を PR としてロールアウトしながら機能を実装する
- Git の履歴はきれいで整然として見える
- しかし現実は違う
-
設計ドキュメントと実装の差
- 設計ドキュメントをそのまま実装するのは幻想である
- コーディングを始めると、設計ドキュメントの内容を修正することになる
- 計画は敵との接触を生き延びられない
-
新しい設計手法: コーディングへの没入
- ドラフト PR を使ってプロトタイプを実装する
- 初期にフィードバックを受けてアプローチを調整する
- ドラフト PR を歴史的な設計アイデアとして文書化する
- ドラフト PR を完全に捨てる覚悟を持つ
- ドラフト PR から段階的に PR を進めていく
- 各 PR を段階的にテストし、堅牢性を補強する
-
成熟の重要性
- コーディングしたアイデアを捨てられる能力が重要である
- コード行数ではなく、組織的な知識の伝達が重要である
- 重要な部分について早い段階で足並みをそろえ、プロトタイプ作業が無駄にならないようにする
-
PR をドキュメントとして使う方法
- PR は開発者にとって最良の文書化形式の一つである
- PR は特定時点の状態を反映する歴史的な成果物である
- 設計ドキュメントはしばしば現実と異なる情報を提供する
-
プロトタイプの重要性
- プロトタイプは 1000 本の設計ドキュメントより価値がある
- 変化を主導するには、ドキュメントではなくコードで行うべきである
- 組織はプロトタイプを答えではなく問いとして捉えるべきである
-
設計ドキュメントの有用性
- さまざまな利害関係者からのフィードバックを整理し、アーカイブするのに有用である
- アイデアがあまりに概念的、または長期的すぎるときに有用である
- コーディングより文章でアイデアを表現する方が効率的なときに有用である
- 組織に最初の解決策を捨てられる規律がないときに有用である
- ジュニア社員がシニア開発者のアイデアに安全に疑問を投げかけられる環境を提供する
-
設計ドキュメントの誤った使い方
- 経験の浅い開発者に対して、プロセスを遅らせるために使われる
- 文書化として使われるが、すぐに陳腐化する
- すべての設計問題を解決しようとするが、実際の問題はコーディングを通じて発見される
-
チームが規律を持てるなら、ハックは設計よりはるかに効率的である
- 組織内でこのような規律を作ることを勧める
- 結局、コードは言葉よりも大きな力を持つ
1件のコメント
Hacker Newsの意見
プロトタイピングは設計プロセスにおける重要な要素であり、問題を定義して解決策を明確にすることが必要
書くことは問題を探るうえで有益であり、問題を理解したと思っていても、書いているうちに新たな疑問が生じた経験がある
プロジェクトを期限内に完了するために一時的な解決策を使った経験がある
設計文書の最大の問題は、誰も読まないこと
コードに対するフィードバックと設計に対するフィードバックには大きな違いがある
何が有効かを見るために大量のコードを書くことが職務内容なら、GPTがより速く安く代替できる
ソフトウェア開発が、きれいで整然とした流れに従うと考える人はほとんどいない
コードがJengaのように積み上がり、誰も手を付けたがらなくなるケースを見たことがある
継続的なコメントスレッドを使って設計上の判断を文書化するプロセスを好む
このアプローチについて考えており、最悪の場合は多くの時間を無駄にする可能性がある