理にかなった設計が、いつのまにか悪い設計になっていた話

当時の設計段階では合理的だったアプローチが、環境の変化とともに陳腐化する。その変化に気づくには解像度を上げる必要があり、対策は銀の弾丸に近いものだった。

気づいたら悪者になっていた

半年前の自分が書いたコードを見て「なんでこんな設計にしたんだ」と思った。よく見ると当時の仕様書には「拡張性より速度優先」と書いてある。そのときの状況では正しかった。

でも半年たって、ユーザー数が増え、機能が追加され、あちこちに分岐が増えた。あのときの「速度優先」の判断が、いまは変更のたびに足を引っ張る存在になっている。悪い設計になったのは、設計そのもののせいじゃない。設計と環境のあいだにズレができたからだ。

設計は「そのときの状況」とセットで初めて正しさが成り立つ。状況が変われば正しさも変わる。コードを書いたときの前提条件を忘れると、過去の自分を責めるだけで終わってしまう。

悪くなったことに気づけなかったのは、環境の変化をぼんやりとしか見ていなかったからだ。ユーザー数が「なんか増えてきたな」程度の認識では足りない。具体的な数字と傾向を見ないと、設計が限界を迎えていることには気づけない。

「最近なんかきつくなってきた」という感覚は、すでに手遅れに近いサインだ。その「なんか」を分解して、何がどう変わったのかを具体化しないと、対策がずれる。

対策はとてもシンプルだった。

自動テストだ。

設計が環境に追いついていないかどうかは、自動テストを走らせてみればすぐにわかる。テストが通らなくなったり、テストを書くために不自然なモックが必要になったとき、それは設計が現実からズレはじめているサインだ。テストは、設計と環境のあいだに立つ翻訳者のような役割をしてくれる。

ただし、自動テストは書いて終わりじゃない。環境が変わるたびにテストも変わる。メンテナンスを続けないと、すぐに嘘をつくようになる。書いたあともずっと付き合っていく。その意味で、まさに「長く付き合っていかないといけない」ものだ。

銀の弾丸と呼ぶには地味すぎるかもしれない。でも、設計の陳腐化にいちばん早く気づかせてくれる仕組みは、いまのところこれしか見つかっていない。

半年前に書いたコードをひとつ開いて、いまもテストが素直に通るか確かめてみてほしい。そこで感じる違和感が、設計を見直すタイミングを教えてくれる。