自動ニュース作成G
東証曰く、システム開発においてコーディング後にはドキュメントは不要
http://developers.slashdot.jp/story/13/04/05/0759247/
2013-04-07 13:03:16
・こいつら馬鹿なんだな。
・コピペが複数あるとソース修正のときに危険なんだよなぁ
・え？これって片方だけバグつぶして終わった気になる元凶なので、可能な限り共通化されるべきことで、「一般論として良い」わけでは決してないと思うが？？>東証側は「重複する記述を含むプログラムはそうでないものと比べて信頼性が高い」と主張しているのに対し
・個人的にはコードから仕様書を生成する方向に（javadocみたいな）向かっていくべきだと思う。あるいはその逆で仕様書からコード
・この件に関して言えばみずほ側の意見を完璧に支持する。 あと仕様書からコードを生成するのとその逆とは根本的に意味が違う。
・ドキュメント修正不要か。今後東証のシステム触る所はちょっと楽になるね！
・ドキュメントなんて参考程度。エライ人には分からんのですよ。結局ソース確認するんだからドキュメントなんて無いものと考えた方がいい。みずほは言いがかり。修正してたらしてたでコードとの不整合があるとか文句言うんだろ。#3考え方だよ。共通化すると修正の影響範囲が拡大してエンバグの原因にもなる。新規はそうだろうけど保守フェーズになると微妙じゃね？
・#5 意味合いじゃなくて、仕様書の信用性が担保されているかどうかって話だよ。何なら別々に更新してもいいけど、テストコードを仕様書から自動で作るとかでも構わなくて、確証が得られることが大事。
・不要なら消せと。嘘ドキュメントトラップなんて危険すぎる。
・俺もソフト開発者だけど、なんでこの業界は仕様書の扱いが適当なんだかね。客先にコードから仕様書起こしていいですか？なんて俺は聞けない。「その方が的確です」なんていったら「何言ってんだ？馬鹿かお前は！」って怒鳴られるよ。
・#１０開発のドキュメントと保守のドキュメントは別。保守のドキュメントはソースコードのリファレンスだからソースから作成するのは理に適ってると思うな。怒鳴られたらきちんと説明するのがプロだろ。お前は顧客に怒鳴られるかどうかで判断してるのかよ。
・ここの人たちのやり取りを見てるとソースコードが仕様書って結論なのかな
・#12違うものが完全に同じ事を表すのは不可能なんでどちらが主かって事だと思う。開発ではドキュメントからプログラム作るけど、保守になるときちんと動くプログラムを保守するのが目的になるからプログラムが主になる。
・#12 完全に自社で完結していて関わった人にコンタクトが取れる状態ならいいけど、どこの誰が書いたかわからないような（ましてや他社とか）ドキュメントは信用出来ない。そういや東証のシステムって前にいた会社で孫請けしてた気がするな…。多分何十社も関わってるはず
・#11 最後のは「そんな馬鹿な事はいえない」って事を強調しただけだよ。
・ソースから仕様を作るってことは、仕様がわからないまま作ったってことでしょ？で、何があっても「それが仕様です、仕様どおり出来てます」って言えるわけだ。
・仕様書を確定させてそれにそってコーディングしてテストケース作るのが理想だけどね。実際は途中で仕様がコロコロと……
・#16 保守フェースの話だよ？プログラムを正しくするのがデバッグなんで、むしろバグがドキュメントに反映されないと意味が無いんだよ。仕様は設計のドキュメント。バグはリバースして作成したドキュメントに表現されるってこと。
・真っ当なところなら仕様が変わる必要性があるなら、仕様を変更してからコードを変更するけどね。つか保守で仕様変更って意味が分からない。
・#１９保守フェースでも機能追加とかあるよね？仕様変更ってどこから出た話？そもそもこれって誤発注のキャンセル処理が出来なかったとかの件だろ。バグも仕様が誤りの場合と仕様と実際(プログラム)が違ってる場合があって、後者の可能性を考えるとリバースしたドキュメントで見るべきって言ってるんだよ。
・仕様変更の無い機能追加？ ごめん、わけわからない。
・仕様変更でもバグフィックスでも料金は一緒なのか？なら適当になるのは当たり前だな。
・#22 バグって瑕疵じゃないの？お金取るものなのか
・御免。良く判らんのだが言ってるドキュメントって機能仕様書とかの事？機能追加や修正があった場合は追加機能証書とか無く一気にソースコーディングでもするのか？
・形だけ作りましたってドキュメントはないほうがましだが、誤動作しても知りませんはダメだろ
・「モジュール詳細定義」を未メンテってあったけど、どんな粒度なんだろう。「Aに１を代入する」のか、機能の詳細説明なのか。