1万ステップのプログラムをデバッグする方法

障害が発生した場合はこれまで紹介してきた方法で

　・メッセージの発生元をF9キーで探る

・WRKACTJOBでエラーの実行スタックを調べる

という方法でエラー場所を特定することができた。

次に厄介なのは表示や印刷出力で目的とする結果が
得られない、あるいは誤った結果が表示/印刷されている場合の
原因を探る手法を紹介しよう。
しかもそのプログラムが 1万ステップ以上ある莫大なもので
あなたが今日初めて見るプログラムである。
さあどうする?

論理的な思考ができない人は日常からエラーが起こると
原因はこれかな? それともこれかな? と
当てずっぽうで原因を探るタイプの人である。
このようなタイプの人は考えるとは「思いつく」ことだと
思っているようでとても1万ステップの解析はできない。

さて次に多いタイプは1万ステップのプログラムを
頭から(先頭から)順にソース・プログラムを読みだして
このプログラムが何を処理しているのかを
読取ろうとするタイプである。

このタイプの人にも1万ステップの解析はできない。
人間がソースを頭のメモリに入れられるのは
せいぜい2千ステップ程度である。

正解は誤った出力の場所を最初に特定したら
その出力を行っているところはどこか?
次にその演算の前の処理はどこかと
対話式デバッグでもよいから逆に逆にと
遡って調べていくことである。

と遡ってしらべていく。

このような方法で逆に遡って解析するように
すれば必ず原因を生んでいる箇所に突き当たる。

もちろん途中で大いに想像力を働かせて
いろいろな変数を仮定してみることが
重要であるのはいうまでもない。

逆からの調査であれば1万ステップでも10万ステップでも
同じであるし他人が書いたプログラムであっても
怖がる必要は何もない。
そのプログラムのすべてをわかる必要はない。
エラー箇所を突き止めることが目的なのである。

それがわかると明日からのデバッグは楽しくなる。
(実はこれは数学の問題の解き方と同じである)
少しずつ犯人を追いつめていってこれが犯人だと
見えてきたときは痛快である。

デバッグこそ思考力と論理的な推理力を鍛えるに
おあつらえ向きのシチュエーションはない。
大いにデバッグを楽しんで頂きたい。