Line Buffer Overflow…

書くことが多過ぎるとき、バッファーとしてこちらに書きます。不定期更新です。

デグレ…

この記事の、続き。 
kiha-gojusan-hyakusan.hatenablog.jp

 

若い子の「5,6年前に戻りたいっ!」にかこつけて、プログラムのお話。

 

まぁ、5,6年まで戻るのは稀としても、プログラムの性能が下がってしまうこと、前のバージョン以下に戻ってしまうことを、「デグレード」、略して「デグレ」と言います。

 

プログラムをリリースしても、そのまま使い続けられるのは、稀だと思います。

改造や修正、不具合対処など、様々な処置を施すことになります。

 

この時、付けた機能や修正が、整合性の問題から、思いも寄らぬ機能に支障したり、時には過去に適用したパッチが無効になって、直した不具合が復活してしまうことも、現実としてあるんです。

 

かなり厄介な不具合と言えます。

専門の評価工程が、あるぐらいですから。

僕も、従事したことがあります。

デグレ評価」なんて言いました。

 

世間の評価は「出来て当たり前」

「一度、やってるでしょ?」ですから。

でも、分業制でできたプログラムに、後付けの修正パッチ。

管理は至難の業だし、そもそも最初のリリース時とは、環境が変わっているのです。

 

それでも、「デグレ評価」はやらなければならない仕事です。

直せるタイミングで、しっかり直しておかないと、同じ不具合に世間はどんどん厳しくなります。

 

実際のところ、プログラムの不具合は、発見出来るかが勝負。

問題を再現し、その際のデータを取ることが出来れば、強力なプログラマーがあっという間に、問題を修正してくれます。

 

でも、一度出た問題は、常に出るとは限らない。

試験を繰り返し、問題を起こす条件を突き止め、実際に問題を起こしてデータを取る「再現試験」は、プログラムとは全く別の技術です。

 

むしろ、プログラマーには向かない作業かも知れない。

プログラムに思い入れが幾重にもあるプログラマーに、評価業務を正確に行わせるのは、無理があるのかも知れません。

僕も評価業務をやりましたが、そのプログラムに関しては、素人でした。

 

地道な作業と、変化を見逃さない感覚。

なかなか陽は当たらないけれど、プログラム開発には絶対必要な、技術と経験がいる仕事なのですよ。

 

 

さて、前に戻って…

5,6年前に戻るのは、時には大いに結構。

ただ、整合性には、気をつけて戻ってね。

相当、難しいことだと思うけど…。