購入した技術書を紹介します

こんにちは。
Aiming 第1事業部エンジニアの珍田です。

今日は先日購入した書籍を紹介します。

本を買いました。

私の所属する Aiming 第1事業部はオフィスが手狭になったことから、昨年、隣のビルに事業部ごと引っ越しました。
その際、多くの書籍を旧オフィスに残したため、新しいオフィスの本棚は現在空っぽの状態です（隣のオフィスに行けば読むことはできますが）。

現在、第一事業部では週に n 日出社し、残りの (5 – n) 日は在宅勤務するというハイブリッドな勤務体制を採用しています。
コロナ禍のフルリモート時代と比較して、オフィスにいる時間が増えたため、エンジニアにとって必読の書籍を選んで購入しました。
なるべく、定番となりそうな書籍を選びました。

壁全面の大きな窓で開放感のあるオフィスです。

コーディング、コード設計

リーダブルコード

良いコードとはどんなものでしょうか。
実行処理が短いことだったり、文字数が少ないことが正義だったりと、その判断をする価値基準は現場における要件やメンバーなどによって変わるでしょう。

そんな中でも読み手に誤解させないこと、というのは大事な要素です。
price という変数に文字列が格納されていたり、 getData() というメソッドで データの更新も同時にしている、というのは良くないコードと言えるでしょう。
長大なメソッドで読み解くのに小一時間かかるようなコードも望ましくないコーディングの一例です。

私たちはチームで開発をしています。チームメンバー（あるいは将来の自分）にとって読みやすいコードであることは開発の難度を下げます。
逆に読みにくいコードが存在するプロダクトでは、コードを読み解く時間がかかったり、意図しない場所でバグを生み出したりと、遅々としてプロジェクトが先に進まなくなってしまいます。
私たちは、読み手にコードを誤読させないコードを書くスキルを身につける必要があります。

命名のような些細な点から始まり、読みやすいコードにするための具体的なテクニックまでを紹介してくれている本です。
GitHub の Pull Request のコメントがどうしても多くついてしまうという人は、読みづらいコードだからという可能性があります。
定期的にこの本を読み返してみると良いかもしれません。

=> リーダブルコード

リファクタリング（第2版）既存のコードを安全に改善する

リファクタリングの第二版です。
サンプルコードの言語が Java から Javascript になりました。個人的には Ruby 版がお気に入りなのですが、こちらは絶版のようです（何度も読みました）。
リファクタリングとはコードを綺麗にすることだ、といった認識でとどまりがちな印象を個人的には持っているのですが、どうでしょうか。
リファクタリングを、ふわっと「こっちの方が良いかな？」なんて感じでやると、あっという間に「前の方が良かったかな」とか、「もっと別の方法の方が良いかも」などと袋小路に入ってしまい、どれが相応しいコードかの基準が定まらなくなってしまいます。

この書籍ではリファクタリングのパターンを体系的にまとめています。
個別のリファクタリング手法について、なぜやるのかという「動機」から、そのリファクタリングを実施する「手順」を提示します。そして、サンプルコードを用いて手順通りに実施した「例」が示されます。
目的を持ってリファクタリングができるようになると、「自分の直感できれいにしてみました」ではなく、なぜそのリファクタリングが必要だったのかが説明できるようになるはずです。

とはいっても、リファクタリングそのものは決して敷居の高いものではありません。気軽に、そして頻繁に帽子を被り直しましょう。

=> リファクタリング（第2版）既存のコードを安全に改善する

テスト駆動開発

順番が前後しますが、リファクタリングをするにはテストが欠かせません。
リファクタリングではアプリケーションの挙動が変わってはいけません。そのためには、先にテストコードありきで、後からコードに手を入れるのが安心安全な開発です。
そもそも最初の実装から（設計段階の仕様から）テストを記述して進めていけば、仕様に沿ったソフトウェアができ上がります。

オンラインゲームは継続してアップデートがされることが前提にあります。
そうなると、一度書いたコードを二度と触らないということはほとんど起きません。
何らかの変更が、誰かの手によってされます。
テストコードを書くというのは、堅牢なアプリケーションにする側面もありますが、未来のチームメンバー（自分かも知れませんが）へのメッセージでもあります。
テストコードのないコードに変更を入れるには、（別にあるメンテされているかもわからない）仕様書を読み、コードを読んで完全に理解した気になって不安に襲われつつ実装をするようなものです。

=> テスト駆動開発

ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本

ドメイン駆動設計(DDD) は「エリック・エヴァンスのドメイン駆動設計」や「実践ドメイン駆動設計」という鉄板本がありますが、少々長大で難解な面があるのが難点です。

これらの本以前の入門本として、この書籍をお勧めしたいと思います。
モデリングについては扱っていませんが、DDD におけるパターンを C# のコードでわかりやすく解説しています。
まずはパターンという武器を理解し使えるようにすることで、DDD への理解を進めるために適した本だと思います。

=> ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本

Adaptive Code ~ C#実践開発手法 第2版

C# での開発経験を積んだエンジニアに一読して欲しい書籍です。
冒頭の「本書の対象読者」の項には、「本書の目的は、理論と実践の橋渡しをすることです。本書の対象読者は、デザインパターン、SOLID原則、ユニットテストとリファクタリングなどの実用的な例を求めている経験豊富なプログラマーです。」とあるように、C# での開発経験を一通り体験したあとに読むとすっと腹落ちするようなことが多いのではないかと思います。
特に、テストからリファクタリングに続く章立てや、SOLID 原則を丁寧に解説しているところ、近年の開発ではぜひ理解しておいて欲しい依存性の注入の章があることなどがおすすめポイントです。
なお、原題は “Adaptive Code: Agile coding with design patterns and SOLID principles, Second Edition” で、第1版では邦題も「C#実践開発手法～デザインパターンとSOLID原則によるアジャイルなコーディング」でした。

=> Adaptive Code　～　C#実践開発手法　第2版

ちょうぜつソフトウェア設計入門: PHPで理解するオブジェクト指向の活用

第一章がクリーンアーキテクチャから始まるという珍しい構成ですが、読み進めると納得の章立ての構成です。
全体を通して感動を覚えるような流れるような解説が進行していきます（FizzBuzz のあんな実装は始めて見ました）。
ゆるふわな表紙に対して表紙詐欺と言われるほど内容は硬派ですが、とてもわかりやすく、いろんな本を読んではみたけどいまいちピンとこなかったという人にピッタリの本だと思います。

「Adaptive Code」も「ちょうぜつ…」もアジャイルやデザインパターン、SOLID 原則、TDD、リファクタリング、DI といった、開発の現場で有益な内容を一冊で扱っており、ある意味良いとこどりな書籍となっています。
最初に読んでからトピックを別の本で深掘りすると良いかもしれません。
なお、PHP とありますが、言語の経験の有無やサーバエンジニアかどうかにかかわらず読める本です。

いずれの書籍も現場での開発プロジェクトの経験を 2, 3 件くらい積んだエンジニアに刺さるものが多いのではないかと感じます。
もし、どちらも読むのであれば、「ちょうぜつ」 ⇒ 「Adaptive Code」 の順で良むと良いかなと思います。

=> ちょうぜつソフトウェア設計入門: PHPで理解するオブジェクト指向の活用

（物理本がまだ届いていないので写真がありません）

Game Programming Patterns ソフトウェア開発の問題解決メニュー

デザインパターンは座学で知る方も多いかと思いますが、古臭い何かと思われるかも知れません（そういうものもある。）が実務でもよく使用されるものです。
外部ライブラリを使った実装をするときや、OSS のコードなどを読んでいて、HogeFactory や Observer などと命名されたクラスを目にすることもよくあるでしょう。
実装に使用するのはもちろん会話でも使われるので、代表的なパターンを押さえておくのは重要なことです。
パターンに名前がついているということは重要なことで、会話でその名前を出せばすんなり話が通じるのは良いことです。
この本では、特にゲーム開発に焦点を当てたパターンを紹介している稀な本です。

一般的なデザインパターンについては、「Java言語で学ぶデザインパターン入門」などで一通り把握しておきたいところです。

=> Game Programming Patterns ソフトウェア開発の問題解決メニュー

ネットワーク・セキュリティ

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

ネットワークセキュリティや攻撃手法とその対策などを網羅的に記した本です。
サーバエンジニアやインフラエンジニアにとって、アプリケーション実装やインフラ構成、採用しているサードパーティのアプリケーションといった対象について、攻撃され得る脆弱性がないかどうかは最大の関心ごとであると言って良いものです。
知らない攻撃手法を事前に対策することはできないので、まずは知ることが必要です。
なお、当社ではサービスのリリース前には必ず脆弱性の診断をおこないリリース可否を判断するフェーズによってセキュリティの担保をはかっています。

余談ですが「体系的に学ぶ安全なスマートフォンアプリケーションの作り方」という姉妹本を刊行していただけないかなとずっと思っています。

=> 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Google の SRE(Site Reliability Engineering)チームの面々が執筆した、より実践的な運用に関わる知見や手法をまとめた本です。
上記の「体系的に…」はアプリケーションとそのネットワーク経路上のセキュリティに焦点を当てたものですが、こちらは日々の監視や運用に焦点を当てたものです。
オンラインゲームの世界は一般的なウェブサービスに比べると、サーバへのアクセスが多いのが特徴です。
動いていて当たり前と思われるシステムを、ちゃんと動かしたままにするというのはなかなか困難なミッションです。

=> SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム

開発手法

アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法

プロジェクトやエンジニアチームのリードをするようになると、工数見積もりやスケジュール調整に時間を割くことが多くなります。
そもそも、リーダでなくとも見積もりやスケジュールからは逃れられず、チームメンバー全員が向き合わなくてはなりません。
プロジェクトを進めていく上で大切なことの一つは定期的に計画を見直すことです。アジャイルマニフェストにもあるように、変化への対応を価値とするのです。

不確実性コーンの図から始まる本書は、見積もりの不確実性を認めた上で、どのように見積もりの精度を上げていくのかをプランニングの実践的な手法を合わせて説明していきます。
表題にある通り、アジャイルの要素も含まれていますが、見積もりとタスク管理、スケジューリングについての普遍的な内容だと思います。

ここであげた本の中で、私がこれまで一番繰り返し読んだ本です。

=> アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法

アジャイルサムライ――達人開発者への道

上記「アジャイルな見積もりと計画作り」と似たテーマを扱っていますが、よりアジャイルに焦点を当てており、また、読みやすいライトなテイストで書かれています。
この本で個人的に最も重要な点の一つだと考えるのは、トレードオフスライダーだと思います。荒ぶる四天王をうまく手懐けられるようになると最高です。
エンジニアだけではなく、プロジェクトに関わる全員で同じ概念を共有して開発を進めるべきです。
また、インセプションデッキやエレベーターピッチ、やらないことリストを作る、など、PJ の途中からでもすぐにチームで実行可能なメソッドも紹介されているので、ぜひ実践してみましょう。

=> アジャイルサムライ――達人開発者への道

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

ペアプログラミングやモブプログラミングは、スキルアップやノウハウの共有など多くの面でメリットがあるプラクティスです。
当社でもペアプロやモブプロを現場で取り入れています。
ただ、朝から晩までペアプロをやると大変に疲れるので、必要な場面や定期的に実施する、などのやり方で折を見て実施しています。

本書では、長年のモブプログラミングの経験をもとに、実践的な多くのプラクティスを示してくれます。

なお、「ペアプログラミング―エンジニアとしての指南書」という書籍もあり、ペアプロの基本を教えてくれる良本です。
ケーススタディ方式で「専門家 – 専門家」ペア、「専門家 – 新人」ペア、「外向型 – 内向型」ペアなどのいくつかのケースを想定した面白い読み物があって好きだったのですが、残念ながら今は絶版になっているようで入手が難しいかも知れません。

=> モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モチベーション

最後に、エンジニアとしてモチベーションの上がるような書籍をチョイスしました。

Team Geek―Googleのギークたちはいかにしてチームを作るのか

チームにおいてリーダは役割です。チームメンバーが各々のタスクのオーナシップをもち、リーダシップを発揮して問題解決に向けて進む。
こんなチームが自己組織化された良いチームの一つと言えるのではないでしょうか。
リーダーシップにもいろいろな形があります。率先して引っ張るのが得意なタイプもいれば、サーバントリーダーシップが得意なタイプもいます。
本書ではチームがうまく行くための三本柱 HRT（謙虚、尊敬、信頼）や、アンチパターンなどの例などでメンバ一人ひとりが主体となったチームづくりの秘訣を教えてくれます。

=> Team Geek―Googleのギークたちはいかにしてチームを作るのか

世界一流エンジニアの思考法

Microsoft の Azure Functions チームに飛び込んだ牛尾剛さんの書籍です。
とにかく読んで欲しい、自分もやろう！という気にさせてくれる一冊です。

=> 世界一流エンジニアの思考法

最後に

読みたい本や読んで欲しい本、押さえておくべき教科書的な本など、まだまだたくさんあるのですが、際限がないので現在の事業部の状況に合わせた選書をしてみました。

絶賛エンジニアの採用もおこなっていますので、このラインアップを見てビビッときたエンジニアの方、応募をお待ちしております。