読者です 読者をやめる 読者になる 読者になる

KOSEIのブログ

自分の可能性をどこまでも

プログラム開発工程(続き)<元SE独白記>

コンピュータ

<元SE独白記>プログラム開発工程(続き)  2016/06/14

プログラム開発工程の続きです。昨日は自分がコーディングしたソース・コード(人間がプログラミング言語で記述した大元のコード-プログラム本文-)に論理的な間違いが無いかどうかを念入りに机上でチェックします。もっとも念入りにといっても、特に大規模なプログラムになるとチェックし切れませんからその後の「コンピュータによるチェック」でやればいい、というようになってきますが、仕方の無いことでしょう。眼や神経が最初から余り疲れてしまっても後の作業に影響します。チェック箇所は2つのポイントです。まずは文法チェック、次に論理チェック。このうち文法チェックも確かに大切ですが、論理チェックに重点を置いたほうがいいと思います。論理的にまちがったコードを書くと実行時に動きが止まってしまいキーボードの入力ができなくなってしまったり(大体が無限ループが原因です)、abort(アボート=流産とか、流れが止まるとか言う意味)したりします。アドートとは、俗に「落ちた」というやつです。

コンパイル作業:これはプログラマーがコーディングしたソース・コードを機械語に落とし込むための中間ファイルを作る作業です。ここでの主目的は「文法エラー」を取り去ることです。最初は100行ぐらいの文法エラーは出るものです。しかしエラー箇所を修正すればどんどん減っていきます。大体はニァミス、ポカミスの類です。スペル間違い、入れ子が対応していない(入れ子またはネスティング)、ピリオドがついていない・・・・・等々。エラーコードを見ながら修正していきますが、慣れてくればエラーコードの番号を見ただけで原因がつかめます。問題は見たこともないエラーコードが出てきた場合です。原因を追究していったら深刻なエラーだったという場合もありますが、ある程度考えてみてそれでもわからない場合もあります。そのような時は無視します。なぜかというと、「コンパイラー」も4またプログラムであり、これを造ったのも人間ですから、なかには造った人が間違っていることも充分あり得るのです。ちなみにプログラム上の動作上の間違いを「バグ(虫)」と呼んでいます。バグをなくして正常に動くようにすることを「バグフィックスする」とかいいます。

このコンパイルエラーのうち「定義エラー」は無視します。たとえば外部のファイルを参照したり、外部のプログラム(このプログラムをサブルーチンともいいます。今コールしているプログラム本体はメイン・ルーチンです)をコールしたりしていても、記述はしてあっても実態はまだ繋げていないからコンパイルエラーが出ても当たり前なのです。

ついでに説明しておきますと、外部プログラム(サブルーチン)で外部に出さなくても、内部ですべて終結させることも、もちろんできます。サブルーチンでやっていることを全部メインルーチンに記述すればいいだけの話です。しかしプログラムを設計するときはサイズの問題、メンテナンス性の問題、といった部分を考慮しなければいけないので、特に他のプログラムでもよく使う処理であれば、外部に出してサブルーチン化すべきでしょう。その方が生産性も上がります。

リンケージ作業:上記のようなコンパイル時に定義エラーになった、まだメインプログラムに繋がっていないファイルをすべてこのリンカーが繋げてくれます。この段階でエラーがゼロならあとは実行あるのみです。

実行:僕が使っていた開発環境ではプログラムの実行はすべてコマンドラインからコマンドを打ち込みました。このときの注意点ですが、最初の一回の実行で一回目から正しい動きをすることは100%ありませんから、本番とまったく同じテスト用の環境を作っておき、その環境下でテストを何回も繰り返します。こういう段階を踏まずにもしも間違えて本番環境で実行してしまい、本番環境に深刻なダメージを与えてしまったら、それこそ損害賠償問題です。僕のやっていたのは金融システムや航空システムだったので、、コンピュータが停まってしまうということは、社会に混乱を引き起こし、かつ企業にとっては大損害なのです。

じつはこの「実行」の段階が最終段階だと思ったら大間違いです。いちばん時間がかかる段階なのです。ロジックどおりに動いているのに何故画面上の正しい位置に表示されない?とか、表示はされるが数字が増えている、文字が化けている、こんなことはザラです。何回見直しても原因がわからない、こんなことはしょっちゅうです。自分が趣味でパソコンでプログラムの勉強をしているのなら、判らないのはそのままにしておいても誰も何も言いませんが、プロフェッショナルとして仕事をしている場合はそうも行きません。プログラマーがいちばん胃を悪くするときでしょう。

このような時は「トレーサー」というプログラムを使います。問題の半分近くは解決します。トレーサーとは、順を追って流れを追いかけてくれる(トレースしてくれる)プログラムです。プログラマーが書いたメインプログラムの動きに合わせて、必要な記憶領域の内容等を1命令(演算)ごとに表示してくれるプログラムです。例えばどこかの記憶領域に何かしらのデータを格納したとします。するとここでその記憶領域の内容をみれば間違っているかどうかは一目瞭然です。たとえば本来格納する数字が「1」だったとします。ところがトレーサーの内容を見たらまったく違う値が入っていた!ここが原因だったということになりますね。

ですが、面倒な場合は記憶領域にデータの出し入れが発生するところで自分でディスプレイ命令を挿入しコンパイル、リンク作業を再びおこない、ディスプレイの結果を見て判断します。また「ウォークスルー」という手法がありますが、これには僕もずいぶん助けられました。情報システム用語辞典によると、

ソフトウェア開発において、ソフトウェア成果物の品質向上を目的に、その作成者が主体となって開催するレビューのこと。インスペクションに準じる公式なソフトウェアレビューに位置付けられることが多い。ウォークスルーは、レビューを希望する作成者が数人のレビューアを招集、成果物の内容を順に説明する形式をとる。それに対してレビューアは、説明を通じて対象を追跡・検証し、その誤りや矛盾、抜け漏れなどを指摘するというのが大まかな流れである。カジュアルなグループディスカッションから公式レビューまで、幅広いバリエーションが存在する。いずれにしても、一つの製品を完成させるには色んな方の苦労の結晶だということですね。

KOSEI