現場で役立つ「設計力」を身につけるための学習法

「動いているのに、直せない」で止まる

機能は完成し、テストも通りました。それなのに一か月後、「この条件を一つ足したい」と言われて、どこを触ればいいのか自分でも分からない。あるいは、一箇所直したら関係ないはずの画面が壊れる。設計を意識せずに書いたコードは、たいていこの形で返ってきます。

設計力とは、格好いい図を描く力ではありません。後から変える人が、どこを触ればいいか分かる状態を保つ力です。そして後から変える人は、多くの場合、数か月後の自分自身です。

名前が読めれば、半分は終わっている

設計の話は抽象的になりがちですが、最初に効くのは変数名と関数名です。

この t が何なのかは、書いた本人にしか分かりません。ミリ秒なのか秒なのか、経過時間なのか残り時間なのかも読み取れません。

名前を変えただけで、動作は一行も変わっていません。それでも、次に読む人がコメントを探す必要はなくなりました。設計の練習は、この粒度から始められます。関数についても同じで、名前を付けようとして「〜して、〜して、〜する関数」としか言えないなら、それは分割の合図です。

原則は覚えるものではなく、見返すときの問い

DRY や SOLID といった設計原則は、覚えて適用するものというより、書き終えたコードを見返すときの問いとして使うと効きます。「同じ判断を三箇所に書いていないか」「このクラスは何が変わったときに直すことになるか」と自分に聞く。これだけで、原則を暗記しなくても効果は出ます。

注意したいのは、原則同士がぶつかることです。重複を消そうとして共通化を進めると、無関係な二つの処理が一つの関数に同居して、片方の都合で直すともう片方が壊れます。重複しているように見えても、変わる理由が違うなら分けたままにしておくほうが安全です。原則に正解を求めず、どちらの痛みを引き受けるかを選ぶ、という感覚を持ってください。

解説

覚え方 — 迷ったら「これは同じ理由で一緒に変わるか」と聞いてみてください。一緒に変わるなら寄せる、別々に変わるなら分ける。

一人でも、勘所は育てられる

チームのレビューが受けられない環境でも、設計の練習はできます。手数の多い順に二つあります。

一つは、過去の自分のコードを書き直すことです。ただし、書き直す前に必ずテストを用意します。テストが無い状態でのリファクタリングは、動くコードを壊す作業になりかねません。テストがあれば、構造を大きく変えても壊れていないことをその場で確かめられるので、思い切った実験ができます。

もう一つは、選んだ理由を短く残すことです。「認証をライブラリに任せた。自前実装は仕様追従の手間が大きいと判断した」程度の数行で構いません。半年後に読み返すと、当時の制約と今の制約が変わっていることに気づけます。設計力とは、選ぶ力であると同時に、選んだ理由を説明できる力でもあります。

今日書くコードの変数名を一つ考え直すところから始めてください。その積み重ねが、大きなシステムを支える設計力になっていきます。