アカウント名:
パスワード:
> 今は、文書を書くことによって発生するデメリット(時間的なコスト)よりも、 > - 文書を書くことで自分の考えている内容が整理される
まあ、動くのが最優先ではあるんだけどもうちょっときちんと評価・判断して欲しかったってのも確か。 考えように依っては無意味に二回開発している事になるし、潜在的バグ要因を残しているって可能性も。
いや、それも取り敢えずは良いとして（余り良くも無いが）、それならそうでドキュメントに反映させて置けよな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
正直なところ (スコア:1)
Re:正直なところ (スコア:1, 参考になる)
ただソフトウェアのライフサイクルでは、運用期間のほうが開発期間より長くなり、
その間にかなりの頻度で改修、拡張が行われるでしょう。
そのときに文書がないと苦労することになるんじゃないでしょうか。
自分の書いたコードだって一ヶ月もすれば忘れてしまうでしょうし。
と思っているのでなるべく書くようにしてます。
未来の自分のために、ってか。
一発ものだったら作り捨てもありかな。
＃「拡張とかないからちゃちゃっと作って」って言われても、大抵修正依頼が来るもんだ
＃それも数年後とかにorz
Re:正直なところ (スコア:1)
は、「だから仕様書なんて書かなくていい」という話ではなく、「どうして仕様書はいい加減になるか」という心理分析です:-)
＃うちは受託開発系のソフト会社なんで、仕様を作る方も見る方もプログラミングできる人、というのが今回の話の前提。
実際に物を作ってしまうより、指示書を作る方が手間がかかるなんて理不尽だ、と無意識のうちに感じてしまうんでしょう。
あと、「コロコロ変わる物をいちいち文面に起こすのは時間の無駄」という心理もたぶんある。
Re:正直なところ (スコア:1, 参考になる)
>実際に物を作ってしまうより、指示書を作る方が手間がかかるなんて理不尽だ、と無意識のうちに感じてしまうんでしょう。
>あと、「コロコロ変わる物をいちいち文面に起こすのは時間の無駄」という心理もたぶんある。
多分にあるでしょうね。昔は私もそうでした。
そして今もその気持ちを仕事ではぐっとこらえています。
＃コードが仕様書だ :-)
＃そして2年前の自分で書いた仕様書(コードね)が読めない私 orz
今は、文書を書くことによって発生するデメリット(時間的なコスト)よりも、
- 文書を書くことで自分の考えている内容が整理される
- 人に(斜め読みでもいいから)レビューしてもらうことで、新たな視点が見つかる
- いざというとき丸投げできる:-)
というメリットが得られることを重視し、また「方法、手段」はコードを見ればよいので、ドキュメントには「方針、意図」を残すように心がけています。
あとはドキュメントを書く練習の機会、とも捉えていることくらいですかね。
やっぱり第三者に伝わるようにドキュメントを書くのは経験が必要でしょうし、書けば書くほどこなれてくるものですよね。
高い意識を常に持って書くことで、できあがった成果物、そしてそれを書いた経験は、自分にとって価値あるものになると思っています。
Re:正直なところ (スコア:1)
どちらかというと、プログラム書いた方が内容が整理される、という経験が多いため、困っています。書いてみて、こういう機能を実現しとかないといけないとか、こういう情報も受け渡してやらないといけないとか、気付くことしばしば。気付いたら、とりあえずプログラム完成。勢い、ドキュメントがおろそかになっていく。
まあ、それでしばしば痛い目にあっているので、できるだけコメント文を残すようにしたり、出きるだけ意味を反映した変数名や関数名を使うよう、心掛けています。
久々に昔のコード（とコメント)を読むと、「お、ちゃんと理由があってこうなっとるんか。昔の自分、結構偉いじゃん」と変に感心したり。
こんな中途半端なプロトタイピングプログラムを仕様書として受け取ってくれるところが、どこか無いでしょうか？
Re:正直なところ (スコア:0)
おおまかな仕様検討→プロトタイピング→仕様書作成→本番プログラム作成
って流れになることが多いのですが、
プロトタイプを捨てるのがもったいなくて、そのまま利
Re:正直なところ (スコア:1)
本番はVC++ってのが多いのだけども、この前客先で見たのは何故か本番もVBに。
帰って担当に聞いたら、どうもなかなか再現しないバグがあって、プロトタイプ用に作ったVBを改造して使ったら出なかったからそれを使っちゃったって話でした。
まあ、動くのが最優先ではあるんだけどもうちょっときちんと評価・判断して欲しかったってのも確か。
考えように依っては無意味に二回開発している事になるし、潜在的バグ要因を残しているって可能性も。
いや、それも取り敢えずは良いとして（余り良くも無いが）、それならそうでドキュメントに反映させて置けよな。
Re:正直なところ (スコア:0)
引き継いでみると、なぜか(納品物として納めたとおぼしき)仕様書とソースだけあって、ドキュメントが無いというパターンが多いんですけどね。
＃物によっては、ソースを解析するよりも仕様書を元に一から作り直した方が早いというケースも
Re:正直なところ (スコア:0)
そんなことを言っていると、やらなくてもいいことまでやらされます(^^;
ソースコードが「現在の仕様書」ですよ。
不条理な仕様のとき、どうしてそういう仕様になったかという理由がどこにも