プロフェッショナルなエンジニアが常に意識している重要な概念が紹介されています。経験が3年以内のエンジニアに特におすすめの一冊です。経験豊富なエンジニアの場合、他のエンジニアへのメンタリングに役立ちそうです。私の師匠は「今まで理解していたけど言語化するとこうなるよなあ」と言ってました。実際本書の中の表現をPRのレビュでもらっていたことを本を読んで知りました。言語化大切です。また、説明もかなり丁寧で、疑似コードをベースに詳しく説明してくれるのでかなり腹落ちしやすいです。

私はインフラメインでキャリアを積んできたので、プログラマーとしては3年以内のエンジニアになります。知らない内容も多く非常に勉強になる一冊でした。目次は以下の通りです。Part1に理論編とありますが、Part2以降も綺麗に考え方や理論を言語化してあります。そのため、どのような背景があり何故そのように書くと信頼性の高いコードを書けるのかなどを深く理解することができます。

- Part 1  理論編
  - Chapter 1  コードの品質
  - Chapter 2  抽象化レイヤー
  - Chapter 3  コードでの契約
  - Chapter 4  エラー
- Part 2  実践編
  - Chapter 5  コードを読みやすくする
  - Chapter 6  想定外の事態をなくす
  - Chapter 7  誤用しにくいコードを書く
  - Chapter 8  コードをモジュール化する
  - Chapter 9  コードを再利用、汎用化しやすくする
- Part 3  ユニットテスト編
  - Chapter 10 ユニットテストの原則
  - Chapter 11 ユニットテストの実践

読んでいく中で既存のプロダクトコードの中で既に利用されているプラクティスを色々理解できたので本当に勉強になりました。仕組みとして理解せずに従っていたものもありました。今回理解を深められて大変良かったです。いくつか内容を紹介してみたいと思います。

Dependency Injection (DI)

Chapter 8のDIの説明が大変勉強になりました。DIの仕組み自体を他のコードを真似て利用したりはしていたのですがその背景や目的についての理解は浅かったです。正直めちゃくちゃ感動しました。

DIにより依存を減らし、より堅牢なモジュールを作る。またそれによりテストもしやすくなる。素晴らしい。

またインターフェースの使い所を正直理解しきれていないところがあったのですが、DIでの用途を疑似コードと一緒に読みながら完全に理解しました（？）。

他にも特定クラスの中でファクトリのロジックも持つとモジュール性が失われていくので、インスタンス作成時のファクトリーを作っておくのが重要など実践的な内容も多く紹介されていました。

テストのフィラソフィー

ユニットテストについても基本的な考え方が記載されています。私が良いなと思ったのは複数の考え方（フィラソフィー）を紹介している点です。上級者の書いたコードに機能追加をしていく場合、そのやり方に従うのでこの辺りを理解していない場合があります。私は普段の会話などで何となく理解していたのですが、以下のように綺麗に学派として別れていたのは知りませんでした。

・モック派 (Mockist)
「ロンドン学派」と呼ばれることもある。支持者は、「エンジニアは、テストでプロダクションの依存関係を使用することを避け、代わりにモックを使用する必要がある」と主張する。モックを使用することは、多くの場合、戻り値を提供する依存関係のすべてに、スタブを使用する必要があることも意味する。

・古典派 (Classicist)
「デトロイト学派」と呼ばれることもある。支持者は、「モックとスタブの使用は最小限に抑えるべきであり、エンジニアは、テストでプロダクションの依存関係を使用することを優先するべきである」と主張している。プロダクションの依存関係を使用できない場合は、フェイクを使用することが次の優先事項となる。モックとスタブは、プロダクションの依存関係とフェイクを使用できない場合の最後の手段としてのみ、使用を勧める。

上記の内容はおまけ部分で、より実践的な内容も書かれています。例えばパブリックAPIのみをテストするのは非常に効率の良い方法ではあるが、非パブリックAPIで重要な箇所をテストできないことはある。重要な非パブリックAPI部分はテストをすることを考えた方が良いことなども説明されています。こちらは今の開発で理解していたところでもあるので、非常に重要だよなあと読みながら思いました。