予想外の成長と食い込み
父と散歩の途中で休憩するいつもの公園で、今日もいつものように休憩していて気付いたのだが、木と柵が大変なことになっていた。
最初からここに木を植えていたのではなく、柵を作った後から勝手に生えてきたのだろう。 小さいうちに雑草と一緒に刈り取られることもなく、すくすく…とはいかなかったかもしれないが成長し、今やもうどうしようもない状態に。
柵の一部は完全に木に取り込まれている。
維管束はだいたい木の皮のすぐ内側くらいにあるのだが、柵を巻き込む形になっているところではどうなっているのだろう。 くっついたところの内部で維管束もくっついてバイパス状態となっているのか。 それとも指で輪を作るようなもので、くっついてはいるけどそこは表皮という扱いで、柵の内側までぐるっと回っているのか。 そこでもうバッサリ途切れているのか。
しかしこんな状態なのに、全体的に見ると他の木と遜色ない元気さってのも凄いよな。
柵が食い込んだ木を、5期の頃の水着を着せられた6期の猫娘に置き換えたりして眺めているうちに、仕事で扱うプログラムにもこんな風になっているのがあったのを思い出した。 きっと作った当初は小さくすっきりしていたのだと思うが、その後に発生した改造に次ぐ改造でコード量は肥大化し、内部構造はアリの巣のように複雑になっているのだ。
改造に次ぐ改造。 だいたいいつも要件確定に当初予定よりも時間がかかり、なのに納期は変わらず、結果としてソースに手を入れる時間が削られる。 そのため、実装コードを綺麗にするために考える時間が取れず、綺麗ではないが誰でもできる機械的な改造を選択してしまう。
例えば、一つの関数の中にいくつも処理を追加するとか。 その処理の各段に同じ条件分岐を追加するとか。 それらの処理のほぼ全体をまた条件分岐で囲み、elseの方は丸ごとコピー→ペーストしてちょっと変えるだけとか。
俺の見た範囲では、PL/SQLが特にこんな感じ。 オブジェクト指向的な手法が取り辛いから、こうした傾向になるのも仕方ないのかな。 と思ったのだが、考えてみれば、別にオブジェクト指向を言語レベルでサポートしていなくても、もう少し綺麗に書けるはずなんだよな。 それに、言語機能としてほとんどアピールされていないが、PL/SQLでも一応オブジェクトは作れるし、継承だってできたはず。
せっかくだからちょっと試してみようと思ったのだが、眠くなってきたので続きは明日。