はてなブックマーク - ウノウラボ Unoh Labs: ドキュメントを楽しく楽に書くために

ウノウラボ Unoh Labs: ドキュメントを楽しく楽に書くために

labs.unoh.net

タグ : document development ドキュメント仕事 programming 開発 agile ソフトウェア開発 *programming work

コンピュータ・IT 55 users

yukiです。今回は主にアジャイル開発におけるコード以外のドキュメントについてお話しようと思います。「包括的なドキュメントよりも、動作するソフトウェア」という言葉がありますが、最近これを「ドキュメントはいらない」もしくは「極力書くべきではない」と誤解され、ドキュメントが軽視されがちだと感じます。確かに、ドキュメントは面倒です。コードを書いている方が何万倍も楽しいですし。私も出来れば面倒なドキュメントは書きたくはありません。「コード見ればわかるでしょ」とか「コードがドキュメントだ」と言い切るのは簡単... > このページを見る

最終更新時間: 2008年03月03日01時48分

▼ブログで紹介する

みんなのブックマーク人気（0）新着

pitworks
評価体制を作る人的リソースを削減する命名にもっと時間をかける(重複しない, 誤解しない, 見ただけで内容がわかる) コミットログで説明(5W1Hが把握可能） 2008/03/21
sdv
Whyが大事に超同意 2008/03/15
Chisei ドキュメント
『コミットログでは、誰が(Who)、何を(What)、いつ(When)、何処で(Where)、どのように(How)は付属情報でわかるのですが、なぜそうしたのか(Why)は人が書かない限りわかりませんので、何故こうしたのか、を必ず書くようにしまし 2008/03/07
m-1046
これいい 2008/03/06
iskwrsk 仕事, 開発
ドキュメントだけでシステムを理解できる様にするという思い込みが蔓延してるのが良く無いと思う。ドキュメントでコードを詳解する必要は無い。緻密にコードを読まなくても大枠が分かる様に補完出来れば良いと思う。 2008/03/03
imai78 document
いまご 2008/03/03
itengineer document
いまご 2008/03/03
toubanjanny programming
ドキュメント軽視の理由はもっともだと思う。命名規則を徹底させてツール使えば楽だよね的な解決策。 2008/03/03
co3k
ちょっとずつ取り入れていこう（あとで読むの意） 2008/03/03
suVene development
「書けない」人もよく見かける。プログラムから起こす仕様書ならともかく、設計段階で。RAPID的な開発に慣れすぎて。(テストファースト的にやってればまだマシだが、そうでない所はいまだ多い) 2008/03/03