はじめに

新卒でエンジニアとして働き始めて1年がたつので, この1年間で読んだ本を簡単にまとめます。
次年度の新卒1年目の勉強に役立てばと。

紹介は読んだ時系列順で並べていきます。

レベル感とおすすめ度という指標を3段階でつけてます。
こちらはあくまで個人的主観です。状況や知識によって変わると思います。
高専で7年間情報系学科に通ったwebサービスのバックエンドエンジニア1年目の目線でのお話になります。

レベル感: やさしい/ちょっと難しい/難しい
おすすめ度: おすすめ/あまりおすすめできない/おすすめしない

紹介

オブジェクト指向でなぜ作るのか

レベル感: やさしい
おすすめ度: あまりおすすめできない

名前の通り, オブジェクト指向までのプログラミングパラダイムやメモリ管理, 3原則といった話を取り扱っています。
技術本というよりは教科書的な本でした。
内容の7割方は高専や大学の情報系学科を出ていれば知っていることだと思います。
5章のメモリ管理の話は新鮮で勉強になった覚えがあります。

当時, 肝心なオブジェクト指向でなぜ作るのかはこれを読んでもわかりませんでした。
そもそもオブジェクト指向とは何なのかさえ, この本を読んだ後に答えることができなかった記憶があります。
現在, 自分の中でオブジェクト指向とは「ポリモーフィズムによる依存関係逆転を使ったプログラミング系態」だと認識しており, その点でいくとなぜ依存関係をコントロールしたいかポリモーフィズムがそこにどう役立つのかについての記述が足りなかったことが原因だと思います。

オブジェクト指向が何なのか、なぜ使うのかは後述する「Clean Architecture」の5章の説明がとてもよかったです。

現場で役立つシステム設計の原則

レベル感: やさしい
おすすめ度: おすすめ

副題の通り, 変更が容易なプログラムを組むにはどうすれば良いかという話を取り扱っています。
本の内容は, if文の駆逐方法, データとロジックを1つのクラスに集めることの重要性, プレゼンテーション・ユースケース・インフラの3層で設計がうまくいかない理由, ドメインオブジェクト, データベースの制約, などかなり実践的なことがまとまっています。if文の駆逐方法は当時目から鱗でした。

ちなみに,
データとロジックを1つにまとめる理由は, そのデータを使ったロジックをよそに書くことはデータを扱うクラスにゲッターを置くことにつながり, それはユースケース層やプレゼンテーション層でデータを使ったロジックが書かれる(重複の)危険性をはらむためです。
また, 3層でうまくいかない理由は, ロジックの置き場所がなく, ユースケースにロジックを書くことになるため処理に重複が生まれることに繋がるからです。

綺麗なアーキテクチャは, チームメンバーにも綺麗な書き方を強制するという観点でかかれていたことがとても印象的でした。

ここら辺の設計原則は, 学校では習わないプログラマーの基礎知識なので1年目に向いている本だと思います。
自信を持っておすすめできる一冊。現在２周目中。

Clean Architecture

レベル感: ちょっと難しい
おすすめ度: おすすめ

基本的に依存関係のコントロールについての話を扱っています。
この本は少し難しく, 読み切れるかは「依存関係逆転」という概念を知っているかいないかで別れると思います。本文中にも説明はあるのですが, 自分は理解できず先輩方から輪読会の場で説明してもらい何とか読み切りました。
依存関係逆転についてはこちらの記事をどうぞ。今度, 整理の意味を含めて自分でも記事を書きます。
https://eiken7.hatenablog.com/entry/2020/08/11/185801
https://kanoe.dev/blog/dependency-inversion-principle/

ちなみに、エモポイントを連発する本です。

個人的一番のエモは, 5章のこの言葉です。オブジェクト指向とはなんぞやという疑問がここで解決しました。

OO(オブジェクト指向)とは、ポリモーフィズムを使用することで, システムにあるすべてのソースコードの依存関係を絶対的に制御する能力である。

レガシープロジェクトのリファクタリングやリアーキテクチャを意識するようになった最近はここら辺の言葉もエモエモです。

フレームワークにアーキテクチャを乗っ取られないように, 戦略をうまく策定しよう。
アプリケーションとフレームワークを可能な限り結合させようとするだろう。フレームワークなんかと結婚するな！

以下, 1章からいくつかエモポイントを紹介します。

「後でクリーンにすればいいよ。先に市場に出さなければ！」
開発者達はそうやってごまかす。だが後でクリーンにされることはない。市場からのプレッシャーは止まらないからだ。
「先に市場に出さなければ」ということは, 後ろに競合他社が大勢いるということである。競合他社に追い抜かれないためにはこれからも走り続けるしかない。

短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い

崩壊をもたらした自信過剰が, 今度は競走をやり直せばもっとうまく構築できるという話に変わっている。現実はそれほどうまくいかない。
自信過剰による再設計は、元のプロジェクトと同じように崩壊する。

ちょっと難しかったので1年目の方は先輩方の輪読することをおすすめします。

ドメイン駆動設計モデリング/実践ガイド

レベル感: やさしい
おすすめ度: おすすめ

後述する「ドメイン駆動設計入門」を既に読んでいると被る部分も多いですが, Q&Aがとても有用です。例えばリポジトリでのソートの扱いや, キャッシュの扱いなど実装時に絶対疑問が出てくる痒いところに対応してくれています。
分量も少ないので「ドメイン駆動設計入門」を読んだ後にサクッと読んでおいて, 実際にコードを書くときに手引書的に使うのが良いでしょう。
Q&Aという意味ではこちらも参考になります。
https://github.com/little-hands/ddd-q-and-a/issues

Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

レベル感: やさしい
おすすめ度: おすすめ

VOYAGEグループの各サービスのエンジニア文化が書かれている良書です。1年目だとどうしても他社のエンジニア文化に目を向ける機会が少ないので良い機会になると思います。この本で紹介されている文化は良いものばかりですが, その中でも特に, レガシーシステムに対しての取り組みは自分ごとで置き換えられて非常に参考になりました。

ドメイン駆動設計入門

レベル感: やさしい
おすすめ度: おすすめ

ドメイン駆動設計の具体的なコードの書き方を扱っています。
内容も平易で手元に1つ置いておきたいおすすめの一冊。
表紙にある通り値オブジェクトやドメインサービス, リポジトリ, さらにはDIやサービスロケーターの話も乗っており, 幅広く浅い知識をつけるのに向いていると思います。基本これを参考に実装していき, 困った時に「モデリング/実装ガイド」のQ&Aなどを見て実践を積んでいけると良いと思います。
唯一の弱点は, ドメイン層を作るのがなぜ良いのか, ゲッターを作るのがなぜ良くないのかなどの説明が少し少ないことかなと思いますが, ここら辺のモチベーションは「現場で役立つシステム設計の原則」でよく説明されているので, 合わせて読むとより理解が深まります。

Design It!

レベル感: 難しい
おすすめ度: おすすめしない

本の紹介では「設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。」と書かれています。
この本の「設計」や「アーキテクチャ」とは, 「レイヤードアーキテクチャ」や「クリーンアーキテクチャ」などの依存関係や再利用性に注目したアーキテクチャという単語よりももっと広義の意味で, 非機能要件をどう満たすか, そのための開発はどうすれば良いのかといった大きな話をしています。
実際に業務でやっているポジションとはかけ離れていたため, 想像が難しく実際にやってみないと何とも言えない部分も多い印象でした。1年目へのおすすめという意味ではあまりできませんが2,3年後に読み返したい一冊です。

Principle of Programing

レベル感: ちょっと難しい
おすすめ度: あまりおすすめしない

いろんな本で共通して紹介されるような大切な原則をまとめました的な本です。
具体的なコードが出てこず, 抽象的な概念としてまとまっているのである程度, 原則とそれを守らなかったが故の失敗経験がないと内容を噛み締められない可能性があります。知識の整理には良いですが, 1年目で全ての原則に納得感を持つことはできませんでした。もう1年後に読みたい。

レガシーコードからの脱却

レベル感: ちょっと難しい
おすすめ度: あまりおすすめしない

コードの書き方やリファクタリングの方法ではなく, 開発体制からレガシーコードを生み出さないように工夫していこうという結構大きな話を扱っています。特に, 開発体制やデプロイ頻度について多く言及しています。クリーンアーキテクチャのエモポイントで紹介した以下の文にグサっときた方には向いているかもしれません。1年目におすすめかと問われると難しいです。

崩壊をもたらした自信過剰が, 今度は競走をやり直せばもっとうまく構築できるという話に変わっている。現実はそれほどうまくいかない。
自信過剰による再設計は、元のプロジェクトと同じように崩壊する。

終わりに

データ分析やグロースハックの本も読んでいるので次回はその紹介を行います。