スタッフBLOG

おはようございます。本日の当番、プログラマーの大川です。

今回は「パッチ処理」について考えてみようかと思います。
プログラマーの方にとっては、あまり聞きたくない言葉では、と思います（汗）

さて、一般的にパッチ処理とは、バグ修正や機能変更を実装する行為を言います。
当然、パッチ無しで動けば無問題（天才！）なのですが、現実的にはそうはいきません。
プログラミング作業の何処かしらで、必ずパッチ処理は必要になってきます。

パッチ処理の手法も色々あると思いますが、「部分的な修正のみを行う」か、「一切合切ソースを組み直して丁寧に修正するか」のどちらか、だと思います。

私の場合、時期にも依りますが、基本的には後者を採っています。
修正に時間が掛かったとしても、他に簡単に直せる方法があるとしても、あえて後者です。

何でそんな面倒な事をするのかと言いますと…、

基本的にパッチ処理というのは、増えれば増えるほどソースの構成が乱れてしまいます。
修正当初は「ここだけ汚くてもいいか～」と思っていても、更に修正～またまた修正、という工程が増えれば、メンテナンスも放棄したくなる事態となります。

処理の見通しが悪くなると、更なるバグを併発する可能性も出てくる訳で、そうなると管理する情報量が増える分、作業効率も散漫になってしまいます。

それを回避するため、ソースの全体構成を見直し、再構築することにしています。
ですが、いちいちそんな事をしていたら、時間だけを浪費する事になりますし、組み直しの過程によるバグ発生の可能性も無視出来ません。実際、余計に酷くなったこともあります。

でも、敢えて後者です。

何故かというと、プロジェクトの後半に備えた、ある程度の「余裕」を持たせる必要があるからです。
ここでいう「余裕」とは、ある程度のバグ修正を繰り返すことが出来る「管理的な余裕」を言います。

これまでの経験上、プロジェクト末期になると、パッチ処理（前者）が大量に発生します。
「ここは安全でしょ！」と思っている箇所にまで及ぶ事もありました。

ですので、そんな事態に備え、プロジェクト中期までは後者、末期では前者、という感じにしています。
プロジェクト中期までは面倒な事は多いですが、最終的に「助かった～！」と思う局面も多々ありました。

是非、ご参考に！

…、

書いてて、ふと思いました。

「パッチ処理の必要が無いプログラムが書ければなぁ～」と。

否！なかなか無理です（汗）
というか、おそらく一生無理なんじゃないかしら（泣）