苦学楽学塾 ホームページ
最終更新日：2025年1月1日
鎌倉時代末期に吉田兼好により書かれた随筆「徒然草」の冒頭に、
つれづれなるまゝに、日くらし硯に向かひて、心にうつりゆくよしなしごとをそこはかとなく書き付くれば、あやしうこそ物狂ほしけれ。
と書かれています。思うままにそこはかとなく、エディタにソース・プログラムを打ち込んで、そのまま、思い通りの仕事をしてくれれば言うことはないのですが、最初に書かれたソース・プログラムがそのままで期待通りの動作をしてくれる、ということはありません。それなりに、しっかりと検討を積み重ねて制作に当たらないと、開発に予定外の時間がかかったり、完成したと思っても実際に運用してみるとボロボロだったり、障害が発生したときに対処不能になる、というようなことが起きます。ソフトウェアは、ほぼ以下のような流れで、開発が進められますが、その逐一で、よく検討して確実な手順で進める必要があります。
(1) システム設計
プログラム開発の最初に、「システム設計」と呼ばれる工程があります。プログラム開発時点では、なかなか、プログラムの全貌についてイメージが湧かないのが普通ですが、ここで手抜きをして先に進んでしまうと、特に共同作業で開発を進める場合に大混乱に陥ります。
(a) 制作ソフトウェアの目的の検討
まず、何をするソフトウェアなのかをしっかり確認しておく必要があります。手作業で行ったのでは膨大な作業量になってしまう面倒なことを省力化・効率化したいわけですが、
何をするのか、
何のためにするのか、
どうやって実現するのか、
要求効率はどの程度のものか、
を確認しておくことが必要です。ソフトウェアの目的をいくら考えても、動作時間の検討をしてみたら無意味だ、というようなことも起きます。
例えば、天気予報のシステムを開発しようというときに、各地域の１日分の気圧や温度などのデータを処理して次の日の天気予報をするのに必要な処理時間が10日かかる、というのでは、ソフトウェアが全く無意味です。天気予報が出る前に次の日になってしまいます。ハードウェアを10倍以上高速なものにするか、計算アルゴリズムを工夫するか、何らかのブレークスルーが必要になります。さもなければ、ソフトウェアの内容をより簡略なものにすることも考えられますが、外れてばかりの天気予報ではやはり無意味です。
(b) ソフトウェアの内部構成の検討
次に、目的を達成するために必要な作業を細かく分解し、どういう手順で行うかを検討します。ここをしっかり検討しておかないと、コーディング作業に入ってからうまく進まず、システム設計のやり直し、という事態に追い込まれます。
プログラムは、必ずしも１つのメイン・ルーチン(C言語では、main()という関数)だけで記述されるものではなく、メイン・ルーチンには、幾つかのサブルーチンを並べ、各一の作業はサブルーチンが担当する、という作りになります。各サブルーチンもまた幾つかの作業に分けられるかも知れません。分解された作業を、プログラミングし易い形に整理配列し、相互関係、共通して使うべきデータ・処理内容、優先度、などを詳細に検討します。作業Ａを実行してからでないと作業Ｂが実行できない、作業Ｃは作業Ａ・作業Ｂの結果を両方とも使う、というような関係を検討しておきます。場合によっては、データ読み取り→データ処理→結果出力、というような一本道では処理が困難で、データ読み取り→処理に必要な環境設定→環境設定に基づき、データ読み取り及び実処理→結果出力、というように、データ読み取りを２回繰り返す必要がある、というような場合も出てきます。ここがうまく行かないと、データ処理を行いたいのに、必要な基本データが揃っていないためにコーディングできない、というようなことが起こります。
例えば、先の天気予報で言うと、データ処理で各地の風力を計算したいのに隣接地域の気圧が求められていない、とか、地上の温度・湿度による上空の雲の状況が計算できていないのに次の時点の地上の温度を求められない、とか、計算の順序をうまく設定する必要があるのです。
(c) 全般的流れ・全体構成の検討
次に、細かく分けられた作業の各一をどのようにプログラミングするかを検討します。必要なデータ、データ構造、データを格納する記憶領域、計算して得られるデータの初期化、データ処理の結果の収納の手順、結果出力するためのデータの保持の仕方、などを詳細に検討します。その上で、各作業をどのような関数にまとめるか、各関数の中でどのように処理を進めるか、手順書・フローチャートの形で整理します。複数の人で開発を行う場合には、各手順・各作業を誰がどのように担当するか分担を決めます。
全般的な流れの中には現れなくても、各関数の行う作業の中で共通・あるいは類似の処理を行う部分を切り出してサブルーチン化します。また、サブルーチンを呼び出す上での前提条件、サブルーチンの引数、サブルーチンがどのようなデータをどのように返すか、を検討し、これも、きちんと文書化し、無駄な作業を二重、三重に行うことがないようにします。二重に行われるのではなくても、処理の中身が複雑な場合、サブルーチン化して全体的な処理の流れが複雑にならないようにする場合もあります。
フローチャートですが、紙の上に書いていくと、ちょっとしたサブルーチンでも意外に場所をとり、思うように書けないかも知れません。最近は「疑似コード」という考え方があるそうです。C言語プログラムの構造のページにその一例を書いているので参考にしてください。C言語プログラムの体裁をとりつつ、詳細のコーディングではなく処理内容だけ書いていく、というものです。
(d) ソフトウェアの動作態様の検討
ある程度プログラムの内容が明確になってきたら、処理を行うためにプログラムに入力するデータの形式などを検討します。データ入力を人手で行う場合には、複雑にならないように、ミスが入り込まないように、ミスが入っても警告できるように、プログラムの内容を検討し直します。場合によっては、実動作を想定するとプログラムがうまく対応できない場合が出てきて、プログラムの手順を再検討しなければならない場合も出てきます。
逆行列計算を掃き出し法でプログラミングしていたら、実際のデータを入れてみると、ピボットがゼロあるいは絶対値が非常に小さい数値になってしまって、結果が充分な精度で得られない、あるいはプログラムが途中で動作停止してしまいかねない、ということが判明し、連立方程式の解法をさらに工夫しなければならなず、全体の流れに影響がでてしまう、というようなことも起きます。
こうしたことも、あらかじめ事前につかんでおくことが望ましいのです。不幸な場合には、コーディング中、デバグ中、あるいは運用開始時点で発覚した問題点のために、全体の処理の流れ自体を再構成しなければならず、プロジェクトが最初からやり直しになる(なら良いのですが、プロジェクト中止・開発失敗ということさえあり得ます)、というようなことも起きます。
また、出力形式も、ユーザーが結果を見易く理解し易い形で出力できるように、またそのように出力するための内部データの保持の仕方などを検討する必要もあります。
以上の内容を、入力仕様書、出力仕様書、全体の流れを記述した基本仕様書、複数人で開発する場合に必要となるサブルーチンの呼び出し法を説明した詳細仕様書などの形でまとめます。
(2) コーディング作業
できれば、場当たり的に泥縄式にコーディングを進めるのではなく、基礎的な部分から順次デバグを行えるように、開発に必要となるサブルーチン群について、コーディングがどれくらい進んでどれくらいデバグが進んでテスト完了しているか、ということを可視化した工程表を作って作業の進捗状況を管理することが望まれます。複数人で開発を行う場合には、進捗の遅い部分に人力を投入する必要もあります。
コーディングに当たっては、ソース・コードを、TABなどを用いて、
int sub1(int j1, char *p1) {
int j2, ret;
char c1;
while (c1 = *p1++) {
for (j2 = 0; j2 < j1; j2++) {
if (ret = sub2(c1, j2)) return ret;
}
}
return 0;
}というように、'{'が出てくる度に、右に1TAB(上記はTAB1つで空白4個分にしています。TAB1つで空白8個が普通ですが、エディタですぐ行あふれを起こし見づらくなります)ずつ行下げを行い、処理手順が見易くなるように記述するのが、複数人で共同作業するときのエチケットです。
int sub1(int j1, char *p1){int j2,ret;char c1;while(c1=*p1++){for(j2=0;j2<j1;j2++){if(ret=sub2(c1,j2))return ret;}}return 0;}と詰めて書いても、コンパイルして動作させることはできますが、これでは、この関数がどのように動作しているのか、見ているだけではわかりません。ソフトウェアが、運用後に障害を起こし障害原因を調べるために、他の第三者がソース・コードを眺めるということはよくあることなので、自分が分かれば良い、というわけには行きません。但し、上記は私なりの書き方で、このような字下げ記述の方法も人により異なります。自分だけで開発するなら、自分が後で眺めて理解できれば良いですが、複数人のプロジェクトの場合には、書き方をメンバー間で統一しておかないと混乱のもとになります。
また、プログラミング手法で、構造化プログラミングと言うのですが、分岐構造のみ先に記述して、分岐の中身を極力関数として記述する、というプログラミングの仕方もあります。また、人によっては、goto文を禁止する、という人もいます。私個人の考え方ですが、分かり易くすることが第一で、却って分かりにくくなるのに自己規制するのは自縄自縛で逆効果ではないか、と思います。私は、分岐構造の中に、たとえ長くなっても処理を延々と書き連ねることもあるし、goto文も積極的に使います。但し、goto文を避ける工夫はあります。例えば、goto文を使って、
for (j1 = 0; j1 < limit; j1++) {
if (strcmp(array[j1], "normal") goto error_process;
}
･･････
return 0;
error_process:
return -1;というようにしたくなる場合に、
j2 = 0;
for (j1 = 0; j1 < limit; j1++) {
if (strcmp(array[j1], "normal") j2 = 1;
}
if (j2) return -1;
else {
･･････
}
return 0;
とすれば、goto文を避けることができます。ですが、goto文を使わないことで却って見にくくなるのであれば、正規に認められているgoto文の使用は何ら差し支えないと、私は思います。
また、while文、if文、for文を使う場合、コーディング中に、
while () {}とか
if () {}
else {}とか、
for () {}と先に、()、{}をペアにして先に書いてしまうというクセをつけるようにしましょう。
while (c1 = *pc1++) {としたまま、この次の行から処理内容を書き続けてしまうと、whileループ終了の'}'を書き忘れてしまうミスをし易いのです。処理内容が長い場合、'{'に対応する'}'がないために、コンパイル時点で不可思議なエラーが出て原因がつかめず苦労することになりかねません。高機能なエディタ、例えば私の使っているMIFESというエディタでは、
while (
とタイプインした時点で、ペアとなる')'を付加して、自動的に
while ()
としてくれます。また、
while (c1 = *pc1++) {
･･････
}となっているときに、後の'}'のところにカーソルを持ってくると、前の'{'が太字で表示されて、対応するカッコを教えてくれて非常に便利です。ですが、メモ帳や、WORDなどで、ソース・コードを打ち込む場合には、そうした便利な機能はないので、充分に注意してください。
(3) デバグ作業
コーディング作業が終了したら、コンパイルに移ります。夥しいエラーの量に足がすくむかも知れません。ですが殆どがタイプ・ミスで深刻なミスはむしろまれです。一つ一つ片づけて行けば、いつかは終わります。私の経験では、コンパイル・エラーで分かりにくいエラーは、'{'と'}'が対応していないことによるものです。対応していない、というメッセージではなく、もっと副次的な困難によるエラー・メッセージが並ぶので、原因がなかなかつかめない、ということがよくあります。コンパイルも修正するたびに一々、
gcc -c new_project.c
gcc -c subroutines1.c
gcc -c subroutines2.c
gcc -c subroutines3.c
とタイプインするのでは面倒です。C言語では、makeという便利な機能が用意されています。makefileというテキスト・ファイルに、実行プログラムnew_project.exeを作るために何が必要か、ということを記述しておくと、makeとタイプインするだけで、必要な作業を行ってくれます。makefileは基本的には、
ターゲット: ターゲットが依存するファイル
コマンド
という形で記述します。ターゲットよりも、ターゲットが依存するファイルの方が新しいと、次の行に書かれたコマンドが実行されます。コマンドは、左側に[TAB]を入れてターゲットから下げて記述します。new_project.c，subroutines1.c，subroutines2.c，subroutines3.cが共通のインクルード・ファイルcommon_inc.hをインクルードしていて、それぞれコンパイルすることにより、new_project.o，subroutines1.o，subroutines2.o，subroutines3.oを生成するとします。さらに、new_project.o，subroutines1.o，subroutines2.o，subroutines3.oをリンクすることにより、実行ファイルnew_project.exeが作られるというのであれば、makefileの内容は、
new_project.exe : new_project.o subroutines1.o subroutines1.o subroutines3.o
gcc -o new_project.exe new_project.o subroutines1.o subroutines2.o subroutines3.o 2>newl.log
new_project.o : new_project.c common_inc.h
gcc -c new_project.c 2>newc.log
subroutines1.o : subroutines1.c common_inc.h
gcc -c subroutines1.c 2>sub1.log
subroutines2.o : subroutines2.c common_inc.h
gcc -c subroutines2.c 2>sub2.log
subroutines3.o : subroutines3.c common_inc.h
gcc -c subroutines3.c 2>sub3.log
となります。gccコマンドは、gcc -cとすればコンパイルを行い、gcc -oとするとリンクを行います。makefileの内容も凝ればいろいろとできますが、基本的には、上記で充分です。各コマンドのラストに、2>newc.logというようなものをつけていますが、コンパイル、リンク時のエラー・メッセージは標準エラー出力に出力するので、これを>の後に書かれるファイルにリダイレクトして出力するという意味です(C言語の主要関数を参照)。これで、どのソース・プログラムを修正しても、makeとタイプインするだけで、コンパイル・リンクを行えます。エラーが出るときには、リダイレクトしたファイルを開けば、エラー内容を確認できます。
コンパイルが通り、実行ファイル(拡張子がexeのファイル)ができたら、動作させてみます。環境変数PATHに、実行ファイルが位置するディレクトリが登録されているのでなければ、実行ファイルの位置をフルパスで指定して実行ファイル名をタイプインして起動させます。上記のnew_project.exeが/home/user/newproに置かれているときは、カレント・ディレクトリが/home/user/newproであっても、CYGWINのコマンド待ちのところから、
home/user/newpro/new_project.exe
と入力する必要があります。実際に動作させて期待通りの結果が得られればデバグ完了ですが、注意深く作成していても、なかなか期待通りには動いてくれません。printf()をソース・プログラム中に入れて、プログラムの進行状況や各変数の値をモニタすることにより、プログラムを修正しては動作確認するという作業を繰り返します。それでも、プログラム中の問題点が究明できない場合は、デバガgdbを利用することになります。詳細は、C言語のデバグを参照してください。 デバグ作業中、特に、原因がつかめないバグのときには精神的にもきつくなりますが、この作業が、ＩＴの核心と言えるところなので、時には、スポーツや音楽で気晴らしをしつつ頑張り抜くしかありません。私の経験で言うと、バグ原因をつかむのに1ヵ月かかった、というようなこともありました。バグ原因そのものよりも、バグ原因を調べる方法を考えるのに長時間の忍耐と工夫が必要、ということもあります。東大理系の数学の難問を考えるのと同じです。
(4) 運用テスト
デバグ作業が完了し、様々な入力パターンを様々なタイミングで加えても問題なく動作するようになったら、実際に運用して動作状況を確認します。ここで大きなトラブルを起こしてしまうと、開発失敗となりかねないので、デバグ作業は完璧に行っておく必要があります。ただ、それであっても、想定不可能な微妙なタイミングのずれなどによって、システムがクラッシュしてしまうことがあります。銀行システムのような膨大な開発費用と人数を必要とする巨大システムであっても、2023年10月、バージョン・アップ時に、メモリ空間の作業領域不足を起こして他行宛の振り込みができなくなり、大きな問題を引き起こした、という事例があります。
安定して動作しているように見えても、危険な個所をうまくすり抜けて動いているだけ、ということもあり得ます。勿論、障害が起きたときに、真摯に対応することも重要ですが、(1)(d)で述べたように、詳細な仕様書を残しておくことが、早急な対処を行い、顧客の信頼を勝ち取ることにつながります。
(5) 文書化
プログラムの動作、デバグ・テストの内容などに関して詳細に記述した文書を残すようにしましょう。場合によっては、システム開発よりも、文書化の方に長い時間がかかるかも知れません。社会に提供して使ってもらうシステムだけでなく、個人的に使うものであっても、障害が発生した場合には、文書がなければお手上げになります。あれっ、これどうだったけな、という事態を避けるようにしてください。
デバグの過程で、バグの原因がどういうことで、どう対処したのか、ということを更新記録に残しておくのも、トラブルが起きたときの対処の役に立ちます。対処の方法自体に抜けがあった、勘違いがあった、修正が修正になっていなかった、ということも多いのです。小さいバグであっても、ユーザーにトラブルを指摘された場合、あるいは、機能追加の更新をした場合には、年月日、トラブル内容、何が原因でどう対処したか、という更新履歴を残すようにします。
【広告】 ここから広告です。ご覧の皆さまのご支援ご理解を賜りたく、よろしくお願いいたします。
【広告】 広告はここまでです。