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

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

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

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

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

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

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

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

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

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

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

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

あけましておめでとうございます。本年もよろしくお願いします。

年末にこのブログでも書きましたが、やはり本業を持ちながらソフトを創作するのは、時間の面でなかなか大変です。といっても、OuDiaは全く放棄というわけではなく、現在OuDiaのリファクタリングに注力しています。

リファクタリングというのは、ソフトウエアの見た目・動作を変更せずに、内部構造を見直すことです。OuDiaは仕事で作ったソフトではないため、時間に追われて焦って作るような場面はなかったのですが、それでも時間が経ってから見てみると、やはり必ずしも洗練されていない部分が見えてきます。

僕自身、OuDiaに搭載したい機能はありますし、ユーザーの皆様からのご要望にもお応えしたい気持ちはあります。しかし、それより先にまず、自分自身が感じている設計面の問題点をクリアにしておきたいな・・と今は思っています。

実は、仕事でソフトを開発する場面では、リファクタリングという作業を受け入れてもらうことは難しいんですね。というのも、リファクタリングの結果は、ソフトウエアのユーザーに直接目に見えるものではないため、直接の収益にはつながらないからです。だからこそ、せめてそういう縛りとは無縁のOuDiaでは、リファクタリングに思い切りこだわっておきたいですね。