「富士通研究所がプログラムから業務仕様を抽出する技術を開発」記事へのコメント

何が結果として出てくるのかが問題

[Anonymous Coward]

問題は、「何をやっているかわからない」じゃなくて、「なぜやっているかわからない」じゃなかったのか？　これを見てうれしい人は、プログラムを読めない、SEと称する「エンジニア」様だけなのかも。

あの会社は、キーワードを日本語化しただけの日本語BASICとか、フローチャートからプログラムを生成するというので見てみたら、プログラム言語をフローチャート化しただけだったとか（for文やswitch文が図になっただけ）、とほほなのが多いからなあ。

同技術を社内の事例に適用したケースでは、仕様書の再整備にかかる時間を約3分の2に削減でき、システム移行時の業務仕様作成の効率化を実証できたという。

というのは、「自社も出鱈目だったのかよ」と笑うところ？　それとも、「ちゃんとドッグフード食ってるねえ」と褒めるところ？

Re:何が結果として出てくるのかが問題

[Anonymous Coward]

「コード読めばわかることはコード見ればいい」ってのは小規模の開発しか想像できないからこその発想だね。

Re:何が結果として出てくるのかが問題

[t-wata (10969)]

それなりの規模の開発してるけど「コード読めばわかることはコード見ればいい」と思ってるよ。
規模が大きくなるほどソースコード見ただけじゃ分からない俯瞰的なドキュメントの方が重要性があって、ドキュメントはそっちに注力してほしいね。
個々の細かい話はソースコード見た方が正確だし手っ取り早い訳で、ドキュメントがコード見ればわかるような話で一杯だと困ると思うが。

Re:

[Anonymous Coward]

あなたは「コードを読めばわかることはコードを見ればいい」と思っていて、そうしている
別のある人も「コードを読めばわかることはコードを見ればいい」と思っていて、そうしている
でも、あなたの理解と別のある人の理解が一致している保証はなにもない
あなたも別のある人もちょっとずつ間違って理解していたかもしれない
だから二人の理解をよりよく一致させるためには、コード以外のものを読む必要がある
そういう時にこういったツールは役に立つのだと思います
コードに書いてあること以上ものは出てはきませんが、コードの大量のノイズを削減して情報処理に対する別の見方を提示すること、
例えばフローのかわりにファンクションを提示するなどしてより深い理解を助けることができる、あるいはその可能性があるのではないウサか

Re:

[Anonymous Coward]

このツールはプログラムを別の角度から見せてくれるので、なかなか有用だと思います
みんな嫌いな境界条件のバグ取りなど、そこそこ楽になるウサ？