前回はソフトウェア開発を「製造業へのたとえ」で考えると設計書の立ち位置がよく分からなくなるという話をした。
今回はその続き。
設計書＝ソースコードの説明書？
「ソフトウェアの設計書」は「いわゆる『設計書』」ではなく「ソースコード」という話を書いた。
ただ、ソースコードを読み解くのはなかなか大変だったりする。 というのも、各ソースコードに書かれた内容は断片的で、しかも普通の文章のように順序づけられてないから。 さらにはファイル数自体も多かったり。
そうすると全体像の把握がとても難しく、どこに何が書かれているかを探すのも大変だし、そもそもどこから読み始めたらいいんだとなる。 たとえるなら、ページ番号が入ってないめっちゃ分厚い本の背表紙を破って各ページがバラバラの順序で入っている状態で、その本を読んで理解しないといけない感じ。
もちろん、継続的な開発でソースコードと暮らしているうちに全体像は見えてくるようになるんだけど、それにはかなりの時間と経験が必要になってくる。 それにチームで開発していると自分の知らぬところでコードの内容やファイルの配置が変わってたりすることもあるので、その変更を全部追い続けるというのも無理があったり。
そうなるとソースコードをもっと読みやすい形で表現しておいてほしいとなる。 つまり、機械のレベルではたしかにソースコードが設計書だけど、それだと人間には読みにくいので、人間に読みやすいレベルで表現された設計書が「いわゆる『設計書』」という考え方だ。 さっきソースコードを背表紙の破れた本にたとえたけど、その本に対して目次と各章の概要をまとめたもの、すなわち読み方の説明を提供しているのが「いわゆる『設計書』」と。
この場合、「いわゆる『設計』」は書こうとしている本（＝ソースコード）のアウトラインを作成する作業とも言える。 実際、製造業とかでもいきなり製品の設計図を描き始めるわけではなく、ラフスケッチで製品のデザインや仕様などを詰めていってるはずで、そういった作業に相当するのがソフトウェア開発における「設計」であると。
これは「製造業へのたとえ」での設計の考え方に比べると、だいぶそれっぽい。
ただ、この考え方だとまだ問題があったりする。 それは「設計書が腐る」問題。 これについてはまた次回話したい。
今日はここまで！
