2005-05-10 いろいろ
■ 無駄なドキュメントは書くな

ひたすら実装に関するドキュメントをしこしこ書いている人がいるが、好きで書いているわけではなく、書かされているのかもしれないけれど、そーゆー無駄なドキュメントは書くな。時間の無駄である。実装は日々変化する。それに追従する形でドキュメントが更新されるということはない。断言する。実装に関するドキュメントと最新の実装は常に食い違っている。いまだかつて同期したことがない。無駄なドキュメントを書く時間があるならコードを洗練しろ。無駄なドキュメントを書く時間があるならコードをドキュメントにしろ。
ソフトウェア工学の教科書にドキュメントの重要性が書いてあるからといって信用してはいけない。ウオーターフォールモデルが商用ソフトウェア開発の現場で役にたたないように、実装に関する詳細ドキュメントは百害あって一利なしである。
コードがドキュメントだ。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CodeAsDocumentation
人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)
- 作者: フレデリック・P,Jr.ブルックス,Frederick Phillips,Jr. Brooks,滝沢徹,富沢昇,牧野祐子
- 出版社/メーカー: アジソンウェスレイパブリッシャーズジャパン
- 発売日: 1996/02
- メディア: 単行本
- 購入: 4人 クリック: 105回
- この商品を含むブログ (42件) を見る
今,手元に第2版を置いているのですけど,ドキュメントについては15章に書いてあると思うのですが,そこで「フローチャートの呪い」ということで,その役割を否定しています.また「自己文書プログラム」ということでプログラムのコードの中に文書を入れる事を提案してます.
”プログラム文書は悪名高いほどに貧弱で,そのメンテナンスはさらにひどい.プログラムの変更が,すみやかに正確にそしてそのまま紙の上に記述されることはない.”
”主要な目的は,文書作成の負担を最小化することだ.”
…
ブルックスの第2版では,漸増的構築モデルということで,マイクロソフトの「毎晩構築」アプローチを紹介してます.デイリービルドとかナイトリービルドとか呼ばれているやつですね.これは毎日毎日ビルドを繰り返して,徐々に機能を洗練しいくアプローチです.
毎日のビルドでは常に動くプロダクトが得られます.時として機能の後退(リグレッション)が発生しますが,毎日ビルドしてリグレッションテストを流していますからすぐに発見できます.いつ失敗してもいいのだけれどそれを発見してすぐに修正するというプロセスが組み込まれています.
このプロセスのダイナミズムを理解しないとなかなかシュリンクラップの現場の勢いを理解できないかなと思います.
一つのプロダクトが出荷されるまでにものによっては数百回,あるいはそれ以上ビルドされて,常に修正されるというイメージです.
http://web.archive.org/web/19990423145139/http://www.best.com/~yoshioka/d/98/i980227.html
とかも読め。
なお最新版は
人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))
- 作者: Jr.,フレデリック・P.ブルックス,Frederick Phillips,Jr. Brooks,滝沢徹,富沢昇,牧野祐子
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2002/11
- メディア: 単行本
- 購入: 7人 クリック: 140回
- この商品を含むブログ (175件) を見る
みたいです。(出版社が変わっただけで内容は一緒だと思う。人月の神話)
- http://d.hatena.ne.jp/higepon/20050510
- http://d.hatena.ne.jp/clock9/20050511
- コードに転嫁できるドキュメントはただのムダ
- http://d.hatena.ne.jp/codemaniax/20050511
- ドキュメンテーション、あるいは作業の二重化
- http://d.hatena.ne.jp/masanobuimai/20050511
- http://d.hatena.ne.jp/kjkw/20050511
- http://d.hatena.ne.jp/kawasima/20050511
- http://d.hatena.ne.jp/harux/20050511
- http://d.hatena.ne.jp/Buzzstyle/20050512
- http://d.hatena.ne.jp/kita_no_naka/20050514
- http://d.hatena.ne.jp/dachii/20050514
- http://d.hatena.ne.jp/kita_no_naka/20050627
- オレドコBlog - 無駄・ムラ・無理を排除してはダメな理由
- 未来のいつか/hyoshiokの日記 - 無駄なドキュメントは書くな(再考...
- 未来のいつか/hyoshiokの日記 - コードはHOW、テストはWHAT、ドキ...

私に言わせると、「無駄なドキュメントを書いている」人は少ないが、「無駄にドキュメントを書いている」人は多い。つまり、内容が無く、読みづらく、基本概念がしっかりしておらず、いやそもそも何が言いたいんだかこれは…
というような「文字列」を吐く人は多い。
そしてそういう人のコードは汚く、場当たり的で、柔軟性に欠け、遅くて役立たずで、すぐ実態と乖離する。ついでに言うと、そういう人は図などの美的センスにも問題があるので、フローチャートも腐ったものでしかない。
ようするに原因と結果が逆なのではないかと思います。ドキュメントが無駄なのではなく、リテラシーがなってないだけだろう、と。無駄にドキュメントを書いているのではなく、無駄な文字列生成をしてそれをドキュメントと称しているだけだろう、と。「なぜそのコードになったのか」を説明するべきなのに、コードが何をしているのかの説明をするから、すぐ Out of date になるのだろう、と。
よいドキュメントを書く人は、全く違った視点から同じアルゴリズムを2度見つめます。ドキュメントとコードの2度、構造の理由を説明した版と実装を説明した版の2度です。で、ドキュメントを先にします。だから「良いコード」になります。もちろん、その後でコードにあわせてドキュメントを直します。ver1.0よりver2.0の方が良いに決まってますから。
下手なドキュメントを書く人は、先にコードを書きます。ver1.0です。で、それにあわせてドキュメントを書くので、ドキュメントもver1.0です。当然バギーです。すぐ変更がかかります。ドキュメントはver1.0のままで、役立たずです。
WebとかTangleとかが流行らなかったのは、まさにこの点がまざまざと出てきてしまうからではないかと。あれは「コードを説明する」システムであって、コードの意図を説明するドキュメント生成はできない。同じ事を2種類の表示方式で言ってもらっても、同じバグが入っているのでは価値は無い。
というわけで、ドキュメント害悪論は本末が転倒した結論だと思っています。
よしおかさんは、もちろんそんなつもりでおっしゃっているのではないと思いますが、この手のドキュメント不要論はドキュメントを書けない人の自己正当化に都合よく利用されそうな気がして、どうにも好きになれないのです。。。
そして最終的に「Howは可読性の高いソースで書く」「Whyは自然言語で書く」という感じの結論になることが多い気がします。