なぜ、ひとつのファイルは膨れ上がるのか
最初は小さなファイルだった。
新しいサービスを作るとき、画面のひとつくらいなら数十行で済む。ボタンを置き、表示を切り替え、データを受け取る。それだけなら、誰でも読める短いプログラムだ。
ところが、サービスが育つと話が変わってくる。あの機能を足したい、この演出も入れたい。要望はいつも「ついで」の顔をしてやってくる。すでにそこにあるファイルに、もう一行、もう一機能。そうやって少しずつ書き足していくのが、いちばん手っ取り早いからだ。
気づいたときには、ひとつのファイルが3275行になっていた。
これは特別だらしない話ではない。むしろ逆で、そのファイルがサービスの中心だったから、みんなが触り、機能が集まり、結果として膨らんだ。肥大化は、放置の証であると同時に、よく使われてきたことの証でもある。
大きくなったものは、身動きが取れなくなる
問題は、大きくなりすぎると動かせなくなることだ。
そのファイルの中には、その場の状態を覚えておくための変数のようなものが87個あった。外部からの通知を受け取る口も22箇所。どこか一行を直すと、思いもよらない別の場所に影響が及ぶ。全体を頭に入れていないと安全に触れない。けれど3275行を一度に頭に入れられる人など、そういない。
こうなると、誰も手を出したがらなくなる。怖いから、見て見ぬふりをする。そして「ついで」の書き足しだけが続き、ファイルはさらに重くなる。大きくなったものは、その大きさ自体が次の変更を妨げるのだ。
しかも、これは本番で動いているサービスの中核だった。止めて、ゆっくり作り直す、というわけにはいかない。お客さんは今日も使っている。
一気にやらない、という決断
作り直すと聞くと、勇気の話に思えるかもしれない。古いものを思いきって捨てて、新しく書き直す。けれど現実に効いたのは、勇気ではなく段取りだった。
一気に全部を書き換えるのが、いちばん危ない。新旧の差が大きすぎて、何かが壊れたときにどこが原因か分からなくなる。だから、やらなかった。
代わりに、小さく切り分けた。87個の状態のうち、まずひとつのまとまりを別の場所へ移す。動くことを確認する。次のまとまりを移す。また確認する。その繰り返しだ。一回ごとの変更は小さく、もし問題が出てもすぐ戻せる。本番を止めずに済んだのは、この刻みの細かさのおかげだった。
派手さはない。けれど、動いているものを壊さないというのは、つまりそういう地味な積み重ねのことなのだと思う。
3275行が、32行になった
結果を数字で並べてみる。
中核のファイルは、3275行から32行になった。状態を覚える変数は87個から6個へ。外部からの通知を受け取る口は、22箇所からゼロになった。
消えた行が、どこかへ消滅したわけではない。役割ごとに小さな部品へと分けられ、それぞれが自分の責任だけを持つようになった。中心にあったファイルは、もう何でも抱え込む置き場所ではなく、ただ全体をまとめる32行の入り口になった。
数字のインパクトは大きいが、本当に変わったのは読みやすさだ。32行なら、初めて見る人でも一目で見渡せる。次に手を入れる人が、怖がらずに触れる。
肥大化は罪ではない、放置が罪だ
この話の教訓は、ふたつある。
ひとつ。ファイルが膨らむこと自体は、悪ではない。それはよく使われ、育ってきたことの裏返しでもある。最初から完璧な設計を求めて手が止まるより、まず動くものを作って育てるほうが、たいていは正しい。
もうひとつ。ただし、膨らんだまま放置すると、いつか身動きが取れなくなる。そして作り直しに必要なのは、思いきりのよさよりも、小さく刻んで一歩ずつ確かめる段取りのほうだ。
大きくなったものと向き合うとき、私たちはつい「一気に片づけたい」と思う。けれど、動いているものを壊さない唯一の方法は、たぶん、急がないことなのだ。
Boundary LAB は「境界を越える体験を設計する」会社です。自社ホスティングのメタバース rezona を運営しています。空間づくりのご相談は X（@shuuuuuuvuu）の DM へ。私たちについては Boundary LAB について もどうぞ。