先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、

・ クリーンアーキテクチャ
・ レガシーコード改善ガイド
・ アジャイルサムライ
・ リファクタリング 系のどれか（例えばリファクタリング第二版）

の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。

追記: 煽り成分多いんじゃね？というコメントに思うところがあったので、レビューしてもらって改訂版を書いてみました。初見の人は是非そちらをお読みください。こちらは比較用としてこのままの状態で残しておきます。

この4冊の基準

さてこの4冊は裏テーマでつながっていますが、それはさておき、分かりやすい基準があり、それは読書効率が良いことです。

・ 他の高レベルの本と比べて読みやすいこと
・ 読んで得られるものが大きいこと、効率が良いこと

もちろん、ここに挙げた以外にも良い本はいっぱいあります（例: Code Completeなど）。けど、この4冊に絞った理由は、2020年という現代において読みやすくて効率がいいからです。

では、なぜ最低5回読みかえすように書いているのか？

1回読んだだけで満足する人は伸びない人です。読みやすいといっても一回で理解しきれるわけが無いです。

・ 本で書かれている内容を全部ソラで説明できる
・ 本で書かれていることの本質を全部説明できる
・ これら4冊のつながりを全部説明できる

これらができるなら一回読むだけでいいと思いますが、よっぽどの天才じゃなければ難しいと思います。

読みやすさで選んだものの、それでも一回だけでは理解しきれないはずです。これはもう技術書、専門書の宿命です。諦めてください。

もしこれまでの人生で、技術書を一回しか読んでなかった人は、過去に読んだ全ての本において、表面しか漁ってこなかったということです。読みかえすという習慣を身につけるべきです。

難しい本を読み慣れるためには、繰りかえし読むしかないです。

なお、読むだけではなく、読んで実践して、読んでを繰りかえしてください。実践のともなわない座学は虚しいです。

あ、ちなみに5回って数字自体には別に根拠はありません。最低でも2回以上ですが、深いレベルで理解するためには、5回くらいが妥当かなと雑に考えて書いたってだけなので、2〜3回程度で深いレベルで理解できるならそれでもいいと思いますが、10回以上読んでもまだ新たに得るものがあるかもしれません。

ちなみにあくまで比較して読みやすいなので、今回の4冊が難しいなと感じたら、もう少し易しめに書いてある本からはじめるといいかもしれませんし、いっそ難しいものだと諦めて意味がわからなくても何回か読んでみると何かを得られるかもしれません。

あなたに合った読書スタイルがきっとあるはずです。

クリーンアーキテクチャ

さて、ここからは4冊について個別に「なぜ、その本をオススメするのか？」という理由を書いていきます。

クリーンアーキテクチャといえば、おそらく有名なこの図を思いだすでしょう。

これは、The Clean Architecture というデザインパターン・思想についての概念図です。

ところが、クリーンアーキテクチャ本では、The Clean Architecture そのものに対する言及はほとんどありません。

副題にある「達人に学ぶソフトウェアの構造と設計」がメインな本なのです。

現代の設計論が、なぜそうなっているのか？SOLID原則やコンポーネント・モジュールの考え方、分割の仕方、情報の暴露、アーキテクチャとは何か、アーキテクトは何をする仕事か？を、歴史を交えて、どうやればクリーンなアーキテクチャ（The Clean Architecture とは限らない）を生み出せるのか？という事をひたすら解説している本なのです。

つまり効率良く、広範囲に渡って設計について深く学べる本なのです。

実際、設計について知り尽くしてる人は、この本を読んでも「ふーん」としか思わないはずです。書いていることはある意味当たり前が多いです。

でも、だからこそ良い本なのです。

そういうわけで、この本は設計についてお得に学べる本です。

この本に書かれている事を身につけ実践していくと、クリーンなアーキテクチャについて、理解が深まっているでしょう。クリーンなアーキテクチャの有益な特徴の1つにテストしやすい設計というものがあります。

レガシーコード改善ガイド

レガシーコードとは、「テストのないコード」のことです。自動テストが書かれていないコードはレガシーコードなので、自動テストを書いていこうぜという本です。

レガシーコード改善ガイドは、多少読みづらい本かもしれませんが、読んでおくべきです。

・ テストがない時に、どうやってテストを書きはじめるか？
・ テストを書き続けるためにできることは何か？
・ どうしてテストを書かなければいけないのか？

を学べる力作です。ちなみにレガシーコードシリーズは何冊か出ていますが、僕自身はまだそれらを読んでないので、もしかしたらそっちの方がいいかもしれません。

この本のポイントは、テストがない、つまりレガシーコードを目の前にして、どうやってテストを書き始めるか？というテストにおいて最も厄介なことについて書いていることにあります。

既にテストがあれば、大抵それなりになんとかなるものです。

だからこそ、僕はこの本をオススメするのです。テストの書き方を学べる本は山程ありますが、レガシーコードをなんとかできる本は少なく、この本はこの点において、他を寄せ付けないのです。

リファクタリング系のどれか（リファクタリング第二版など）

Java系の人なら、新装版 リファクタリング も良い本です。リファクタリング Ruby エディションはさすがに古すぎて入手困難により、オススメできないのが難点です。とても良い本だったんですけど。

リファクタリングとは、外から見た振る舞いを変更せずに中身を改善することを指します。外から見た振る舞いはUIや描画内容といったI/O以外にも、関数の入力と出力や、クラス、オブジェクトの挙動など様々なものがあります。

つまり、これら外から見た振る舞いが少しでも変わればそれはリファクタリングではありえません。

リファクタリング本ではソースコードが持つ致命的ではないけど何かしら問題の予兆を感じさせる不吉な匂いを嗅ぎとって、リファクタリングをしていくという内容になっています。

・ どういうコードを書くと不吉な匂いを発するか？
・ どういう手順でコードから不吉な匂いを取り除けるか？

についてのカタログがメインとなる本です。

ソースコードは、最初から悪意を持ってクソコードとして生み出されることはありません。おそらくほとんどの場合は、最初に書かれたコードは、そのときの最善だと思って書かれているのです。

ですが、ソースコードは改善をしなければ、歴史的積み重ねにより、いずれ不吉な匂いを放つようになり、それを放置し続ければ、メンテナンス性が悪化していき、いつの間にか臭いクソになっていくのです。

リファクタリングはそれを除去する唯一の手段です。

クソという比喩の通り、それはとんでもない悪臭を放っていますが、不吉な匂いの時点ではまだ、手を付けやすいはずです。

作り直しという考え方もありますし、式年遷宮アーキテクチャのような考え方も悪くないですが、それは問題から目を背けているともいえて、リファクタリングを身に着けて実践しない限り、どんな新設計のコードも、いつかは不吉な匂いを放ち始めるのです。

読みやすさで言えば、カタログがメインな本であるため、おそらく4冊の中でも読みやすいはずです。ただし「不吉な匂い」と表現されるようなある種曖昧なものを本当に感じとるには実践と経験が必要です。

Q. リファクタリングはいつするの？
A. 常時

Q. リファクタリングって汚いコードを改善すること？
A. 本質的にそれは逆で、不吉な匂いを発してるうちに予防的にリファクタリングしていくことで、ソースコードを汚くしないためのテクニックです。おそらく汚くなってしまったコードを改善するためにはレガシーコード改善ガイドなどの知見も必要になるでしょう。

Q. リファクタリングしなくてもいいんじゃない？
A. その結果、あなたやチームの目の前にあるコードの惨状となっているのです（それがないとしたら、誰かがやってくれているのです）

ただ、常時リファクタリングをするというのは難しそうに思えるでしょう。いくつかの考え方があります。静的型を使っているなら、型の支援を活用しましょう。IDEの支援をうけましょう。QAやテスターの方がいるなら、最悪人力という手段に頼ることも考慮に入れてください。

でも、忘れないでください。最も重要な命綱はもうここまでに挙げています。それは自動テストです。

アジャイルサムライ

この本は他に挙げた三冊とは毛色が違います。この本は設計や実装ではなく、心構えを説いた本です。

他の三冊の背景となる思想や心構えを理解するために、この本を推奨しています。これは、他の三冊をおすすめしつつも、それらがなぜ本当に必要なのか？腹落ちするためにあるのです。

心のレベルで他の三冊について必要性を感じとってください。心の境地を引き上げるためにこの本を読んでみてください。

また、数あるアジャイル系の本の中では、群を抜いて読みやすいのに濃密にアジャイルで大切な事について書いてあります。

やっぱりこの本も効率がとても良いのです。

ちなみにこの本でアジャイルなプログラミングとして書かれているのは次の四つに絞られています。

・ ユニットテスト
・ リファクタリング
・ TDD
・ CI

TDDのためにはユニットテストが必須だし、リファクタリングのためにはCIとユニットテストが必須です。

これら4冊の裏テーマ

さて、もう勘の良い読者の方であれば、僕がこの4冊に込めた裏テーマが分かったことでしょう。

それは、リファクタリング及び、それを支えるための自動テストです。

設計が分かれば自動テストしやすい設計をできるようになりますし、レガシーコード改善ガイドを読んでいれば、テストのない状況からテストを書けるようになり自動テストを生み出せるはずです。自動テストがそろえば、不吉な匂いを嗅ぎ取って安心してリファクタリングを行えるでしょう。

なお、ユニットテストの効能は、ユニットテスト慣れしておくと、ユニットテストしやすい設計（要するに良い設計）をしたくなる、できるようになるというものもあります。ユニットテスト力によって設計力が上がるのです。

メンテナンス性を確保するためにはリファクタリングは不可欠です。

これらは本を読む、実践する、ふりかえるというループによって、上達のスパイラルを形成します。

この過程について心から理解するために、腹落ちするための心構えはアジャイルサムライに記されています。

リファクタリングは呼吸をするかのごとく、水を飲むかのごとく、当たり前にできて然るべきです。

たとえば、エリック・エヴァンスのドメイン駆動設計という本があります。この本は、翔泳社セールではトラップだよ！と書いたものの、ドメイン駆動設計の思想や実現自体はとても良いものです。（本が読みづらいので罠だと表現しただけなんで、内容自体にケチを付けるわけではありません）

ところが、リファクタリングを常時行えない環境では、DDDを体現し続けることは不可能です。

まとめ

挙げた4冊はどれもコスパの良い本です。また、1回読んで満足してはいけません。必ず数回読んで、深いレベルで理解をしてください。表面だけ読んで、読んだ気になってはいけません。

また、読んで、実践して、ふりかえりを繰りかえしてください。上達の鍵です。

設計の基礎を高レベルで身につけるために、クリーンアーキテクチャ本を読んでください。

自動テストのない環境でも自動テストが書けるように、自動テストを書けるようになるために、レガシーコード改善ガイドを読んでください。

ソースコードを臭く悪化させない為に常時リファクタリングをできるようにするために、リファクタリングの本を読んで実践してください。

それらの背景を知り、心構えを得るために、アジャイルサムライを読んでください。

ぼくも、最近これらを読みかえしています。

あなたは表面だけに満足する人ですか？それとも読み返す人ですか？