ホームページ目次前の話次の話

プログラム集中治療室で行う緊急処置(2)概要把握

2008年3月21日

前回、見積りについて書いたが、集中治療が必要なプログラムの場合、 正確どころか、いい加減な見積りも不可能な場合が一般的である。 それでも、スタートせざるを得ない不幸にぶつかることがある。

とりあえず行うことは、全てを天にまかせ、ソースプログラムを見ることとしよう。 ドキュメントが幸運にも存在する場合があるが、あてにしない方がよい。 ドキュメントを見て、書かれているように動作しているなら、 救急治療室に運び込まれることもないだろう。

まず、最初は、修正するのではなく、どんな感じでプログラムが書かれているか 全体を眺めることから始める。 詳しくはプログラミング言語によってやり方は違うのだが、 全体を把握して(実際には把握などできやしないのだが)、 どういう戦略で取り組めば、なんとかなるかもしれない道筋をおぼろげながら考える。

最初の時点で重要なのは、分量である。分量が多く、たとえば10万行以上あって、 それで意識不明の重体ソフトだったりすることがある。

もっと困るのは、プログラムとしては結構まともに動作しているのに、 ソースプログラムを見たら卒倒しそうになる場合があり、こういう場合の方が大変だ。

いずれにしろ、プログラムの修正は、すこし落ち着いてから行なった方がよい。 それより、どんな風に開発していたのか、そのあたりを探っておいたほうが良い。 オブジェクト指向言語、たとえばJavaだからオブジェクト指向的に 書かれているなんてことは夢にも思ってはならない。

何がとんでもない原因かを突き止めることができれば、かなりな成果といえる。 よくあるのが、コピーしては一部変更して延々と作ってしまい、 何か修正しようとすると、修正個所がやたらに多くなりそうなソフトがある。

ゴミが大量に残っているままのソフトウェアがある。 動かないプログラムが、そのままソースとして残されていて、 何割ものゴミに埋もれているソフトがある。

また、今までの修正が、コメントとして延々とソースプログラム中に入っていることがある。 修正記録がコメントとしてプログラム中に入っているのが正しい方法と信じている 開発者が未だに絶滅しないが、これはプログラムを読み難くするだけで、何のメリットもない。 ソースプログラムを管理したいのなら、ちゃんと履歴管理ソフトを使おう。 それに、コメントは人間が書くもので、ウソが入っていることが多く、信用してはならない。

巨大クラス、長大なメソッド、関数などがあるときは要注意だ。 こういうものに手を入れなければならない場合は、非常に神経を使う。 それぞれの部分が独立になっていなくて、どこかをちょっとでも変更すると、 もう全体が動かなくなることがよくある。 Never Ending 何とか が出て来たら、ほぼ非常事態と思って間違いない。 世間には、数千行に及ぶ、クラス、メソッド、関数などを作り、 なおかつ何とか動くようにする強者がいる。

こういう調査を行なうと、プログラムを変更しなくても、次第に全貌がかすかに見えてくる。 そして、全貌がかすかに分ったところで、もう一度、捨てるべきか、何とか救急治療を行なうか、 考えるべきである。判断は、ソースプログラムだけで判断するのが良いのだが、 実際には、そのソフトの価値、存在価値とかも考えて行なわれるものだ。

私が今まで手をつけた救命処置は、ソースプログラムだけで判断するなら、 いずれも捨てて作り直しすべきものであった。 無茶苦茶なプログラムは、いくら手を入れても、できることは延命処置に過ぎない。 延命処置には限界があり、延々と延命を行なうのは、ゼロから再開発するよりコスト高になる。 そのため、どの程度までなら手を入れて良いかを判断する。

要するに、プログラムを眺めて、救命手術のプランを立てるのである。 もちろん、この救命手術は作業時間に比例して着々と進むことは珍しい。 まだまだ思いがけないことが起きる可能性がある。

捨てますか、直しますか、直すならどのあたりまでやりますかという判断と、決心、決意が必要だ。 手をつけると、もう後へ引くのは困難なことが多いので、慎重になろう。

そして、しっかり理解しておかなければいけないのは、 「何とかしてください」と言って持ちこんだ者は、 プログラムの救急治療の大変さを理解する筈がないことである。 大変さが分るくらいだったら、そうなる前に手を打っているに決まっているのである。

インターンシップ体験記


ホームページ目次前の話次の話