ソフトウェア設計書は「書くため」ではなく、後戻りを防ぐためにある
ソフトウェア開発では、コードを書く前に設計を言葉にしておくことがある。今回取り上げる記事は、その「design doc（設計書）」をどう書けば役に立つのかを、実務経験に基づいて整理したものだ。単なる文書作法ではなく、どの場面で書くべきか、何を入れて何を入れないかまで踏み込んでいるのが面白い。設計書を“面倒な儀式”として扱う人ほど、読み直す価値がある内容だと思う。 元記事の筆者 Michael Lynch は、Google、Microsoft、自分の会社で design doc を書いてきた経験から、効果的な設計書の書き方をまとめている。主張の軸はかなりはっきりしていて、design doc は「実装前に大事な判断を洗い出し、チーム内の認識を合わせるための道具」だという。雑にコードを書き始めてしまうと、あとで間違った方向に大きく進んでしまうことがある。設計書はそれを防ぐ。 記事では、筆者が実際に作った例として、キャッシュ層を追加する web app の設計書も示されている。コードを書く前に設計書を作り、その設計に沿って実装を進めている点が印象的だ。しかも、その文書は趣味の一人開発なら少し
papoo.work