『良いコード/悪いコードで学ぶ設計入門』を読んで、API設計の“つらみ”と向き合う
はじめに
新卒2年目でエンジニアをしている初心者です。
業務でPHP(Laravel)やRuby on Railsのバックエンドを触っていますが、まだまだレビューで指摘をいただくことも多く、日々勉強中です。
そんなとき、先輩に「設計の基礎を学ぶなら何を読めばいいですか？」と質問したところ、おすすめされたのが本書『良いコード／悪いコードで学ぶ設計入門（保守しやすい成長し続けるコードの書き方）』でした。
読んでみることで、実際の業務での“つらみ”と重なる部分が多くあり、非常に参考になりました。この記事ではその学びをまとめてみます。
本の概要（全17章）
本書は「悪いコード例」と「良いコード例」を並べながら、なぜ悪いのか・どう直せば良いのかを解説してくれる構成になっています。
章立ては全部で17あり、以下のようなテーマで整理されています。
- 設計の初歩（命名、変数、メソッド分割）
- クラス設計、責務分離、不変の活用
- 条件分岐、低凝集、コレクション処理の整理
- 密結合の解消、アンチパターン（マジックナンバーなど）
- 名前設計、コメントの書き方、メソッド設計、モデリング
- リファクタリングの進め方
- 設計の意義や開発プロセスとの関係、学び方の指針
学びになったポイント
初心者として特に役立つと思ったのは次の3つです。
-
命名は最大のドキュメント
コメントに頼らず、変数や関数名そのもので意図を伝える。 -
責務は小さくする
1つの関数やクラスに処理を詰め込みすぎると、テストしづらくレビューでも指摘されやすい。 -
変更に強い設計を意識する
マジック値を定数化する、enumや値オブジェクトを使う、if分岐の増殖を避ける。
特に印象に残った内容
業務でAPIを作成したとき、処理を1つの関数に詰め込みすぎてネストが深くなり、
- Rubocopに「複雑すぎる」と怒られる
- レビューで「共通化できないか？」と指摘される
という経験がありました。
修正はするものの、「どうすればレビュー前に自分で気づけるのか？」「メソッドをもっと単純にできないか？」と悩みながら実務をしていました。
本書を読んで、その悩みと共通する記述を見つけました。
例えば第6章「条件分岐の整理」では、
ネストが深いと人間がコードを読む際に把握すべき条件が増え、可読性が下がる。
と書かれています。まさに自分が感じていた「追いにくさ」を言語化してくれていました。
また第5章「低凝集の典型と対処」では、
責務が多い関数はテストが困難になり、修正や追加のたびに広範囲の影響を受けやすい。
と説明されています。これもレビューで指摘を受けた経験と重なりました。
さらに第14章「リファクタリング」では、影響範囲の大きさを避けるための具体的な手法として「小さな責務への分割」「処理の抽出」が紹介されています。
これらを踏まえて、実務で意識すべき改善策は次の通りだと思いました。
- ガード節（早期return） でネストを浅くする
- 役割ごとに分ける（リクエスト検証、ユースケース、ドメイン処理、インフラアクセス）
- コントローラやサービスを小さな単位に分割する
これを心がけることで、レビューで指摘される前に自分自身で煩雑なコードを気づけるようになりたいと感じています。
実務メモ：変更に強いコード
もう1つ印象に残ったのは「変更に強いコード」を意識することです。
実際、修正タスクをするときに「ただその場を直す」のではなく、影響範囲や今後の拡張も考えないといけない場面があり、難しいけれど大事だと感じました。
チェックリストとして意識したいのは：
- マジック値を無くす（enumや定数を使う）
- 値オブジェクトにドメインルールを閉じ込める
- if分岐を整理して、クラス分けやマッピングで外に出す
- 不変データを活用して、副作用をコントロールする
小さなところからでも習慣にしていければ、より可読性、変更に強いコードを書けるのではないかと感じています。
まとめ
『良いコード／悪いコードで学ぶ設計入門』を読んで、特に「関数やクラスの責務を小さくすること」が印象に残りました。
業務での経験と重ねて理解できたのは大きな収穫です。
また、「変更に強いコード」の考え方も、修正や仕様追加の際に意識したいポイントだと思いました。
この本は、新人エンジニアで「レビューでよく指摘される」「設計の基準がまだ掴めない」と悩んでいる人におすすめです。
悪い例と良い例が並んでいるので、自分のコードを振り返りながら学べます。
明日からでもできることとしては、
- ネストが深くなりそうならガード節で早期リターン
- 責務を小さな単位に分ける
- マジック値を定数化する
といった習慣から始めていきたいと思います。