## デザインドキュメントとは？ - ソフトウェアを開発する前に書くドキュメント - 何を・なぜ・どのように作るかを記したドキュメント - 解決策の提案となぜその方法が良いのかを示したドキュメント ## なぜ書く必要があるの？ - 早い段階で設計の問題を見つけることで変更が容易になる - 設計に関するコンセンサスを取る - 横断的関心事に関して検討する - ナレッジの共有 ## 何を書けばいいの？ <aside> 💡 前提として正解はないのでその時に適切な項目を書く </aside> - 目的、背景 - ゴール（とゴールとしないもの） - = requirements - デザイン - overviewを示した後に詳細に入る - トレードオフも記述する - 構成図 - System-context-diagram - APIs - どのようなAPIを持つのか - Data storage - どのようなデータを持つのか - どのようなデータ操作があるのか - Code and pseudo-code - 基本的にはコードは書かない - 新しいアルゴリズムを利用する場合には説明のため擬似コードがあるとわかりやすい - 代替案に関する検討 - トレードオフなどについて示しなぜ選択した設計が良いのかを示す - 既知の問題点 - 懸念点や今後検討が必要な項目について ## 参考リンク - [Design Docs at Google](https://www.industrialempathy.com/posts/design-docs-at-google/) - [Google の Design Doc について](https://please-sleep.cou929.nu/20091116.html) - [Googleのdesign docを眺めてみる](https://kenmaz.hatenadiary.jp/entry/20090712/1247401684)