良い手本になろう - PART1

悪夢・・・

以前に誰かが作ったプログラムを自分が引き継がなければならない時があるでしょう。そんなプログラムがぐちゃぐちゃのスパゲティコードだったらどうでしょう。

たとえば引き継いだプログラムに新機能を付け加えるのがあなたの仕事だったとしましょう。まず手始めに、受け取ったプログラムを解読しなければなりませんが、この作業に必要以上の時間をとられます。で、これからやろうとしている改造のあまりの困難さに愕然としつつも、仕方なく改造に着手します。そのやり方は、まるで「実験」です。どうやったら確実に新機能を実装できるかなんてわかりません。まして、何日以内に作業を終えられるかなど見当もつかないでしょう。いい加減にいじってみて、試しに動かしてみて、それなりに動いたらそれでよしというような、最悪の方法に頼らざるを得ません。

繰り返される悪夢

では、時間がたっぷりあったらどうでしょう。プログラムをきれいに書き直して、今後の改造に備えようと思うでしょうか？いいえ、そうは思わないでしょう。そんなことをしてもボスはほめてくれませんし（よけいなコストが発生しますからね！）、「どうせ自分もそのうち誰かに引き継ぐんだから、それまでの我慢さ」と考える方が気が楽です。そもそも自分のせいでもないのにどうして責任をとる必要があるというでしょう！？

このようにして、見通しの悪いプログラムはずっとそのままになります。いや、むしろますます見通しが悪くなっていくのかもしれません（見通しが悪いものについてのことなので、実際のところは良く分かりませんが）。そしてほとんどの場合、コーディングがぐちゃぐちゃなのは、設計がぐちゃぐちゃか、または設計そのものが行われていないからです。設計がしっかりしていれば、たとえプログラムの一部分にできの悪いところがあっても、全体の見通しまでは失われません。つまり、ひとたび悪い設計をすると、それがいつまでも引き継がれていくということです。