アカウント名:
パスワード:
できあがったものの簡潔な説明は、確かにここで指摘されたように有用だと思う。けど、設計書にその役割を求めると、理想はともかくとして大概「格言」に引っ掛かることになるよね。
同様の経験は確かにあるが、バグ発見に「も」役立つというだけで、そっちがメインじゃないよな。その目的のためだけにドキュメントを書かせるならS/N比が悪すぎる。# この文脈ではバグがSignal。要は時間をかけてコードを精査して埋もれたバグ発見しろや、だけど使った時間がもったいないからその分手を動かしてドキュメント残せ。
やっぱり最初から作りこまないのがベストで、そのためのKISS。プログラマにとって、適切なコメントが入ったシンプルなソースは詳細設計書に勝る。プログラムは設計書のとおりには動かないけれど、コーディングされているとおりには動く。
ここの問題はドキュメント作成にかかるコストが書かれていないし、効果についても定量的に書かれていない。どういったドキュメントをどのくらいの手間をかけて作成するべきかを明示して欲しいよね。
開発時の品質向上の効果についてはわからんが、開発後の保守を担当させられた経験上からは、肝心なドキュメントが足りなかったり、コードとの間に数箇所の違いがあるだけで、ドキュメントの正当性が怪しくなり、最終的にはソースを見ないと駄目という結論に・・・
ソース見れる奴はどうせドキュメントなんて見ないのさ(笑)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
前か後か (スコア:1)
できあがったものの簡潔な説明は、確かにここで指摘されたように有用だと思う。
けど、設計書にその役割を求めると、理想はともかくとして大概「格言」に引っ掛かることになるよね。
Re: (スコア:0)
同様の経験は確かにあるが、バグ発見に「も」役立つというだけで、そっちがメインじゃないよな。
その目的のためだけにドキュメントを書かせるならS/N比が悪すぎる。
# この文脈ではバグがSignal。
要は時間をかけてコードを精査して埋もれたバグ発見しろや、だけど使った時間がもったいないから
その分手を動かしてドキュメント残せ。
やっぱり最初から作りこまないのがベストで、そのためのKISS。
プログラマにとって、適切なコメントが入ったシンプルなソースは詳細設計書に勝る。
プログラムは設計書のとおりには動かないけれど、コーディングされているとおりには動く。
Re:前か後か (スコア:0)
ここの問題はドキュメント作成にかかるコストが書かれていないし、効果についても定量的に書かれていない。
どういったドキュメントをどのくらいの手間をかけて作成するべきかを明示して欲しいよね。
開発時の品質向上の効果についてはわからんが、開発後の保守を担当させられた経験上からは、
肝心なドキュメントが足りなかったり、コードとの間に数箇所の違いがあるだけで、ドキュメントの正当性が怪しくなり、
最終的にはソースを見ないと駄目という結論に・・・
ソース見れる奴はどうせドキュメントなんて見ないのさ(笑)