OPC Diary: 設計時ドキュメント書く？ – もちろん書く！
これの続き。
設計書のアクターって二種類あるということをなんとなく多くのプログラマの人に理解していただいていないのかなって思います。
一つ目のアクターは、そのプログラムを保守することになるプログラマー、二つ目のアクターはそのプログラムの管理をするシステム管理者です。そして、たいていこの二つ目のアクターを皆さん見逃しすぎです。システム管理者は、その彼・彼女が優秀であればあるほど、トラブル発生時にプログラムの内部仕様を調べてプログラム原因が何であるか調べ解決しようとし、その際に参照することになるのが、たいていの場合設計書です。
そこでです。
本当にユニットテストのコードや、その他テストコードはこの二つ目の読者にとって有用な情報なのでしょうか、一つ目の読者にとってはユニットテストコードはリファクタリングの勇気を与えるものですが、二つ目の読者にとっては困惑を深めるだけで、事態に改善には近づきません。システム管理者はプログラマではありません。また、それがコードである以上テストコードの管理は作る側の責任です。
設計が文書であったとしても、一つ目の読者だけを念頭に置いて書かれたものもおそらく二つ目の読者にとっては有益なものにならないでしょう。
結果、それらはシステム管理者に捨てられるか、その存在が忘れ去られます。
kawabata wrote:
設計書: トラブルが発生したときには、その存在は忘れられているもの。たいていの場合は、フィクション。
ましてやフィクションなら。。
最終的に自分たちの作ったプログラム、ソフトウェアシステムが、使っている人たちにとって有用なものとして、誇りのある仕事をされたいのであれば、その使っている人たちの中にシステム管理者がいることを忘れないようにし、作成するドキュメントの読者にも気をつけないといけません。エンドユーザーへのおもてなしはもちろん、システム管理者へのおもてなしも忘れずに。Windowsが売れたのはNetwareよりシステム管理者へのおもてなしをしっかりやったからです。
プログラマと、システム管理者両方の経験がある身として、ちょっと書いてみました。
コメント