1. イントロダクション：僕が「設計のモヤモヤ」から解放された理由
エンジニアなら誰もが経験する悩み。それは「機能は動く。でも、自分の書いたコードがなぜか汚い」「先輩のコードレビューで、いつも**『設計』に関する同じ指摘**を受ける」というモヤモヤではないでしょうか。
僕も以前は、コードを動かすことに精一杯で、設計原則（SOLIDなど）は知っていても「どう使えばいいのか？」が全く分かりませんでした。
そんな僕の**「設計迷子」を完全に解消してくれたのが、この『良いコード／悪いコードで学ぶ設計入門』**です。
この記事では、この本がなぜ「設計入門はこれ一冊でOK」と言い切れるのか、そして僕自身のコードと設計思想がどう変わったのかを、具体的な変化とともにレビューします。
2. 本書の衝撃：悪いコードの「原因」が分かった瞬間
2.1. 「あるある」な悪いコードが心に刺さる
この本が他の設計本と決定的に違うのは、抽象論から入らないことです。
- 読前の僕: 巨大クラスや引数が多いメソッドを見て、「汚いな」と感じるだけでした。
- 読後の僕: 本書で、それらの**「悪いコード」が生まれる原因**が、具体的な設計判断ミスにあると知りました。現場で遭遇するコードをそのまま例に使っているため、「これ、僕が昨日書いたコードだ！」と毎回ドキッとさせられました。
この**「共感」と「危機感」**が、理論を頭で理解するだけでなく、体で設計を学ぶきっかけになりました。
2.2. 設計原則が「現場の道具」に変わった
単一責任の原則やDRY原則といった設計原則は、インターネットで検索すれば出てきます。しかし、この本を読むまで、僕はそれらを**「お題目」**のように捉えていました。
- 「良い命名とは何か？」
- 「責務を分離するために、どこに線を引くべきか？」
本書は、これらの疑問に対し、リファクタリングのコードBefore/Afterを示しながら、原則を適用する具体的な判断基準を教えてくれます。僕にとって、設計原則が**「守るべきルール」から「問題を解決するための道具」**へと変わった瞬間でした。
3. 本を読んでからの僕の3つの具体的な変化
この本がきっかけで、僕のコードレビュー、リファクタリング、そして日々のコーディングスタイルは劇的に変わりました。
3.1. 変化1：メソッドの引数が激減した
以前は、メソッドに4つ、5つと引数を渡していました。しかし、本書で**「引数が多いことの危険性」と「引数を減らすためのオブジェクト化」**を学びました。
- Before: 引数をオブジェクトでまとめず、メソッドのシグネチャが非常に長かった。
- After: 関連する引数を値オブジェクトやDTOとしてまとめ、メソッドの責務をシンプルにする習慣が身につきました。
3.2. 変化2：コメントを書く手が止まった
本書で繰り返し強調されるのが**「コメントはコードの意図を伝えられていないサイン」**という哲学です。
- Before: 「なぜこの処理が必要か」をコメントで補おうとしていた。
- After: 「このコメントなしで意図が伝わるか？」を自問し、伝わらなければ変数名、メソッド名、クラス名を改善するように徹底しました。結果、コードはクリーンになり、レビュー依頼の時間も短縮されました。
3.3. 変化3：コードレビューが怖くなくなった
以前は、レビューで設計を指摘されるのが怖かったですが、今は逆です。
設計に関する共通言語（責務、結合度、凝集度など）を本書で得たことで、レビューアの意図が明確に理解できるようになりました。また、自分から積極的に**「ここは拡張性を考えてあえて低結合にしました」**と説明できるようになり、建設的な議論ができるようになりました。
4. この本はこんなエンジニアに読んでほしい
僕自身の経験から、特に以下のような方に、本書を強くお薦めします。
- 実務経験1年～3年目の若手: 「動くけど汚いコード」を卒業し、「育つコード」の書き方を学びたい方。
- コーディング歴が長いベテラン：長年の習慣で身についた**「悪い癖」**を客観的に見直し、最新の設計思想にアップデートしたい方。
- チーム開発のリーダー: チーム内で「良い設計」の共通認識を作り、コードの品質を統一したい方。
5. まとめ：設計力を磨き、市場価値を高めよう
『良いコード／悪いコードで学ぶ設計入門』は、プログラミングスキルを**「動かす」フェーズから「育てて、長く愛されるシステムにする」**フェーズへと引き上げてくれる一冊です。
設計力は、エンジニアの市場価値そのものです。ぜひこの本を手に取り、僕のようにコードを変え、エンジニアとしての自信を手に入れてください。
コメント