タイムカプセル

レガシーなシステムの機能改造案件をやりました。

とにかくドキュメントがない。お客さんの説明がわからない（専門用語多すぎ）。フレームワークがあるのだが、どこをどういじれば今回の拡張に対応できるのかさっぱりわからずトライアンドエラーでなんとか動かす。かなり疲れた。

ソースの改定コメントが本体より大きくなり、全部取っ払って変更点を検討して、コメントの間に変更点を入れ込み、そしてその変更点をコメントアウトする。こういうのは悪事に荷担したような気分でいやな感じだ。

とあるパラメータは、また別のパラメータの設定値であり、片方だけをいじるとエラーやコアダンプしてくれればまだマシで、うまくいってるかのごとく静かに立ち上がる。エラーがでても意味不明で、かつ発生個所がわからない。関数xがエラーリターンしたなら「x()がエラーリターン」と言えばいいのに「処理異常終了」としか出さない。しかも「処理異常終了」というメッセージはマクロ定義されており、エラーメッセージ文字列の配列に格納されている。いやがらせか？

しかし、これらのことはすべて当時は良かれと思って行ったであることは想像に難くない。修正履歴がわかったほうがいいだろう（当時でもRCSはあったのだけど）。ソースに文字コードがハードコーディングされてるのは良くないから一括管理しよう（でもエラーが増えて面倒になって、とりあえず「異常終了」として、そのまま）。１つのパラメータ変更が他にも自動で追従したほうがいいだろう（どれがどれに追従するのかは後でまとめる予定は未定）。などなど。

フレームワーク自体を適切にパラメータ設定できればすいすい動くという成功した部分は評価されず、そのパラメータ設定がドキュメントされていない、という失敗の部分だけが、これまでこのシステムに携わった人たちの心に残っただろうし、私もそういう気分でいる。

これから未来のシステムがどうなっていくのかはわからないけど、そういうプログラマから見て「負債」としか思えないコードも、売る人から見れば「時の洗礼を受けたビジネスロジック」である。そう簡単に消えるとは思えない。

そして、今この瞬間、この地上で書かれているピカピカのコード達も、形を変えた「ｎ年殺し」を相当量含んでいることは間違いないし、自分が書いたコードだって他の人から見てどう思われるものか、と思うと、ソフトウェアのライフサイクルについて複雑な想いをいだいてしまう。

自分のソリューションをもって、自分で責任を取れるようになれればいいのだけど、そこまでの力もなく、かと言ってあきらめもできない自分がいかに中途半端かを教えてくれました。