この間、ダイナミックなリファクタリングをコアなロジックに施術した。
正直このレベルの変更をするのはチームでも難しいと言われてて、かつ重要なロジックなので変更が難しかったのだが、今回思い切ってやってしまった。
そういった壊して作り直すことを考えてたら浮かんできた記事。
"ソフト"ウェアに寿命があるとするなら、その命が尽きるのは変更が無理になってしまったときなのだと思う。
幸運にも生き残ってしまったソフトウェアは、絶え間ない機能追加と仕様変更の波に晒されることになる。初期の頃上手く言ってた設計も日が経つに連れて、限界を迎えてしまう。
ソフトウェアの死は事業の死にも直結する。何も遊びの変化の無いゲームを遊び続けてくれるユーザーは居ないだろう。
とはいえリファクタリングは無尽蔵に出来るものでは無い。私はリファクタリングの成功には経済的合理性が必要だと思ってる。ただの自己満足なのか、それとも事業をより前に進めるための必要経費なのか。
前者は完璧主義なソフトウェアエンジニアが陥ってしまう(私も例外ではないが)罠で、そのリスクはよく知られているはず。より良いものは作りたいが、何から何まで完璧にすることなんてのは諦めたほうが良い。
ただ、後者が必要なタイミングというのは往々にしてやってくる。今回は明らかにそのタイミングだった。
巨大に膨れ上がったトランザクションスクリプトの一挙一動を知ってるのは最早限られた人しかおらず、何もかも読みにくい、この上に更に新規機能を加えるなんてのは流石に出来ないと。
複雑に絡み合ったロジックを紐解いて分かりやすく再構築するのはやっぱ並大抵な難易度じゃない。もっの凄いエネルギーを使う。紐解いて再構築するの大好きなので楽しかったけど。
こうやってソフトウェアを作り変えることをやってると、去年観たレヴュースタァライトという映画を思い出した。あれは舞台のお話だけど、ソフトウェアも似たようなものかもしれない。囚われ変わらないものは、やがて朽ち果て死んでゆく。アタシ再生産。
かつての私はこんな攻撃的なコードは書かなかったなと思う。もっと保守的に書いてた。既存の思想に従った、影響範囲が出来るだけ狭くなるような、そういった改修を自然と選択してた。その選択も間違ってはいないが(実際自分の改修はバグが少なかった)、逆に負債を溜めてしまう結果にも繋がっていた。
0と1で判断出来るようなことじゃなくて、グラーデーションのある事柄なので、何が正しいなんて言えない。けど、変化することを恐れたくないという祈りなのだと思う。
22/06/24 一部添削
