The Pragmatic Programmer: Your Journey to Mastery（達人プログラマー：熟達に向けたあなたの旅）

引用

Thomas, D., & Hunt, A. (2019). The Pragmatic Programmer: Your Journey to Mastery (20th anniversary ed., 2nd ed.). Addison-Wesley.

章の要約

本書は、短く独立した53の「トピック」を9章にまとめたもので、あとがき、参考文献、演習に対する著者の解答例が付く。主な助言は番号付きの「ヒント」が担い、本文中で囲みに示され、切り取り式のカードにもまとめられている。多くのトピックは演習（比較的はっきりした答えがある）と、答えの定まらない「チャレンジ」で終わり、関連するトピックは相互参照でつながっている。序文は、トピックをどの順番で読んでもよいと述べている。著者によれば、この版ではトピックのおよそ3分の1が新しく、残りの大半も書き直された。並行処理の部分は再編され、リソースの付録は削られ、アジャイルの実践、関数型プログラミングのイディオム、プライバシーとセキュリティを反映した内容が加わった。コード例はRuby、Python、Javaなど複数の言語で書かれている。

第1章：A Pragmatic Philosophy（達人の哲学）

本書全体の根底にある姿勢を示す。自分のキャリアと失敗に責任をもつこと（「The Cat Ate My Source Code」）、ソフトウェアのエントロピーに抗うこと、変化を促すこと（「Stone Soup and Boiled Frogs」）、ソフトウェアがいつ「十分よい」かを判断すること、知識のポートフォリオに投資すること、効果的にコミュニケーションすることである。

第2章：A Pragmatic Approach（達人のアプローチ）

設計の一般原則を扱う。良い設計の本質、DRY（コードの重複だけでなく知識と意図の重複を避けることで、プログラムだけでなくドキュメント、データ、APIにも当てはまる）、直交性、可逆性、曳光弾、プロトタイプ、ドメイン言語、見積もりである。

第3章：The Basic Tools（基本的なツール）

プレーンテキスト、コマンドシェル、エディタの習熟、バージョン管理、デバッグ、テキスト操作言語、そしてエンジニアリング日誌をつけることを扱う。

第4章：Pragmatic Paranoia（達人の偏執）

不完全なソフトウェアのための防御的な実践である。契約による設計、失敗したプログラムを止めること（「Dead Programs Tell No Lies」）、アサーション、リソースのバランス、遠い将来を予測するのではなく小さな歩幅で進むこと（「Don't Outrun Your Headlights」）を扱う。

第5章：Bend, or Break（柳に雪折れなし）

コードを柔軟に保つ方法である。結合の解消、現実世界の出来事への対処、プログラムをデータの変換として考えること、継承のコスト（「Inheritance Tax」。代わりにインターフェース、委譲、ミックスインを勧める）、設定をコードの外に出すことを扱う。

第6章：Concurrency（並行性）

この版で書き直された章である。時間的な結合の解消、共有状態の危険（「Shared State Is Incorrect State」）、アクターとプロセス、黒板を扱う。

第7章：While You Are Coding（コーディング中に）

プログラミング中の習慣である。直感に耳を傾けること、「偶然に頼るプログラミング」を避けること、アルゴリズムの速度、リファクタリング、テスト（「Test to Code」）、プロパティベーステスト、セキュリティ（「Stay Safe Out There」）、命名を扱う。

第8章：Before the Project（プロジェクトを始める前に）

要求とプロジェクトの立ち上げである。本当の要求を掘り出すこと、一見不可能なパズルを解くこと、共同作業、アジャイルの本質を扱う。

第9章：Pragmatic Projects（達人のプロジェクト）

本書の考えをチームとプロジェクトに当てはめる。達人のチーム、「Coconuts Don't Cut It」、達人のスターターキット、ユーザーを喜ばせること、自分の仕事に誇りをもつこと（「Pride and Prejudice」）である。

主要概念

第1–2章：哲学とアプローチ

• ソフトウェアのエントロピー：時間とともにソフトウェアが劣化していくことで、本書はそれと戦うよう読者に促す。
• 知識のポートフォリオ：継続的な学習を、定期的に管理する投資として扱うこと。
• DRY：すべての知識はシステム内で単一、明確、かつ信頼できる表現をもたなければならないという原則。コードだけでなく、ドキュメント、データ、APIにも当てはまる。
• 直交性と可逆性：構成要素を互いに独立に設計し、決定を元に戻しやすく保つこと。

第3–5章：ツール、偏執、柔軟性

• 契約による設計とアサーションを使ったプログラミング：コードが前提とすることと保証することを明示し、確かめること。
• 小さな歩幅：知りえない将来に向けて設計するのではなく、結果を確かめられる一歩だけを進めること。
• 継承税：継承が生む結合と、インターフェース、委譲、ミックスインを使う理由。

第6–7章：並行性とコーディング

• 共有状態は誤った状態：共有資源への並行アクセスには排他的アクセスかトランザクションが必要であり、ランダムな失敗はしばしば並行性の問題を示している。
• 偶然に頼るプログラミング：たまたま動いているコードに頼ること。本書はこれを戒める。
• プロパティベーステスト：生成された入力に対して、コードの一般的な性質を検査するテスト。

第8–9章：プロジェクトとチーム

• 要求の落とし穴：ユーザーが本当に必要としているものを知ることの難しさ。出版社の説明では「本当の要求を知る」とまとめられている。
• 達人のスターターキット：著者がすべてのプロジェクトで整えるよう勧める基本的な実践。

批判的分析

長所

• 短く独立したトピック。 各トピックは独立しており相互参照されているので、どの順番でも読め、授業のプロジェクトと並行して一つずつ課題にできる。
• 徹底した改訂。 序文によれば、トピックの約3分の1が新しく、残りの大半も書き直された。出版社は新しい節を10と数えており、目次にはプロパティベーステスト、セキュリティ、アクター、エンジニアリング日誌といった今日的な話題が並ぶ。
• 練習が組み込まれている。 解答例付きの演習と答えの定まらないチャレンジがあり、著者はチャレンジを上級プログラミングの授業でのグループ討論やレポートに使うことを提案している。出版社も、教室向けの教員用資料と演習セットを挙げている。
• 言語に依存しない助言と具体的なコード。 原則は一般的な言葉で述べられ、コード例は短く、複数の言語で書かれている。

短所

• 深さより広さ。 約300ページに53のトピックがあるため、各話題には数ページしか割かれない。並行性、テスト、要求、アーキテクチャは、それぞれ他でより詳しく学ぶ必要がある。
• 方法ではなく助言。 本書が示すのは体系的なプロセスや実証的根拠ではなくヒントと逸話であり、著者自身も、提案の一部は間違っていると判断してよいと読者に呼びかけている。
• ある程度の経験があってこそ役立つ。 多くのトピックは、他人とコードを書き、バージョン管理を使い、重複や不安定な並行処理といった問題に出会った経験を前提にしている。まったくの初心者には抽象的に感じられる助言もあるだろう。

コースにおける位置づけ

ソフトウェア工学のコースの中で、本書は個々の開発者の習慣について最も幅広く扱う本である。自然な相棒は Ousterhout の A Philosophy of Software Design である。そちらはモジュール設計による複雑さの管理という一つの問いを深く掘り下げ、Thomas と Hunt は設計、ツール、テスト、並行性、チームワークを短い文章で見渡す。DRY、直交性、継承のトピックを Ousterhout の深いモジュールと情報隠蔽の章と並べて読むと、両者が一致する点と異なる点がわかる。

Sommerville の Software Engineering は、本書が触れるだけの体系的なライフサイクルの視点（要求、プロセス、検証）を与え、Software Engineering at Google は同じ関心事を組織規模で示し、Bass、Clements、Kazman の Software Architecture in Practice と Jackson の Software Abstractions はアーキテクチャと形式的モデリングにずっと深く踏み込む。本書は、最初の本格的なプロジェクトの最中に早めに読み、後で読み返すのがよい。

本書の使い方

出版社は本書を、新人のプログラマー、経験を積んだプログラマー、そしてソフトウェアプロジェクトを担当するマネージャーに向けている。何らかの言語でのプログラミング経験があれば十分で、ソフトウェア工学の予備知識は必要ない。

• 中核： 第1–2章（哲学とアプローチ）と第7章（コーディング中に）。
• プロジェクトの最中に： ツールの第3章と防御的プログラミングの第4章、続いて達人のスターターキットの第9章。
• 必要に応じて： コードが変更しにくくなったら第5章、並行処理が現れたら第6章、実際のユーザーがいるプロジェクトの始めに第8章。

週に一つか二つのトピックを読み、自分の仕事で実行に移すとよい。エンジニアリング日誌をつけ始める、ビルドの一手順を自動化する、自分のコードからDRY違反を一つ探す、といった具合である。演習は著者の解答を読む前に解き、チャレンジは勉強会の討論の題材にするとよい。ヒントのカードを手元に置き、1、2年の経験を積んでから本書に戻ってくること。