プログラムの内容理解

質問

私は仕事で現在コボルを使用しています。
コボルどころかこういった専門的なものは初めての初心者です。

最初のうちは短い行のプログラムを読んで理解して修正して・・・と、苦しいながらも先輩方に聞きながら進んでいきました。
しかし段々と量が増え、さらにプログラムが複雑になり（色々なところに飛ぶ）ついていけなくなりました。

先輩方に部分部分聞いても自分自身が
　　　「ここがこうなるからこっちはこうなる。そして次でこれが・・・」
という理解をできていないのですぐ分からなくなります。

そこで皆様に聞いてみたいのですが、長いプログラムを読むコツみたいなものはありますでしょうか？
「IF」などで分岐していくともう頭がこんがらがり余計に理解ができなくなってしまいます。

1をAに、さらにそれをBへ。そしてCに入れ最後にD・・・などもよくあるのですが「何故そんなに遠回りを？」と思い追いかける気力が無くなってしまいます。

どうかよろしくお願いします。
簡単ではないでしょうが頑張ってコツみたいなのをつかんで壁をこえたいです。

回答No.9

Passeio

自分は、もう１５年以上COBOLにどっぷりつかっています。
造る側の視点で自分が心がけていることを挙げていきますね。

・解りやすいように造ること。
・GOTO文の乱立は行わないこと。
・セクション分割すること。
・階層を深くしすぎないこと。
・フラグコントロールを少なくすること。
・階層化の開始文字位置をあわせること。
・状態分岐は全パターンを想定すること。
・コメントを利用し読みやすいプログラムにすること。
・無限ループにならないように気をつけること。
・再帰的呼び出しはなるべく使用しないこと。
・処理のトリガーとなる条件を把握しておくこと。

ひょっとしたら、読んだプログラムが
このいずれかを守っていなくて
読みにくくなっているのかもしれませんね。

だから、「何故そんなに」と
お考えになるのは非常にいいことだと思います。

回答No.8

sambarunba

質問への回答は他の方がされているようなので、
経験上からひとこと。
（質問への回答ではないので、これは参考になりません^^;）

>私は仕事で現在コボルを使用しています。
>コボルどころかこういった専門的なものは初めての初心者です

COBOLは言語仕様上分りにくいと思います。
以前、COBOLを使用していましたが、
Windows主流の言語などを憶えてしまうと、使用したくないですね。
「PERFORM」は必要ですが、
「GO TO」をロジック上の基本適なところで使用しているのはかんべんしてほしいです。
また、変数のスコープが無いというか、
故意に全体的に使用するところがどうも・・・。
ツールの話になりますけど、
Windows主流の言語の開発環境にあるデバッガのようなものがあれば、
そこまで苦労しないんだろうな・・・。

>1をAに、さらにそれをBへ。そしてCに入れ最後にD・・・などもよくあるのですが
>「何故そんなに遠回りを？」と思い追いかける気力が無くなってしまいます。

（実際はどうなのかは分りません）
必要なことで処理を行っているのは当然ありますが、
無駄に処理を行っている場合も絶対無いといえません。
「意味無いだろ」とか「もっとスマートに出来るだろ」というようなソース^^;
しかし、仕様上、ロジックがどうしても複雑になる、
作りこんでいったら結果そうなったという経験も自分にはあります^^;

おおまかな仕様およびロジックを理解してからプログラムを細かく追ったほうがいいですね。
しかしながら、人のプログラムは分りにくいです。
個人の考え方が入っていますから。

すんません。個人的な話でした^^;

回答No.7

wakame0729

コンピューターってバカなんですよ(笑)。なのでなにか動かそうと思ったら、赤ん坊に物を教えるようなつもりで取り組まないといけません。プログラムってそういう作業です。例えば中学生に箸を持たせようと思ったら「箸を右手で持て」って言えば通じますが、赤ん坊(まあ言葉は理解するとしましょう)には「はーい、これは『箸』って言いま～、わかりまちゅか～？は～い、いい子ですね～、じゃあこっちの手の人差し指と親指で・・・」とまあこの位の手間が掛かりますよね。コンピューターを相手にするっていう事は実はこういう事なんですよ。

プログラムコードを読むって実はものすごい大変な作業です。特に人の書いたプログラムはベテランでも読むのが大変です。ただ、１行づつ命令を読みながら自分がコンピューターになったつもりで追って行くんです。今、ここが何なのか、なぜこういう事をしているのか、ああ、だからここでこっちに行くんだ・・・プログラムは1行1行意味があるもので、その意味を考えながら追っていけば、多少は理解が深まります。

ちなみに僕が最初に取り組んだのはファミコンのアセンブラという言語(っていうのかな?)でした。アセンブラって足し算と引き算しかないんですよ。掛け算も割り算も足し算引き算を組み合わせて自分で作るんです。それからすると、始めてC言語っつーものを見た時は感動しました。2*2って書くだけで4になってくれるんだもん(笑)。

お礼

確かに他人が書いたプログラムを理解するのは難しいですね。
質問の時にも書いたのですが「何故こんな？」ということも製作者には当然考えがあってのことで・・・。
落ち着いて一行ずつ読んでいったりしてるのですが段々焦りだしてやけになって「分からん！」となってしまっています。
とにかく一度理解できる段階までいければ何か見方が変わるかなとは思うのですが。
ありがとうございました。

回答No.6

530529

プログラムって、何かをするために作る物ですよね！
ここでは、同意をいただいたとして、今はやりたい事がとても複雑になってきており一つのプログラムでは出来ませんので、複数のプログラムが集まって実現しています。
そうなると、一つのプロクラムの１行では本当に小さな事しかしてないのでそこだけを見ても
質問者が書かれているようになんでこんな事を考えてもしかたがないのでと思います。
もちろん個々の動きが分からなければ全体は分からないとも思いますが、全体からと言うかトップダウンで考えて、何々をするために、このプログラムで何々をしている、さらにこの部分ではＸＸをしているとしておっかけていけばよいので無いでしょうか　？

> 「IF」などで分岐していくとか、「何故そんなに遠回りを？」
と書かれていますが普通のプログラムでは一度に一つしか出来ませんので、やりたい事別にやりたい事を書いて（処理、対応）して行くしか方法が無いのでは無いでしょうか　？

お礼

そうなんですよね。
複数のプログラム・・・これが正直現状でとてもキツイんです。
メモをとっていても別のプログラムに飛んで戻ってきたらもう頭が混乱していて。
頭ではおっしゃっているように仕方が無いと分かっているのですが実際追いかけるとなるとまだまだ私にはデカイ壁です。
ありがとうございました。

回答No.5

poncheke

フローチャートにしてみればなんとなくわかってきますよ。１つ１つの処理を作っていくって感じですかね・・・
いくつもこなしていくうちにわかるようになってきましたよ☆あたしもはっきり言ってキライです・・・見たとたんに「終わってる」ってやる気なくしてました・・・

お礼

「見たとたんに終わってる」・・・まさに私がそれですw
数をこなしていけば慣れるか、というのも考えていたのですが先に参ってしまいそうです。
確かに始めのうちはプログラムよりもフローを追いかけたほうがとっつきやすい感じはしますね。
ありがとうございました。

回答No.4

BLUEPIXY

多分、機能毎の固まりになっていると思うので、
1行1行を追いかけていく前に、
固まりとして理解してから、
その固まりの中を理解するというようにしていったらどうでしょう

お礼

確かにそれもいいかもですね。
全体どころか各ブロックでなにをしているのか、そこまで考えていませんでした。
ただひたすらに「正確に読まないと」と焦っていたところも正直あります。
初心者特有の焦りですかね・・・。周りができている分余計に。
ありがとうございました。

回答No.3

kokorone

最初のうちは、１命令単位で何をやっているのか。
どんな命令で何をやっているのかを把握してくだ
さい。
その次のステップとして、条件分岐など、数ステップ
単位で何をやっているのかがわかるはずです。
それらを頭の中で組み立てようとすると、頭がパンク
してしまいますので、絵とか図に書いて、整理します。
これをフローとか、流れ図といいます。
また、ソースレベルで分からない命令などは、朱書き
など、チェックしておくのも、いいでしょう。

お礼

たしかに頭の中で考えていました。
「さっきこれをやったから今は値が変わってて・・・あれ？」
パンクしっぱなしでしたね。
メモはとっているのですがメモを見返すのもまた一苦労・・・という現状です。
慣れない間は本当に大変です。
ありがとうございました。

回答No.2

Pesuko

＞何故そんなに遠回りを

必要だから・・・

会社の入金伝票処理を考えてください

顧客から入金されます
「入金されたら領収書」だけなら簡単ですが
通常は
元帳を引っ張り出して
顧客名から現在の売掛金の集計をして売り掛け合計から入金を差し引いて・・・

「なんで売り掛け金を集計するの」とは思わないですよね
必要だから・・・・

全体の処理の流れが解っていないから「飛ぶ」必要性がわからないのだと思います。

お礼

全体の流れを分かる前にこっちが先に参ってしまうんですよね・・・。
まぁ私が情けないだけなんですが。
今まではでたらめに追いかけるだけだったんですが流れを意識してみようと思います。
ありがとうございました。

回答No.1

exepieco

まずは仕様書でしょうね。
そのプログラム全体が何をしようとしているのか、そして
全体の中で今見ている部分は何をしようとしているのかをつかんだ上で、このIF文の目的は、と見てみるとよいのではないでしょうか。
#元のソースの品質にもよるのですが・・・
私が解析的なことをする場合、長かったり分岐が多いものはプリントアウトしてまず流れを追うようにしてます。
紙ベースの作業は賛否両論ですが（＾＾；

お礼

私もプリントして追っているのですが、見るだけで「やる気」を奪われるのが一番大きいですね。
先輩曰く「非常にクセのあるプログラム」だそうですw
くじけそうですが、頑張ってみます。
ありがとうございました。