プログラミングの楽しさ: プログラムの作り方
ふだん何気なく考えて判断したり行動したりしていることを細かい処理に置き換えていく。それがプログラミングです。一見華やかそうですが、わりと地味な努力の積み重ねによってプログラムは作られています。
前回の続き
前回はコンピュータが動く仕組みについて書きました。今回はプログラムを作る方法について説明します。業務と趣味の違い、作るプログラムの内容によって、やり方は様々ですが、わりと一般的な方法を書いてみました。
今回もすでにプログラミングを知っている人には、ここから先は退屈な話ですので、あしからず。
プログラムの作り方
大まかな仕様を考える
まずはどんなプログラムを作るか決め、それがどんなふうに動くか考えます。
例えばWindowsの電卓を作るとしましょう。どんな機能をつけるか、ボタンを配置する位置は、計算結果を他のソフトウェアと共有する方法は、等々、プログラミング作業をある程度想像しながら、プログラムの構成を考えていきます。
ここでは中身を細かく考えるよりプログラムの大まかな目標や方針について決めるのがいいでしょう。例えば、軽くて気軽に使えるようにする、なるべくユーザの入力を少なくする、などなど。プログラムを作っている間に仕様変更は何度もありますが、方針が決まっていれば、その時の判断が楽になり、使い勝手の統一された、使いやすいものになります。
仕様を元にプログラミングコードを書く
考えた仕様を元に、プログラミング言語に変換していきます。この作業のことをコーディングと言います。
前の記事でコンピュータが理解できるのは機械語と呼ばれる単純な命令群であることを説明しました。機械語はとても単純です。人間同士なら漠然と｢ここではこれしといて｣ぐらいに指示しておけば問題ないようなことでも、コンピュータに対しては一つ一つ手順を指示してあげなければなりません。高級言語はその作業をだいぶ楽にしてくれますが、基本的な考え方が変わるわけではありません。
例として、以下のような値を小さい順に並べ替えるプログラムを作るとしましょう。
１２ ３１ ５ １１ ３７ ５８ ７ ８８ ７５ １６
人間であれば、ぱっと見た瞬間にどのように並び替えればいいか、イメージできるでしょう。でも、コンピュータが一度に見渡せるのは、せいぜい1個か2個です。一度に見渡せないとしたら、あなたはどのような方法で並び替えをしますか？
１２ ３１ XX XX XX XX XX XX XX XX
ふだん何気なく考えて判断したり行動したりしていることを細かい処理に置き換えていく。それがプログラミングです。なんか難しそうに思えるかもしれませんが、慣れるとそれほど難しくはなく、とても楽しい作業になります。
実現したい機能がすでにあるかどうか調べる
プログラムで実現したい機能がすでにあるかどうか調べます。
プログラムを0から全て自分で作ることはまれです。すでにOSが機能を提供していたり、サンプルプログラムがあったりします。これによりプログラムを作る手間を省けるとだけでなく、多くの人に使われて安定している機能を利用することで、プログラムの品質を高めることが出来ます。
コンパイル
C/C++などを使ってプログラムコードを作ったら、それを機械語に変換します。この変換作業のことをコンパイルといいます。
プログラミング言語は人間が扱う言語より厳密に定義されています。最初のコンパイルでは多くの文法エラーが出ることでしょう。文法の間違いを正し、エラーがなくなるまで繰り返しコンパイルをします。
言語によっては、コンパイルという手順を必要としないものもあります。その場合も、最終的にはコンピュータが実行できる形式に変換されます。
デバッグ
コンパイルが完了したら、実際に動かしてみます。一発でプログラムが期待通りに動くことは少ないです。たいていどこかで間違いをしています。プログラムの間違いを見つけ、プログラムコードを修正し、コンパイルしてまた実行という作業を繰り返すことになります。この作業をデバッグといいます。
プログラムの間違いをバグといいます。バグを見つけてプログラムを直すという意味で、デバッグと呼ばれています。
デバッグは最初だけでなく、テスト中や完成後にも行われます。プログラムが誰かに使われている間はずっと行われていると思って間違いありません。一般的に、後になればなるほどバグ探しは難しくなるうえ、再テストの手順も増えていきます。最初にどれだけバグを潰しておくかが、プログラムの品質向上と早期リリースのため、重要になります。
テストと評価
プログラムがある程度動くようになったら、次はそれをいろいろな角度からテストしてみます。
まずは自分自身でプログラムを評価してみます。使いにくいところはないか、インタフェースは分かりやすいか、待たされてしまうことはないか、等々いろいろな観点から見てみましょう。最初の設計に問題があるようなら、思い切って仕様から検討し直すことも必要です。理想はマニュアルを見なくても使い方が自然に分かるプログラムです。
可能であればプログラムを利用者に広く公開し、フィードバックをもらうのもよい方法です。多くの人に見てもらうことで、自分では思いもしなかった改善点やバグを発見してもらうことができます。
総合テスト
プログラムの完成度が上がってきたら、最後に品質を高めるために総合的なテストを行いましょう。
この時点ではあまり機能追加は行わず、プログラムの動作を安定させることに注力します。大量のデータを与えて見たり、メモリを少なくしたりする、などプログラムをいじめて見ることも安定化に役立ちます。
バグが見つかっても、よほどのことがない限り、大規模な修正はしないようにします。再テストの工数の問題もありますが、多くの修正はプログラムの安定性を損ねます。小さな修正も影響が小さくなるよう慎重に行った方がいいでしょう。大規模な修正が必要な場合は、次のバージョンで変更するようにします。
リリース
総合テストが終了したら、いよいよ利用者への配布です。
テスト期間内と違って、リリース後はプログラムを簡単に直すことは難しくなります。完全にバグを0にするのが理想なのですが、現実にはそれは不可能に近いので、ここまでなら安心してプログラムを利用できるという見極めが大切です。
メンテナンス
リリース後もプログラムの改善とバグ修正は続けられます。
実際に利用する環境と全く同じ状況でテストをすることは難しいので、テスト中は思いもよらなかった問題が発生することも珍しくありません。情報が少なくて原因の究明が困難な場合は、情報を収集するための特別なバージョンを作成してテストしてもらうのも、一つの方法です。
次回は本題
またもや話が長くなってしまいました。どうもすいません。
次回は本題であるプログラミングの楽しさについて述べて見たいと思います。
