アカウント名:
パスワード:
> 今は、文書を書くことによって発生するデメリット(時間的なコスト)よりも、 > - 文書を書くことで自分の考えている内容が整理される
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
正直なところ (スコア:1)
Re:正直なところ (スコア:1, 参考になる)
ただソフトウェアのライフサイクルでは、運用期間のほうが開発期間より長くなり、
その間にかなりの頻度で改修、拡張が行われるでしょう。
そのときに文書がないと苦労することになるんじゃないでしょうか。
自分の書いたコードだって一ヶ月もすれば忘れてしまうでし
Re:正直なところ (スコア:1)
は、「だから仕様書なんて書かなくていい」という話ではなく、「どうして仕様書はいい加減になるか」という心理分析です:-)
＃うちは受託開発系のソフト会社なんで、仕様を作る方も見る方もプログラミングできる人、というのが今回の話の前提。
実際に物を作ってしまうより、指示書を作る方が手間がかかるなんて理不尽だ、と無意識のうちに感じてしまうんでしょう。
あと、「コロコロ変わる物をいちいち文面に起こすのは時間の無駄」という心理もたぶんある。
Re:正直なところ (スコア:1, 参考になる)
>実際に物を作ってしまうより、指示書を作る方が手間がかかるなんて理不尽だ、と無意識のうちに感じてしまうんでしょう。
>あと、「コロコロ変わる物をいちいち文面に起こすのは時間の無駄」という心理もたぶんある。
多分にあるでしょうね。昔は私もそうでした。
そして今もその気持ちを仕事ではぐっとこらえています。
＃コードが仕様書だ :-)
＃そして2年前の自分で書いた仕様書(コードね)が読めない私 orz
今は、文書を書くことによって発生するデメリット(時間的なコスト)よりも、
- 文書を書くことで自分の考えている内容が整理される
- 人に(斜め読みでもいいから)レビューしてもらうことで、新たな視点が見つかる
- いざというとき丸投げできる:-)
というメリットが得られることを重視し、また「方法、手段」はコードを見ればよいので、ドキュメントには「方針、意図」を残すように心がけています。
あとはドキュメントを書く練習の機会、とも捉えていることくらいですかね。
やっぱり第三者に伝わるようにドキュメントを書くのは経験が必要でしょうし、書けば書くほどこなれてくるものですよね。
高い意識を常に持って書くことで、できあがった成果物、そしてそれを書いた経験は、自分にとって価値あるものになると思っています。
Re:正直なところ (スコア:1)
どちらかというと、プログラム書いた方が内容が整理される、という経験が多いため、困っています。書いてみて、こういう機能を実現しとかないといけないとか、こういう情報も受け渡してやらないといけないとか、気付くことしばしば。気付いたら、とりあえずプログラム完成。勢い、ドキュメントがおろそかになっていく。
まあ、それでしばしば痛い目にあっているので、できるだけコメント文を残すようにしたり、出きるだけ意味を反映した変数名や関数名を使うよう、心掛けています。
久々に昔のコード（とコメント)を読むと、「お、ちゃんと理由があってこうなっとるんか。昔の自分、結構偉いじゃん」と変に感心したり。
こんな中途半端なプロトタイピングプログラムを仕様書として受け取ってくれるところが、どこか無いでしょうか？