BLOGあります

■品質を確保するためのユニットテスト

　シンプルぱっと２の品質を確保するために、VBUnit3という単体テストツールを導入しています。また、 このツールを利用するため、生産性を高めるために、可能な限りオブジェクト指向という開発手法に従ってコードを書いてます。

　シンプルぱっと２の主要機能は、「クラス」と呼ばれる単位で書かれており、 VB6の場合はひとつのファイルにひとつのクラスが記述できるようになっています。クラスは他のソフトでも流用が利くように作れば、 生産性をあげるのに大きな貢献をしてくれます(おっず道楽SPAT4はシンプルぱっと２のクラスを利用するために、 かなりの手直しをしました)。

　シンプルぱっと２で使っているクラスは、約2年半前から開発がスタートしました。 このころは単体テストツールの導入にようやくこぎつけた頃であり、「テスト」自体も不慣れなことからあまりよい構成になっていませんでした。
　そこで、今回はクラス構造の見直しとテストケースの見直しを同時に行っています。 単に機能を追加するだけならすぐにできますが、品質を同時に確保するためにはどこかで見直しを行う必要があり、 これは避けて通れないことです。

　今回は構成そのものを見直したため、すっきりとしたクラス構成に生まれ変わりましたが、古いコードも入っているため、 なぜそのような実装になっているのか悩んでしまう局面もありました。

■変更点管理

　吉田はソースコードの変更点管理にCVSというバージョン管理ソフトを導入しています。 これはシンプルぱっと１のリリース後に導入したもので、シンプルぱっと２の場合は開発当初から利用しています。
　バージョン管理ソフトを利用する利点は、ソースコード等に関する変更がすべて記録されるため、リリース後に前のソースと比較したり、 古いバージョンを取り出すのが容易に行えることです。

　どこにどんな変更を加えたかは履歴を追いかければ容易に発見できます。しかし、バージョン管理ソフトで追跡するには、 レポジトリと呼ばれるデータベースに変更点を追加する必要があります。この作業をコミットと呼びます。
　コミット時にファイルの「リビジョン」、「変更箇所」といった情報は自動的に記録されます。でも、「何の目的でどんな変更をしたか」 は記録されません。コミット時にコメントをつけられるものの、面倒なのであまり積極的には利用してません。

　長い間ソースコードをメンテしていくと、「何の目的」で、「どういう理由」 でといった「背景」が重要になってきます。
　また、わざと処理がコメントアウトされて無効になっている箇所などがあり、これは何のためにやっているかが分かりません。 作業当時は明確になっているこれらの動機も、時間の流れと共に忘却の彼方に消えてしまいます。

　紙やウェブ上(主にWikiなどのツール)にも設計資料は残ってますが、細かな資料までは残っていません。 資料や記録にない処理はやはり、コードを追いかけて「理由」を探ることになります。
　ソフトウェアはドキュメントと、現物の整合性を取るのが難しいと言われており、きちんと管理するとこの部分のコストは鰻登りになります。
　ましてや、自分だけが見るコードにそこまでコストをかけるのもばからしい話です。

■最もシンプルな管理手法

　一番確実で、最もシンプルな方法はソースコード中にコメントとして残すことです。 まるっきり中身が変わってしまったような処理をコメントと残しておく理由はありませんが(これはバージョン管理ソフトの範疇です)、 一部の仕様を変更した際などにコメントを1行追加するだけでも大きく違います。

　ケースバイケースですが、バグフィクスのような誤りを訂正するなら不要ですが、仕様上の変更、 動作変更の際には必ずその理由を記録するようにします。単純ですが、最も効果がある方法だと思ってます。