前回は、人間には読みにくいソースコードの説明を与えるのが、いわゆる「設計書」ではないかという考えを紹介した。
ただ、この考え方はまた別の問題を生み出してしまう。
腐る設計書？
ソフトウェアは作って終わりというものではなく、作ったあともバグ修正や機能追加が入るのが普通だったりする。 そのとき、ソースコードを調査する必要が出てくるわけだけど、前述のとおり、ソースコードを読み解いていくのは大変。 そこで「そんなこともあろうかと」用意しておいた設計書を読むわけだけど、大抵はそこで絶望することになる。
なぜって、「設計書に書かれている内容と現状のソースコードが乖離している」ことがよくあるから。
ソースコードを書く前に設計書を書くわけだけど、設計書のとおりにはうまくいかず、ちょっと違ったソースコードになるというのはよくあることだし、一度書いたあともソースコードが変更されるということはよくある。 けど、そうやってソースコードに変更が入ったとき、そのフィードバックを設計書にまで反映させるということは大抵されない。 実際、反映させようと思ってもかなり大変だし。
結果として、時間が経てば経つほど、設計書に書かれてる内容は古くて使い物にならなくなっていく。 つまり、設計書が腐っていく。 こうなってしまっては「ソースコードを説明する」役割を果たすどころか、場合によっては「嘘」になった説明が害を与えることすらある。 それでは何のために頑張って設計書を書いてるんだとなる。
ソースコードから設計書を作る？
設計書が腐る原因は、ソースコードの変更に合わせて設計書にもフィードバックが必要だけど、それをやるのは大変で、設計書のメンテがされなくなるということ。
だったら発想の転換で、むしろソースコードに人間向けの説明を書いておき、そこから設計書を生成したらいいんじゃないかというのは自然かもしれない。 そうしておけば、ソースコードを直すときに人間向けの説明も一緒に直せるので、メンテが維持されると。 こういった仕組みは、古くはTeXの実装に使われたWEBとか、Javadoc、Doxygenなどのツールで実現されている。
たしかにこういう仕組みを用意すれば、「設計書」が腐る問題は起きにくくなるだろう。
けど、ちょっと待ってほしい。 それは「設計書」なのか？
設計書はどこに消えた？
こうやってソースコードから「設計書」を生成するのだとすると、ソースコードの前に「設計書」は存在しないことになる。 従来書いていたはずの「いわゆる『設計書』」は何だったのか、そしてどこに行ってしまったのか？
「それでいいんだよ、だってソースコードが本来『設計書』なんだから」という過激派はまぁいるかもしれないけど、それだと「思ってたものと違った」ときの手戻りがとても大きくなるデメリットは出てくる。 だって、もうコードを書いちゃってるわけだから。
ちなみに、大抵はそうなると工数に追われて「もう動くコードがあるから・・・」と実装しちゃったものが採用されることになる。 もっと詰めるべきだった仕様とか設計があったにも関わらず。 で、技術的負債になっていくと。
ここで、ちょっと別の観点でも考えてみたい。
ソフトウェア開発の成果物というとまずはプログラムなわけだけど、実際にはそれ以外にも必要なものがある。 それは「ドキュメント」。 プログラムだけあっても使い方が分からないので、何らかの形でドキュメントが必要になる。
そしてこのドキュメントはソースコードの変更に追従する必要がある。 なので、実際にはソースコードからはプログラムの他にドキュメントも生成されていることになる。 これは、言葉通りソースコードに埋め込まれた内容からドキュメントが作られることもあれば、ソースコードの内容を元に手で書かれたドキュメントの場合もある。
ここまで書けば、言いたいことは分かるかと思う。
そう、ソースコードから生成された「設計書」というのは、実のところ「設計書」ではなく、「ドキュメント」だったりする。 ドキュメントというとユーザ向けのドキュメントが浮かぶわけだけど、開発者向けのドキュメントも存在するわけで、ソースコードから生成されたソースコードの説明というのは、設計書ではなくて開発者向けのドキュメントの一つにすぎない。
「設計書」というのは本来「ソースコード」を生成するためもので「ソースコード」よりも前に存在する必要がある。 それが逆に「ソースコード」から生成されるものになってしまっては、それはもはや「設計書」ではない。 ただの「ドキュメント」だ。
つまり「ソースコードを説明するのが設計書だ」という考え方は、設計書でないもの（ドキュメント）を設計書と勘違いしているだけにすぎなかったりする。
では、設計書とは一体何なのだろうか・・・？
今日はここまで！
