📚

2年目エンジニアのためのコード設計！名著3冊を徹底比較！

2024/01/04に公開

実務にも慣れてきた2年目エンジニアのあなた、以下のようなことで悩んでいませんか？？

先輩たちのようにキレイな良いコードが書けない
チーム開発を初めてレビューで可読性について指摘された
実装でどこに処理を書いて良いかわからなくなった
先輩たちのコードの意図が読めない(なぜこんな設計にするのかわからない)

そんな悩みを解消するべく、コードの設計に関する名著を3冊読んだので、そのレビュー・比較をしていきたいと思います。
それぞれの書籍のポイントや違いについて理解し、書籍を購入する際の手助けになれば幸いです。
では、早速、私の読んだ順で紹介していきたいと思います。

「リーダブルコード」のレビュー

リーダブルコードの概要 (主なテーマ、どのような視点から設計が語られているか)

「リーダブルコード」の名の通り 「可読性」 を重視している
「他人や未来の自分が読んだ時に理解しやすいコードになっているか？」の観点から良いコードについて書かれている
良いコードを書く上での細かなTipsも豊富に書かれている
- ex) コメントはhowではなくwhyをかく
  - howはコードが示してくれるからコメントにはコードからは読み取れないwhyの部分を記述した方が良い
- ex) コードの意図をコメントする際は概念的に高レベルのものにする
  - ❌ 配列をpriceカラムで降順に並べる
  - ⭕️ 商品のリストを高い順に並べる

リーダブルコードからどんなことが学べたか？

「良いコードとは何か？」に関して、ざっくりと理解できる
「良いコード」 = 「美しいコード」かつ「テストしやすいコード」
コードを書く時は読み手の視点に立つ
- 変数やメソッドの命名で、自分がつけようとしている名前は初めてコードを読んだ人にも何の責任を持つものかをイメージできるか？

リーダブルコードはこんな方にはオススメ

まずは「良いコードがどんなものかを知りたい」という方にはうってつけ
コード書き始めの初学者
- 内容も複雑でなく、非常に読みやすい

「プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則」のレビュー

プリンシプルオブプログラミングの概要（主なテーマ、どのような視点から設計が語られているか）

リーダブルコードと同じで 「可読性」 の観点を重視して書かれている印象
一番の特徴は「内容が抽象的」であること
- コードも一切出てこないので、「良いコードとはなにか」をざっくりでも理解しており、コードを書いた経験がある方に向けた書籍だなという印象
- 初学者がいきなり読むと、何のことをさしていっているかの理解が難しそう
KISSやDRYなどのプログラミングの原理原則から、思想、心構えなどを中心に書かれている
リーダブルコードより複雑かつ抽象的で、広範囲(コードの設計以外にも書かれている)
1~4章はリーダブルコードとほぼ同じ内容

プリンシプルオブプログラミングからどんなことが学べたか？

コードの設計だけではなく、プログラマとしての姿勢や考え方についても学べた
プロジェクトの進め方やアンチパターンについても学べた
- ex) 即行プロトタイプ (MVP的な考え)
  - なるべく早くプロトタイプを開発しプロジェクトに見せた方が良い。そうすることで手戻りが減らせる
個人的によかった第7章の「セカンドシステム症候群」を要約して紹介

個人的によかった第7章の「セカンドシステム症候群」** を要約して紹介

この節の最重要メッセージは「機能追加は最小限に抑えてシンプルを保て」
ファーストリリース後のフェーズ2では、多機能主義に陥りがち
機能を増やす = コードの保守性, ユーザーの使い勝手の悪化
開発リソースには限りがあるので、ユーザーの価値に貢献するものを選定することが大事
- ❌ ユーザーからの要望を鵜呑みにする
- ❌ 闇雲な機能追加
- 意外とユーザーは新機能よりも「基本機能の安定」や「基本機能の使い勝手の向上」を望んでいるケースもある
- どうしても機能追加を避けられない場合は、拡張機能やプラグインとしてプロダクトのコア(コードも含め)を変更せずに対応することも一つの手

プリンシプルオブプログラミングはこんな方にはオススメ

ざっくりと「良いコードとは？」を理解しているが、「なぜ良いのか？」が理解できていない方
- コードはもちろん、考え方などが学べるので、タイトルにもあるように「3年目までに」読んでおくのが良いなと感じた
- 「なんとなくこのやり方が良いらしい」から一歩進んで「この原則に乗っとているからこういうメリットがあって良い」までの理解のスピードが早くなると思う

「良いコード / 悪いコードで学ぶ設計入門」のレビュー

こちらの書籍は「ミノ駆動本」の愛称で親しまれているので、以後、「ミノ駆動本」として紹介させていただきますmm

ミノ駆動本の概要（主なテーマ、どのような視点から設計が語られているか）

特に 「変更容易性」 を一番重要なポイントとして書かれている
実際のプロジェクトでありがちなシチュエーション(仕様変更や後任のエンジニア目線、テストが書かれていない現場など)を想定しているので、一番現場に寄り添っている印象
アンチパターンを見せてから、ベストプラクティスを見せる流れなので、どのような時にその設計パターンを利用するかをイメージしやすい
読んだ後に会社のつよつよ先輩の書いたコード読んだら、こういう設計パターンが使われているんだ〜ってわかるからおすすめ

ミノ駆動本からどんなことが学べたか？

各種設計パターン
- 値オブジェクト ( + 完全コンストラクタ )
- ストラテジパターン
- ポリシーパターン
- ファーストクラスコレクション
- コンポジション構造
設計に関する考え方
- 「どんな課題があるか」「ある手法がその課題解決に効果的か」「コスト的に問題にならないか」を評価して判断する姿勢
- 課題と目的を意識して技術選択できる必要がある。
- 『設計にベストはない。常にベターを目指すことが大切』

ミノ駆動本はこんな方にはオススメ

条件分岐のある実装をする際に、躊躇なくif文やswitch文を使う方
- 書籍の中で「interfaceを使えるか使えないかが設計スキルの分かれ目」と書かれていました！
上で紹介している設計パターンについて理解していない方
設計についての考え方はざっくり理解しているが、具体的な実装まで落とすのが苦手な方
実務で設計が原因で開発しにくいなどの悩みがある方

3冊の比較

共通して強調しているポイント

「シンプルさ」が一番大事
- 色々な原則があるが、その根底にあるのは「単一責任の原則」
- DRY、KISS、OCPなどのその他の原則の多くは「単一責任の原則」を守るためにはこの原則を守るためのもの(と、解釈している)
パフォーマンス <<< 可読性
- パフォーマンスと可読性はトレードオフ
- 開発はチームで行うかつ、追加の機能開発などで長期間にわたって行うので、ほとんどのケースでは可読性の方を優先した方が良い

読みやすさ、理解しやすさなど、形式的な比較

それぞれの書籍の特徴をざっくり表にすると以下になります。

	テーマ	具体 or 抽象	難易度
リーダブルコード	可読性	具体的	簡単
プリンシプルオブプログラミング	可読性	抽象的	難しい
ミノ駆動本	変更容易性	具体的	普通

読んだ方が良い順番

これら3つの書籍を読んでみて、読んだ順番も良かったと感じたので、そのメリットも含めて紹介します。

リーダブルコード
- 内容が具体的
- 一番簡単に書かれているので「良いコードとは？」を理解しやすい
プリンシプルオブプログラミング
- 内容が抽象的なので、リーダブルコードでざっくり全体像を理解した上で読むとスって入る
ミノ駆動本
- 具体的な設計パターンを書いているので、抽象を具体に落とす作業になり、より理解が深まる

こちらの順番だと、具体を抽象を繰り返すことで理解が深まり定着しやすくなるのでオススメです！

まとめ

それぞれの書籍でレベル感、抽象度、観点などは違えど、本質的には同じことを述べていて、「コードはシンプルに書こう」ということが根本的な考えになっています。

チーム開発をスタートしたばかりの初学者や、新卒で入社したばかりのエンジニアが読むにはどの本もタメになるのではないでしょうか？

本記事が読者の書籍選びの参考になれば幸いです。

個人的な話になりますが、これからはより具体的なデザインパターンなどを学び、実装の引き出しを増やしていき、プロジェクトに応じて使い分けできるようになることを目標にしたいと思います。