What Is Software Design?

表題の「What Is Software Design?」というエッセイを読みました。

"最終的なソースコードこそが真のソフトウェア設計である"と仮定すると、どのようなことが考えられるかについて書かれています。

以下の段落が目に止まりました。

all programmers know that writing the software design documents after the code instead of before, produces much more accurate documents. The reason is now obvious. Only the final design, as reflected in code, is the only one refined during the build/test cycle.

(和訳)すべてのプログラマたちは知っている。コーディングの前に設計ドキュメントを書くより、コーディングの後にドキュメントを書いたほうがよいと。
理由は明白だ。最終的な設計は、ビルド・テストサイクルを通して洗練されたもの --それらはソースコードに反映される -- だけだからだ。

それはみんな分かってることだと思いますが、なぜ実践されないんでしょうね。

設計ドキュメントはソースコードを書くために参照するドキュメントではなく、お客様に説明するためのドキュメントである。要件を抑えて、開発方針の合意を早い段階で取るためにこれらの資料はソースコードを書き始める前に作らなければならない。

ということなのかなと自分を納得させているものの、モヤモヤ感は残っています。
上の方法を行うと、"ソースコード作成 = 真の設計"であることを認めてしまうことになり、それだと困る人たちが多いのではないかなとか思ったり。。

少し脱線してしまった感がありますが、エッセイの概要は以下のとおりです。早い段階でのプロトタイピングとテストによる設計の検証を支持するような内容です。

• ソースコードはソフトウェアの設計成果物である。コンパイラ・リンカは設計をもとにソフトウェアを製造する。
• そのため、他の工学分野と比べて製造工程が非常に簡単で安価である。（飛行機や橋を作る場合の設計と製造の関係と比べてみると分かる）
• ソースコードという表現技法を用いて設計を行うと、設計のミスに気づきやすい。
• ソフトウェアのビルドはとても簡単なので、設計に対してフォーマルなバリデーション（例えば橋をつくる場合は、コンピュータシミュレーションをしたり、模型を作ったりすること）を行うことはあまり実用的ではない。ビルドしてテストして設計が正しいかどうか確認した方が簡単だからだ。
• テスト・デバッグは設計活動である。よい設計工程はこのことを認識しておくべきである。
• すべての設計は相互的である。よいソフトウェア設計は設計が変更になることを寛容する。（detailed designの設計ミスがtop level designに影響するのであれば、素直にtop level designも変更する方がいい。）
• 設計の成果物はソースコードの他に補助的なドキュメントも必要。そのドキュメントには以下が挙げられる。
•  設計（ソースコード）には直接落とし込まれなかった問題領域（ドメイン）の重要な情報
• ソースコードにコメントとして書けないような、図で書くと分かりやすい横断的情報
• ただし補助的な資料はあくまでも補助で、ソースコードこそが真の設計成果物である。補助資料はツールを利用してソースコードから自動生成することが望ましい。