2023年12月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

 

« 今日買ってきてもらった本 | トップページ | やってられるか! »

2009年12月 4日 (金)

プログラム考察:ソースを見て確認するか、プログラムを動かして確認するか

普通、プログラムを作ってもすぐに完全に動かない。人間が作る以上、ミスをしてバグを作り込んでしまうからだ。
そのバグとは、単純なコーディングのミス(よく似た変数名があってそれを間違えたとか条件式の値を間違えてループやif文の思わぬところに入ったとか)から、仕様上の問題(処理順が違う、関数間で思ったデータをやりとりできないなど)など、様々な問題を抱える可能性がある。

これらの問題を解決するにはデバッグするしかないのだが、それにはソースコードを眺めて処理を追っていく方法「机上デバッグ」と実際にプログラムを動かして動きを見ながら問題が発生したら修正する方法「単体テスト・プログラムテスト」がある。

一見、プログラムを動作させて確認する方が簡単に思えるが、そうはいかない。
はじめはつまらないミスが多く残っているので、プログラムを動かすたびに動きが止まったり、思わぬ動きになり、結局はソースコードを読むことになる。
行数(Step数)が多くなるほど、バグを作り込む可能性が高くなり、規模が大きいプログラムではそれだけ動作が止まったり、おかしな動作をしたりすることになる。

なので、一番はじめは机上デバッグで変な値を使っていたりしないか、条件は正しいかなどを確認してから、プログラムを動作させた方が絶対に早い。
重要なのはソースコードを見るときに”観点”を決めて確認しないと、ただダラダラ見るだけで何もバグが抽出できない。(経験を積むと観点を決めなくても分かってくるけど、後に残らないのでメモなりなんなりを作るべき)
ある程度バグが抽出できたら次の段階に進む。ちなみに統計的に単位行数に作り込むバグの量があって、それをプロジェクトの目標として使用する。
プログラムを作成するプロジェクトの計画は、統計的な目標があると非常にわかりやすくなる。

« 今日買ってきてもらった本 | トップページ | やってられるか! »

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

« 今日買ってきてもらった本 | トップページ | やってられるか! »