「クマデジタル」さんのところで、『バグを仕込んだプログラマ』さんの話が
出ていたので、一応、自称「なんちゃってプログラマ」な自分としても
プログラム品質について整理しておこうかと、エントリーしてみることに。
まず、これはプログラムを組んだ人なら誰でも同意してもらえると思うのですが、
バグというのはプログラムには、つきものでして、完璧なプログラムというのは
事実上、存在しないといっても良いと思います。
言い換えれば「バグは必然的に発生する」わけでして、問題はそれをいかに
未然に発見し、的確かつ迅速に修正できるか、というのが大切なのは
言うまでもありません。
ここで問題となるのは、「バグはプログラマの責任なのか？」という点です。
私もこれまでいろんな場面でバグに出くわしてきましたが、バグが発生すると、
往々にして、バグを作り込んだプログラマが責任の矢面に立たされる
ことになります。
無論、「バグを出さない努力をする」ことは大切ですが、私は常々、
「バグが残らない環境作り」を重視するように心がけています。
ソフトウェアの品質を考える上で、最近良く使われる言葉に
「ソフトウェアメトリクス」というものがあります。
具体的な内容は他の解説に譲るとして、要は「品質の数値化」が
大切だという考え方にあるものだと思います。
最近は「Resorce Standard Metrics」といったソフトウェアもあって、
細かく分析・数値化して、品質状況を確認することができます。
品質向上自体も人によるレビューだけでなく、「C++Test」や「PGRelief」、
「Boundschecker」などといったソフトウェアで、半自動で品質向上を
図ることもできるようになっています。
管理面でも「Duepark」なんていうソフトもあって、これも便利です。
こうしたツールによる「環境作り」と合わせて、工程やレビュー自体の
実施要領もしっかり『設計』することが大切ですね。
漫然と時間だけ掛けてテストやレビューをしても、効果が上がらず、
結局バグに泣いた例を多々、見てきましたからねぇ。(^^;
私が考えるところでは、バグは「発生させたこと」＝プログラマやバグそのものに
責任を置くのではなく、「発生を未然に防げなかった開発体系上の欠陥分析」に
重きを置いて捉えるべきだと思うのです。
もちろん、若手プログラマや協力会社さんの品質意識向上も、体系作りの
一環として、とても大切なことではあります。
そういう点では、「若手SEのための ソフトウェアテストの常識」という本が
オススメです。
 |
若手SEのための ソフトウェアテストの常識 秋本 芳伸 岡田 泰子 ディー・アート 2006-01-25 by G-Tools |
タイトルには「若手SEのための」となっていますが、品質の捉え方、考え方が
大変良く整理された本ですので、ソフトウェアにかかわる方は、一度、
目を通してみられると良いかもしれません。
(当サイトでは、Amazonアソシエイトをはじめとした第三者配信のアフィリエイトプログラムにより商品をご紹介致しております。)
