Googleの設計ドキュメント？

Design Docs at Google

Googleではどんなソフトウェア設計しとるの？というのを調べていたら上の記事にあたり、面白かったのでまとめました。
※あんまり設計自体の話はないです…

詳しいところがキニナル人はそんなに長くないのでぐぐる翻訳して見てみてください。

その名も「Design Docs」。これを書くことで、

• 設計上の問題を早期に特定することで時間、金が節約できる。

• 組織内の設計に関するコンセンサスを得る。

• 横断的関心事の考慮を確実にする。

• 上級エンジニアの知識を組織に拡大する。

• 設計上の決定を組織のアセットにできる。

• ソフトウェア設計者の技術ポートフォリオの要約アーティファクトとして機能する。

ここは割りと当たり前のことな気がします。。。
気になる中身を見ていきましょう、章立ては以下の通り。

• 背景とスコープ

• 目標と非目標（何をやらないか明記するの大事！）

• わかりやす図（システムコンテキスト図、DB、APIなどをイラストに）

• 検討された代替案（なんで使わないのか、どこがトレードオフなのか）

• セキュリティ、プライバシなどの考慮事項

特徴的なのは詳しいコード内容には触れず、わかりやすい図を使って説明すること。

それから代替案やトレードオフなど意思決定に関わる部分を重要視していること。

要するに設計ドキュメントは細かい実装方針まで定義して軸にするものではなく

• あらかじめ問題点を洗い出す、コンセンサスをもらうためのもの。

• 設計知のデータベース。

だぜという感じでしょうか。

-長さはどれくらい？

できるだけ詳細に、かつ忙しくても読める分量を目指したい。

大規模プロジェクトであれば10～20p. がちょうど良いそう。

これを超えてしまう場合には課題の切り分けがうまくできていないかも。

-いつも必要なの？

課題またはソリューションが複雑である場合にドキュメントは効果を発揮する。

また、これらに付随する代替案やトレードオフについて述べることが大切。

逆に、解決策も実装もシンプルなものならドキュメントなどいらない！

ここまで読んで面白いなと思った方はぜひ元記事も読んでみてもらえるとよいです！！！