デザインパターン:「テンプレート」に思考を縛られるな
皆さん、こんにちは。
昨日のトレードオフ・マインドセットについての投稿に、たくさんのポジティブなフィードバックをいただきました。今日はそれと密接に関係する話 — 先人たちが用意してくれた「テンプレート」について話したいと思います。
多くの人はそれらをベストプラクティスと呼びます。でも、それらは本当に宣伝されているほど「ベスト」なのでしょうか?
真実はこうです: ITのような創造的な分野で働いているなら、既成のパターンに思考を縛られてはいけません。これは特にデザインパターンに当てはまります。
「賢く見せる」罠
3年ほど前、僕はまだ駆け出しの開発者でした。デザインパターンをほぼ全部暗記していると自慢する友人がいて、こいつヤバいなと思って、それを追いかけ始めました。
『Head First デザインパターン』まで買って、寝る前に読む本にしていました。
その時の僕の基準はシンプルでした:
知っていて使えるパターンが多いほど、「プロ」だ。
卒業制作では、コードを「プロっぽく」見せるためだけに、いろんなパターンを詰め込みました。
でも実務に揉まれて — デッドラインに殴られ、半年前に自分が書いた「賢い」コードをデバッグして — 痛い真実に気づきました:
デザインパターンはビタミンだ。でも過剰摂取すると毒になる。
パターンが「鎖」になるのはいつ?
パターンが悪いと言っているわけではありません。システムをきれいに保ち、デカップリングを改善するなど、ちゃんと役割があります。でも、それらは正しい文脈で適用されたときだけ機能します。
次の3つの質問に答えられないなら、パターンを使ってはいけません:
1. その問題は本当に存在するのか?
鶏小屋を上に乗せるために、別荘の基礎を作っていませんか?
2. チームの規模は?
2人のチームが何十ものパターンを使ってマイクロサービスを構築する? それは設計じゃない — 自作の複雑さです。
3. 未来のために過剰最適化していないか?
あなたは次の5年のために抽象化している…でも、プロダクトは次の3ヶ月生き残れないかもしれません。
シニアの意思決定フレームワーク:Rule of Three
パターンを盲目的に愛したり嫌ったりする代わりに、本当のシニアはシンプルな判断ルールを使います。
1回目:
可能な限りシンプルなコードを書く (KISS)。少し「汚く」ても構わない。
2回目:
似たようなロジックがまた出てきても、すぐに抽象化しないでください。もう一度コピペします。
なぜか? まだ「本当に共通するもの」を知るのに十分な文脈がないからです。
3回目:
ここまで来たらリファクタリングする価値があります。正しい抽象化を引き出すための実例がやっと十分に揃いました。
覚えておいてください:間違った抽象化のコストは、重複したコードよりはるかに高い。
実例
❌ オーバーエンジニアリングなアプローチ:
class ShippingFactory {
static getStrategy(type) {
if (type === 'domestic') return new DomesticShipping();
if (type === 'international') return new InternationalShipping();
throw new Error("Unsupported!");
}
}
const strategy = ShippingFactory.getStrategy('domestic');
const fee = strategy.calculate(10);✅ 実用的な (KISS) アプローチ:
function calculateShippingFee(type, weight) {
const rates = { domestic: 1000, international: 5000 };
return weight * (rates[type] || 0);
}最初のアプローチでは、ロジックの一部を変えるのに5ファイルを触ります。 2つ目では、5秒で終わります。
あなたのアプリが今後2年間1つの国でしか動かないなら、あのFactoryは技術的なゴミでしかありません。
終わりに
デザインパターンはあなたに仕えるために生まれました。あなたはそれらに仕えるために生まれたのではありません。
優れたエンジニアとは、最も多くのパターンを暗記している人ではなく、いつ使わないかを知っている人です。
複雑な構造で賢く見せようとしないでください。複雑な問題をシンプルでメンテしやすい解決策に変えることでスキルを示してください — チームメイトがあなたを呼ばずに理解して修正できるように。
だから今日、自分に問いかけてみてください:あなたは賢く感じるためにパターンを足していますか? それとも本当に存在する問題を解決していますか?
時と場合による。でも短期的な「カッコよさ」を長期的な痛みに変えてはいけません。