アカウント名:
パスワード:
問題は、「何をやっているかわからない」じゃなくて、「なぜやっているかわからない」じゃなかったのか? これを見てうれしい人は、プログラムを読めない、SEと称する「エンジニア」様だけなのかも。
あの会社は、キーワードを日本語化しただけの日本語BASICとか、フローチャートからプログラムを生成するというので見てみたら、プログラム言語をフローチャート化しただけだったとか(for文やswitch文が図になっただけ)、とほほなのが多いからなあ。
同技術を社内の事例に適用したケースでは、仕様書の再整備にかかる時間を約3分の2に削減でき、システム移行時の業務仕様作成の効率化を実証できたという。
というのは、「自社も出鱈目だったのかよ」と笑うところ? それとも、「ちゃんとドッグフード食ってるねえ」と褒めるところ?
それなりの規模の開発してるけど「コード読めばわかることはコード見ればいい」と思ってるよ。規模が大きくなるほどソースコード見ただけじゃ分からない俯瞰的なドキュメントの方が重要性があって、ドキュメントはそっちに注力してほしいね。個々の細かい話はソースコード見た方が正確だし手っ取り早い訳で、ドキュメントがコード見ればわかるような話で一杯だと困ると思うが。
あなたは「コードを読めばわかることはコードを見ればいい」と思っていて、そうしている別のある人も「コードを読めばわかることはコードを見ればいい」と思っていて、そうしているでも、あなたの理解と別のある人の理解が一致している保証はなにもないあなたも別のある人もちょっとずつ間違って理解していたかもしれないだから二人の理解をよりよく一致させるためには、コード以外のものを読む必要があるそういう時にこういったツールは役に立つのだと思いますコードに書いてあること以上ものは出てはきませんが、コードの大量のノイズを削減して情報処理に対する別の見方を提示すること、例えばフローのかわりにファンクションを提示するなどしてより深い理解を助けることができる、あるいはその可能性があるのではないウサか
このツールはプログラムを別の角度から見せてくれるので、なかなか有用だと思いますみんな嫌いな境界条件のバグ取りなど、そこそこ楽になるウサ?
プログラマならソースを読めで済めば楽なんですけどね。長期に渡る大規模なプロジェクトだとコメント文の不備や不整合も生じますからね。どっかで整理できればいいがリファクタリングは時間や金銭的問題があるので。実際に動いているプログラムならコードの不整合はないはず。人はそれを不具合やバグと呼ぶから。
言語はCOBOLだし。
例を見ると、スコープが全体にわたる一時変数の山とIFとGO TOでなす多段コードを、なるべくフラットなパターンマッチテーブルに変換するという話に見えます。COBOL世界では本来そういうテーブルが「仕様書」としてあって、それをCOBOLでは複雑なIF構文に落とし込んでいたため、バグやら他の仕様からの副作用やらでコードのほうから変化した時に仕様書とのずれが大きくなっていくのでしょう。またCOBOL世界では、COBOL言語で書く書かないに限らず、今ではVCSでやるような変更履歴等もコード上のコメントなどで積み重なっていく運用をするので、こういう単純化自体が大きく役立つ世界でしょうし。
モダンな言語なら、この仕様書レベルの内容はコードで直接表現するのであって、コードを読めば良いのですけれどね。
読んだら読んだで
// hensu_1に3を足す// MOD 2001.12.31 山田 5を足す仕様に変更// hensu_1 = hensu_1 + 3;// MOD 2004.05.05 鈴木 足す数値を8に変更// hensu_1 = hensu_1 + 5;hensu_1 = hensu_1 + 10;
みたいなコードがあって頭を抱えたりするんだぜ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
何が結果として出てくるのかが問題 (スコア:0)
問題は、「何をやっているかわからない」じゃなくて、「なぜやっているかわからない」じゃなかったのか? これを見てうれしい人は、プログラムを読めない、SEと称する「エンジニア」様だけなのかも。
あの会社は、キーワードを日本語化しただけの日本語BASICとか、フローチャートからプログラムを生成するというので見てみたら、プログラム言語をフローチャート化しただけだったとか(for文やswitch文が図になっただけ)、とほほなのが多いからなあ。
というのは、「自社も出鱈目だったのかよ」と笑うところ? それとも、「ちゃんとドッグフード食ってるねえ」と褒めるところ?
Re:何が結果として出てくるのかが問題 (スコア:1)
Re:何が結果として出てくるのかが問題 (スコア:2)
それなりの規模の開発してるけど「コード読めばわかることはコード見ればいい」と思ってるよ。
規模が大きくなるほどソースコード見ただけじゃ分からない俯瞰的なドキュメントの方が重要性があって、ドキュメントはそっちに注力してほしいね。
個々の細かい話はソースコード見た方が正確だし手っ取り早い訳で、ドキュメントがコード見ればわかるような話で一杯だと困ると思うが。
Re: (スコア:0)
あなたは「コードを読めばわかることはコードを見ればいい」と思っていて、そうしている
別のある人も「コードを読めばわかることはコードを見ればいい」と思っていて、そうしている
でも、あなたの理解と別のある人の理解が一致している保証はなにもない
あなたも別のある人もちょっとずつ間違って理解していたかもしれない
だから二人の理解をよりよく一致させるためには、コード以外のものを読む必要がある
そういう時にこういったツールは役に立つのだと思います
コードに書いてあること以上ものは出てはきませんが、コードの大量のノイズを削減して情報処理に対する別の見方を提示すること、
例えばフローのかわりにファンクションを提示するなどしてより深い理解を助けることができる、あるいはその可能性があるのではないウサか
Re: (スコア:0)
このツールはプログラムを別の角度から見せてくれるので、なかなか有用だと思います
みんな嫌いな境界条件のバグ取りなど、そこそこ楽になるウサ?
Re: (スコア:0)
プログラマならソースを読めで済めば楽なんですけどね。長期に渡る大規模なプロジェクトだとコメント文の不備や不整合も生じますからね。
どっかで整理できればいいがリファクタリングは時間や金銭的問題があるので。
実際に動いているプログラムならコードの不整合はないはず。人はそれを不具合やバグと呼ぶから。
Re: (スコア:0)
言語はCOBOLだし。
例を見ると、スコープが全体にわたる一時変数の山とIFとGO TOでなす多段コードを、
なるべくフラットなパターンマッチテーブルに変換するという話に見えます。
COBOL世界では本来そういうテーブルが「仕様書」としてあって、それをCOBOLでは複雑なIF構文に落とし込んでいたため、
バグやら他の仕様からの副作用やらでコードのほうから変化した時に仕様書とのずれが大きくなっていくのでしょう。
またCOBOL世界では、COBOL言語で書く書かないに限らず、今ではVCSでやるような変更履歴等もコード上の
コメントなどで積み重なっていく運用をするので、こういう単純化自体が大きく役立つ世界でしょうし。
モダンな言語なら、この仕様書レベルの内容はコードで直接表現するのであって、コードを読めば良いのですけれどね。
Re: (スコア:0)
読んだら読んだで
みたいなコードがあって頭を抱えたりするんだぜ