無料ブログはココログ

amazon

フォト

« 日本の技術は世界一 | トップページ | 月までの距離 »

2010年9月 3日 (金)

ソフトウェアの品質向上のために

システム開発において、品質の高いシステム作りとはなんだろう。
ひとことで言えば、バグのない且つ効率的なシステムとなる。
そのためにはどうすればよいだろうか。

プログラムについては、下記要点が述べられる。
1. 見やすい。
2. 判りやすい。
3. 機能単位になっている。
4. コメントが入っている。

プログラムのソースはコンパイルされたあとはマシンには必要ない。その後必要とされるのは人間が参照する場合である。
その為にも、上記の点が述べられる。肝心なことは、ソースは人間が見るものであると言うことである。

見やすさのひとつは、字下げをすることである。すべて1カラム目から始まっているようなプログラムは見る気がしない。
また、VBなどでのDoのカラムとEndカラムを合わせる事、などである。変数ひとつにしてもcount1, count2ではなく、input_count, tran_countとかの名前にすべきであろう。
その他、subは機能単位でまとめる。云々などがある。

判りやすさのためには、基本的なロジックを理解することである。
ロジックは、「上から下へ」「分岐(if)」「ループ(for)」の3つですべてのロジックが組めることが数学的に証明されている。構造化プログラミング(ストラクチャード・プログラミング)と呼ばれる。アセンブラ等のように特殊な言語を除いて、goto文を使うべきではない。goto文があっただけで、見る気もしない。

基本的なロジックは、配列操作、コントロール・ブレイク、マッチングである。これらの考え方を理解していれば美しいプログラムが作れる。
マッチングにも3本マッチングとなると複雑なロジックになるので、「AファイルとBファイルをマッチングしてABファイルを作り、ABファイルとCファイルをマッチング」のようにプログラムを分けることにより、2本マッチングで書ける。大切なのは3つの基本的なロジックの考え方を理解する事である。

では、仕様書においてはどうだろうか。
仕様書は、「何をするか」を書くものであって、「どのようにするか」を書くものではない。

下記の例がある。
1. iが1から100まで下記を繰り返す。
2. tblのi番目=product_idの場合、繰り返しを抜ける。
3. 上記でない場合は …
:
上記は「どのようにするか」を書いたものである。見る気もしないので、下記のように書き換える。
1. 入力レコードの製品番号が、配列に蓄えた製品番号一覧に存在するかを調べる。
2. あった場合、…
3. なかった場合、…
:
上記は「何をするか」を書いたものである。この仕様書を元に「どのようにするか」はプログラマーの考える事である。

仕様書もソース同様に、人間が見るものである。よって、見やすい、判りやすいに重点を置いて作るべきである。このように作成された仕様書やソースから品質の高いシステムが生まれる。これは基本的な事である。

企業によっては標準化が行われている場合もある。だが、単に生産性を上げることだけを目的としているような、誤解している場合もある。標準化とは品質向上を目的としたものであるにもにもかかわらず、である。

どうせ作るなら、人に見られても恥ずかしくない、美しいものを作ろうではないか。
何でもそうであるが、「安かろう悪かろう」のようなものは作りたくないし、見る気もしない。

« 日本の技術は世界一 | トップページ | 月までの距離 »

パソコン・インターネット」カテゴリの記事