Curated Tech Reading Map

次に読むべき技術書が見つかるサイト

ブログ記事

プログラマーとしてのキャリアを設計する:Andrew Hunt & David Thomas『達人プログラマー』

著者: DevBookPath 編集部公開日:

1999年に初版が出て以来、ソフトウェア開発者の定番書として読み継がれてきた。Andrew Hunt と David Thomas の『達人プログラマー』(第2版: 2019年)は、特定のプログラミング言語や技術に依存せず、「どう考え、どう行動するか」という姿勢の問題を扱っている。

1. DRYは「コードの重複禁止」ではない

Don't Repeat Yourself(DRY)原則は広く知られているが、本書の定義は単純なコードのコピペ禁止とは異なる。

本書でのDRYは「すべての知識は、システム内で唯一の、曖昧さのない、権威ある表現を持たなければならない」という原則だ。ここで言う「知識」はコードだけでなく、ドキュメント、設定ファイル、データベーススキーマにも及ぶ。

例えば、同じビジネスルールがコードとコメントと仕様書の3箇所に書かれていると、一方を変更したとき他の2箇所との乖離が生まれる。DRYの違反は、変更のたびに複数箇所を修正する必要が生じるという形で現れる。

2. 曳光弾:動くものを素早く見せる

本書が提示する「曳光弾(Tracer Bullet)」の概念は、プロトタイプとは異なる実装スタイルだ。

プロトタイプは使い捨てを前提とした探索コードだが、曳光弾は「完成品と同じ素材で作った細い実装」だ。フロントエンドからバックエンドまで一貫して動く最小限の経路を、早期に本番環境のコードで通す。この経路を軸に、徐々に肉付けしていく。

曳光弾の価値は、要件が変わった場合に「軸」を早期に確認できる点にある。設計の大半が完了してから「方向が違った」と気づくリスクを下げる。

3. 壊れた窓と技術的負債

「壊れた窓」の比喩は本書の中でも特によく引用される節だ。

建物の窓が壊れたまま放置されると、周囲も荒廃していく——という社会心理学の観察を、ソフトウェア開発に適用している。品質の低いコードが一箇所残っていると、「どうせ汚いコードだから」という判断が周囲に広がり、品質の劣化が加速する。

逆に言えば、小さな問題を素早く修正することが、コードベース全体の品質を維持する習慣になる。技術的負債の蓄積に対する実践的な処方箋だ。

4. ETC:変更しやすいかどうかを設計の軸にする

第2版で追加された「ETC(Easy To Change)」の概念は、本書全体の設計判断を貫くテーマだ。

SOLIDや他の設計原則が有用である理由は、それらが変更しやすいコードを作るからだ——という視点から、本書はすべての設計判断を「このコードは変更しやすくなるか?」という問いに統一する。

ETCは「良い設計とは何か」という複雑な問いに対して、実践的な判断軸を与える。特定の原則を暗記するより、この問いを習慣的に問い続ける方が長期的には有効だという主張だ。

DevBookPath のマップで確認する

この本の前後の読書順は、DevBookPath のグラフで確認できます。

👉 ソフトウェア設計の地図を見る


本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。

この記事を共有

この地図を共有