OuDiary - OuDiaプログラム開発日誌

　OuDia Ver0.05.03 を公開してから3日が経過しました。

　OuDia Ver0.05.03 では開発環境を Visual Studio 6.0 から 2008 に置き換えました。ユーザーの皆様のPCにうまくインストールできるのか心配しながらのリリースでした。しかし、それから3日間、ダウンロード数は170ですが、インストールに関する苦情は今のところゼロです。うまくインストールできているみたいですね。

　・・・と、いう解釈の結果、僕は安心してPCから Visual Studio 6.0 をアンインストールしたのでした。

　実は、僕のPCはハードディスク容量が不足しつつあります。Visual Studio 2008 をインストールしたことにより、ディスク容量の逼迫はさらに深刻になりました。このため、一刻も早く古い Visual Studio 6.0 を削除してディスク容量に余裕を持たせたいと思っていました。でも、もし OuDia Ver 0.05.03 でのインストールの障害連絡が来た場合は、原因究明のために Visual Studio 6.0 が必要になってしまいます。

　そんなことを考えながら、僕は Visual Studio 6.0 の削除のタイミングをずっと見計らっていました。 今回、インストールに関する障害情報がないことにより、削除の決断ができたのでした。
 

 このたび、自宅ＰＣのソフトウエア統合開発環境（※)を更新しました。

　従来は、Ｖｉｓｕａｌ Ｓｔｕｄｉｏ 6.0 という統合開発環境を使っていました。しかし、Ｖｉｓｕａｌ Ｓｔｕｄｉｏ6.0 は 1998年の発売で、今となっては古臭いものになっていました。これを最新の Ｖｉｓｕａｌ Ｓｔｕｄｉｏ 2008(Standard Edition)に置き換えました。

※統合開発環境：　簡単に言えば、ソフトウエアを作成するためのソフトウエアです。詳細は、こちらを参照。　

　Visual Studio のバージョンアップは、6.0 以降、.NET・.NET 2003・2005・2008 と小まめに行われていました。しかしながら、安サラリーマンの僕には、Microsoft のバージョンアップのたびに万単位(ものによっては十万単位) の支出をするわけにはとてもいかなかったんですね。このため、Visual Studio のバージョンアップをずっとためらってきたんですが、さすがにそれにも限界が来て、このたび一気にバージョンアップを行ったわけです。

　というわけで、早速OuDiaを Visual Studio 2008 でビルドしてみました。すると、古い Visual Studio 6.0 では発見できなかったバグが露見して大汗をかくという始末。10年ぶりのバージョンアップの効果を早々に見せ付けられる羽目になりました。これ以外にも、開発効率を上げるための新機能がいろいろと追加されています(特に、IntelliSence が比較にならないほど賢くなっています)。

　今回リリースした OuDia Ver0.05.03 は、Visual Studio 2008 による最初のOuDiaとなります。

　僕としては、OuDia　Ver.0.05.03がうまくインストールができるかどうかが心配です。Visual Studio 2008 のインストールと同時に、僕のPCにはWindowsの最新モジュールが導入されているようです（Microsoft .NET Framework 3.5 など）。このため、他のPCで同じように動作するか否かの検証が難しくなってしまいました。 特に心配なのは、以下のような動作環境です。

• Windows Update をあまり行っていないPC
• Microsoft Office がインストールされていないPC
• OSがWindowsXP以外のPC（これは「サポート外」という言い逃れはできますが・・・）。

　そのようなわけで、インストールに問題が起こった場合は、ぜひ作者にお知らせください。この場合、以下の情報をお寄せいただければありがたいです。

•  WindowsのOSのバージョン（[スタート]→[コントロールパネル]→[パフォーマンスとメンテナンス]→[システム]で確認できます）
• .NET Framework のバージョン（[スタート]→[コントロールパネル]→[プログラムの追加と削除]で確認できます）
• Windows Installer のバージョン（[スタート]→[コントロールパネル]→[プログラムの追加と削除]で確認できます）

新人プログラマからよく聞かれる発言に、こんなのがあります。

「プログラムを動作させてみたところ、実際に出力されたデータは正しい値の10倍でした。そこで、データを出力直前に10で割るようにしました。これにより、プログラムは正しく動作するようになりました・・・」。

しかし、これで 仕事が終わりになったつもりになっているようなプログラマが作るのは、おろらく理解困難な低品質プログラムです。

データが正しい値の10倍になったのには、それまでの処理の過程に必ず原因があるはずです。もしかしたら、それは設計の根本に関わるような勘違いかもしれませんし、他の処理でも同じような問題を抱えているかもしれません。

その根本原因を放置して「10倍の値が出たから10で割って正しい値が出るようにしました」では、後からそのプログラムを見ても「何でここでは10で割っているのか？」ということが分かりません。こういうつじつま合わせが積み重なったプログラムは、意図不明の処理が満載の、理解困難なものになるわけです。

　こういう対応をするプログラマは、
　　「どうすれば『正しく動くプログラム』になるのか」
というところまでしか見えていないように思われます。いや、もしかしたら
　　「どうすれば上の人に言われたとおりに動くプログラムになるのか」
ということしか考えていないのかもしれません。

でも、『正しく動くプログラム』と『正しく作られたプログラム』はイコールではありません。 冒頭に挙げたプログラムは、『正しく動くプログラム』であったとしても『正しく作られたプログラム』ではないんですね。

『正しく作られたプログラム』を作るプログラマは、「このプログラムはどうあるべきか」という考え方をとります。そういう人は、10倍の値が出た時点で、原因を究明しようとします。たとえ、その時点では動かすことを優先して10で割るという応急処置を施したとしても、それを放置することはせず、いずれ機会があればプログラムの構造を正常化します。

世の中には、「開発を進めていくうちに、いつの間にか設計が破綻していた」というプログラムの話はいくらでもあります。それを避ける必要条件の一つは、

• プログラマ一人ひとりが『正しく作られたプログラム』への意識を失わないこと

ではないかと考えています。