『良いコード/悪いコードで学ぶ設計入門』を読んで、API設計の“つらみ”と向き合う

はじめに

新卒2年目でエンジニアをしている初心者です。
業務でPHP(Laravel)やRuby on Railsのバックエンドを触っていますが、まだまだレビューで指摘をいただくことも多く、日々勉強中です。

そんなとき、先輩に「設計の基礎を学ぶなら何を読めばいいですか？」と質問したところ、おすすめされたのが本書『良いコード／悪いコードで学ぶ設計入門（保守しやすい成長し続けるコードの書き方）』でした。
読んでみることで、実際の業務での“つらみ”と重なる部分が多くあり、非常に参考になりました。この記事ではその学びをまとめてみます。

本の概要（全17章）

本書は「悪いコード例」と「良いコード例」を並べながら、なぜ悪いのか・どう直せば良いのかを解説してくれる構成になっています。
章立ては全部で17あり、以下のようなテーマで整理されています。

設計の初歩（命名、変数、メソッド分割）
クラス設計、責務分離、不変の活用
条件分岐、低凝集、コレクション処理の整理
密結合の解消、アンチパターン（マジックナンバーなど）
名前設計、コメントの書き方、メソッド設計、モデリング
リファクタリングの進め方
設計の意義や開発プロセスとの関係、学び方の指針

学びになったポイント

初心者として特に役立つと思ったのは次の3つです。

命名は最大のドキュメント
コメントに頼らず、変数や関数名そのもので意図を伝える。
責務は小さくする
1つの関数やクラスに処理を詰め込みすぎると、テストしづらくレビューでも指摘されやすい。
変更に強い設計を意識する
マジック値を定数化する、enumや値オブジェクトを使う、if分岐の増殖を避ける。

特に印象に残った内容

業務でAPIを作成したとき、処理を1つの関数に詰め込みすぎてネストが深くなり、

Rubocopに「複雑すぎる」と怒られる
レビューで「共通化できないか？」と指摘される

という経験がありました。
修正はするものの、「どうすればレビュー前に自分で気づけるのか？」「メソッドをもっと単純にできないか？」と悩みながら実務をしていました。

本書を読んで、その悩みと共通する記述を見つけました。

例えば第6章「条件分岐の整理」では、

ネストが深いと人間がコードを読む際に把握すべき条件が増え、可読性が下がる。

と書かれています。まさに自分が感じていた「追いにくさ」を言語化してくれていました。

また第5章「低凝集の典型と対処」では、

責務が多い関数はテストが困難になり、修正や追加のたびに広範囲の影響を受けやすい。

と説明されています。これもレビューで指摘を受けた経験と重なりました。

さらに第14章「リファクタリング」では、影響範囲の大きさを避けるための具体的な手法として「小さな責務への分割」「処理の抽出」が紹介されています。

これらを踏まえて、実務で意識すべき改善策は次の通りだと思いました。

ガード節（早期return） でネストを浅くする
役割ごとに分ける（リクエスト検証、ユースケース、ドメイン処理、インフラアクセス）
コントローラやサービスを小さな単位に分割する

これを心がけることで、レビューで指摘される前に自分自身で煩雑なコードを気づけるようになりたいと感じています。

実務メモ：変更に強いコード

もう1つ印象に残ったのは「変更に強いコード」を意識することです。
実際、修正タスクをするときに「ただその場を直す」のではなく、影響範囲や今後の拡張も考えないといけない場面があり、難しいけれど大事だと感じました。

チェックリストとして意識したいのは：

マジック値を無くす（enumや定数を使う）
値オブジェクトにドメインルールを閉じ込める
if分岐を整理して、クラス分けやマッピングで外に出す
不変データを活用して、副作用をコントロールする

小さなところからでも習慣にしていければ、より可読性、変更に強いコードを書けるのではないかと感じています。

まとめ

『良いコード／悪いコードで学ぶ設計入門』を読んで、特に「関数やクラスの責務を小さくすること」が印象に残りました。
業務での経験と重ねて理解できたのは大きな収穫です。

また、「変更に強いコード」の考え方も、修正や仕様追加の際に意識したいポイントだと思いました。

この本は、新人エンジニアで「レビューでよく指摘される」「設計の基準がまだ掴めない」と悩んでいる人におすすめです。
悪い例と良い例が並んでいるので、自分のコードを振り返りながら学べます。

明日からでもできることとしては、

ネストが深くなりそうならガード節で早期リターン
責務を小さな単位に分ける
マジック値を定数化する

といった習慣から始めていきたいと思います。