出版書誌データベース

「切り裂きジャック（Jack the Ripper）」とプログラムのソースコードには、実は共通点がたくさんあります。本書では、科学的犯罪捜査の手法を活用し、犯罪の地理的プロファイルを使ってコミットログからコードベースを視覚化し、開発のホットスポット（不具合が発生している可能性が高いところ）を見つけ、技術的負債に優先順位を付け、隠れた依存関係を明らかにします。それにより、リファクタリングの方向性を評価したり、チームがソフトウェア アーキテクチャにどのように影響するかを理解したりといった戦略を立てることが可能になります。また、これらの分析や戦略は、プログラミング言語、あるいは、コードベースの規模を問いません。
本書は、大きく3つの部に分かれています。「第1部　理解しにくいコードを特定する」では、ソフトウェアのソースコードを犯罪現場のように分析し、問題点を特定・解決することで、よりよいソフトウェアを開発する方法論を紹介します。「第2部　支援的なソフトウェアアーキテクチャの構築」では、ソースコードの特定の問題だけでなく、システム全体を俯瞰し、設計と実装の整合性を検証する方法を解説します。ソースコードの履歴を分析することで、開発者の意図やシステムの進化を理解し、リファクタリングやモダナイゼーションに役立つ情報を引き出します。「第3部　コードの社会的側面」では、チームの組織化とソフトウェアアーキテクチャのミスマッチが、コードの品質低下やコミュニケーション問題を引き起こすことを解説します。社会的バイアスやチームの決定過程がソフトウェア開発に与える影響も分析し、よりよいチーム開発を実現するためのヒントを提供します。また、付録には、各章の章末にある練習問題の解答を掲載しています。

○ 目次
第1部　理解しにくいコードを特定する
　第1章　理解するための最適化
　第2章　コードを犯罪現場として扱う
　第3章　ホットスポットの検出：コードの犯罪者プロファイルを作成する
　第4章　ホットスポットの応用：人の視点に立ってコードを可視化する
　第5章　劣化している構造を突き止める
　第6章　複雑なコードを修正する
　第7章　技術的負債のビジネスへの影響を伝える
第2部　支援的なソフトウェアアーキテクチャの構築
　第8章　コードは協力的な目撃者
　第9章　アーキテクチャのレビュー：データに基づく設計の見直し
　第10章　従うべきは美しさ
　第11章　隠れたボトルネックを明らかにする：デリバリーと自動化
第3部　コードの社会的側面
　第12章　社会的バイアス、グループ、偽の連続殺人犯
　第13章　コードベースで組織的な指標を発見する
　第14章　技術的な問題が組織的な問題を引き起こすとき
　第15章　システムの知識マップを作成する
　第16章　未来に向かって
付録
　付録A　練習問題の解答
　付録B　エンクロージャの可視化

本書に寄せて
謝辞
犯罪現場へようこそ
第2版の日本語版へのまえがき
監訳者まえがき
第1部　理解しにくいコードを特定する
　第1章　理解するための最適化
　　1.1　コーディングがプログラミングのボトルネックではないことを理解する
　　　1.1.1　アジャイルの世界でメンテナンスを理解する
　　1.2　規模の課題に対処する
　　　1.2.1　デジタルの干し草の山から針を見つける
　　1.3　複雑さの指標の誘惑にご用心
　　　1.3.1　振る舞いの観点からコードにアプローチする
　第2章　コードを犯罪現場として扱う
　　2.1　速習：犯罪者プロファイリング
　　　2.1.1　犯罪の地理的プロファイリングを学ぶ
　　　2.1.2　犯行パターンを見つける
　　　2.1.3　切り裂きジャックのプロファイル
　　2.2　地理的犯罪者プロファイリングをコードに応用する
　　　2.2.1　コードを地理的に探索する
　　2.3　捜索範囲を絞り込む：コードの空間的パターン
　　　2.3.1　変更頻度を捜査の指針にする
　　　2.3.2　複雑さと関連性を組み合わせてホットスポットを特定する
　　　2.3.3　ホットスポットは欠陥の予兆となる
　　2.4　ホットスポットは確率を反映する
　第3章　ホットスポットの検出：コードの犯罪者プロファイルを作成する
　　3.1　コードの進化を掘り出す
　　　3.1.1　Gitログに慣れる
　　　3.1.2　Code Maat用のGitログを作成する
　　　3.1.3　コミットアクティビティを調べる
　　　3.1.4　影響の分析:コードの変更頻度を計算する
　　3.2　複雑さの次元を調べる
　　　3.2.1　コードの行数から複雑さを把握する
　　　3.2.2　clocで行数を調べる
　　3.3　複雑さと作業量が交差する場所
　　3.4　空間的確率分布によるリファクタリング
　　　3.4.1　技術的負債をすべて返済しなくてもよいのはなぜか
　　3.5　練習問題
　　　3.5.1　ホットスポット分析をコードベースの一部に限定する
　第4章　ホットスポットの応用：人の視点に立ってコードを可視化する
　　4.1　ソースコードを可視化する
　　　4.1.1　可視化を比較する
　　　4.1.2　コードベースのメンタルモデルを構築する
　　　4.1.3　コードを可視化する
　　　4.1.4　可視化空間を探索する
　　4.2　言語に依存しない分析：言語の壁を打ち破る
　　4.3　ホットスポットの温度を確認する
　　　4.3.1　分析の期間を選択する
　　　4.3.2　コミットのスタイルを統一する
　　4.4　バグがバグを生む
　　　4.4.1　ホットスポットと欠陥の関係
　　4.5　情報は使ってこそ価値がある
　　4.6　練習問題
　　　4.6.1　言語に依存しない分析を試してみる
　　　4.6.2　Vue.js：もう1つの選択肢
　　　4.6.3　Kubernetesの技術的負債を特定する
　第5章　劣化している構造を突き止める
　　5.1　コードの形状から複雑さの傾向を判断する
　　　5.1.1　複雑さをひと目で判断する
　　5.2　コードのネガティブスペースを調べる
　　　5.2.1　複雑さに関するホワイトスペース分析
　　5.3　絶対値よりも傾向を優先する
　　　5.3.1　ある範囲のリビジョンを分析する
　　　5.3.2　傾向を突き止める
　　　5.3.3　複雑さの傾向を可視化する
　　5.4　成長のパターンを評価する
　　　5.4.1　複雑なコードから学ぶ
　　　5.4.2　スタイルの変化に注意する
　　　5.4.3　複雑さを理解する
　　5.5　練習問題
　　　5.5.1　Kubernetesの主な容疑者を調べる
　　　5.5.2　傾向をコードの複雑さのカナリアとして使う
　第6章　複雑なコードを修正する
　　6.1　コードを通して脳を科学する
　　　6.1.1　コードを脳に合わせて調整する
　　　6.1.2　凝集性を考慮した設計
　　　6.1.3　関数名に基づいてホットスポットをリファクタリングする
　　　6.1.4　形式分析を使って凝集性を計測する
　　　6.1.5　変更を切り離す設計
　　6.2　ワーキングメモリに負担をかける入れ子のロジックを突き止める
　　　6.2.1　でこぼこ道には近寄らない
　　6.3　複雑なコードのリファクタリング：シンプルな手順
　　　6.3.1　不適切な名前を見分ける
　　　6.3.2　指標ではなく脳に合わせて最適化する
　　6.4　オブジェクト指向から逸脱しない
　　　6.4.1　プリミティブ型に執着しない
　　　6.4.2　デメテルの法則に従う
　　6.5　思考ツールとして抽象化を使う
　　6.6　練習問題
　　　6.6.1　ハリウッドからの電話
　　　6.6.2　シンプルなボタンを単純化する
　第7章　技術的負債のビジネスへの影響を伝える
　　7.1　技術的負債のコストと結果を知る
　　　7.1.1　持続可能なソリューションよりも短期的な利益が優先される理由
　　7.2　作業の半分に2倍の時間がかかる理由
　　　7.2.1　結果1：機能を2倍の速さで実装できる
　　　7.2.2　結果2：機能の実装に桁違いに時間がかかることがある
　　　7.2.3　結果3：Redコードはバグの温床
　　7.3　リファクタリングのためのビジネスケースを作成する
　　　7.3.1　リファクタリングをビジネスの期待値に合わせる
　　　7.3.2　リスクベースの計画を立てて双曲割引に対抗する
　　7.4　プロジェクトのサイレントキラー：計画外の作業と戦う
　　　7.4.1　計画外の作業を定量化してITブラックボックスを開ける
　　　7.4.2　技術的負債に縛り付けられた未活用のキャパシティを計算する
　　　7.4.3　質を高めてスピードを上げる
　　7.5　修正の時間と利払いを区別する
　　7.6　練習問題
　　　7.6.1　許容できるリスクを理解する
　　　7.6.2　より大規模なリファクタリングの動機を理解する
　　　7.6.3　技術的負債の兆候を見つける
第2部　支援的なソフトウェアアーキテクチャの構築
　第8章　コードは協力的な目撃者
　　8.1　虚偽記憶のパラドックス
　　　8.1.1　無実の強盗
　　　8.1.2　協力的な目撃者を事情聴取するときは先入観を減らす
　　　8.1.3　虚偽記憶が植え付けられることに注意する
　　8.2　変更の仕組みを明らかにする
　　　8.2.1　すべての依存関係が同等ではないことを認識する
　　　8.2.2　偶有的な複雑性には2つの形式がある
　　8.3　コード変更の手口を調べる
　　　8.3.1　システム内のChange Couplingを可視化する
　　　8.3.2　ReactでChange Couplingを分析する
　　8.4　時間的な依存関係の背後にある理由を理解する
　　8.5　練習問題
　　　8.5.1　言語に依存しない依存関係分析
　　　8.5.2　TeslaアプリのDRY違反を突き止める
　　　8.5.3　表現のソースを1つにするための設計
　第9章　アーキテクチャのレビュー：データに基づく設計の見直し
　　9.1　使者を撃ってはならない
　　9.2　Sum of Couplingを使ってアーキテクチャの目的を判断する
　　　9.2.1　SoC分析を使ってアーキテクチャをレビューする
　　　9.2.2　SoC分析の結果をChange Coupling分析で調べる
　　　9.2.3　学習曲線を平らにする
　　9.3　Change Couplingのさまざまなアルゴリズム
　　　9.3.1　時間を考慮するアルゴリズムを使う
　　　9.3.2　アルゴリズムをシンプルに保つ
　　　9.3.3　Change Couplingの限界
　　9.4　アーキテクチャの劣化を検知する
　　　9.4.1　継続的な変更のための設計
　　　9.4.2　予想外の変更パターンを特定する
　　　9.4.3　Change Couplingのホットスポットに着目する
　　　9.4.4　依存関係を断ち切る
　　9.5　モノリスをモジュール化する
　　　9.5.1　レガシーモダナイゼーションプロジェクトを進行させる
　　　9.5.2　モダナイゼーションの落とし穴に気をつける
　　　9.5.3　新しいコードを継続的に監視する
　　　9.5.4　ソフトウェアアーキテクチャを単純化する
　　9.6　練習問題
　　　9.6.1　ホットスポットとSoC分析を組み合わせてリファクタリングの優先順位を決める
　　　9.6.2　循環依存：Change Couplingを使って設計を改善する
　第10章　従うべきは美しさ
　　10.1　なぜ魅力的であることは重要か
　　　10.1.1　美しさを否定概念として捉える
　　10.2　コードに美しさを
　　　10.2.1　アーキテクチャに驚かされないようにする
　　　10.2.2　パターンに照らして評価する
　　10.3　Pipes and Filtersアーキテクチャを分析する
　　　10.3.1　実装を調べる
　　　10.3.2　アーキテクチャ上の重要なコンポーネントを定義する
　　　10.3.3　問題のあるコードを特定する
　　10.4　階層化アーキテクチャを分析する
　　　10.4.1　重要な層を特定する
　　　10.4.2　各層をアーキテクチャの境界として定義する
　　　10.4.3　高くつく変更パターンを特定する
　　　10.4.4　なぜ階層化が「関心の混乱」を表すのか
　　　10.4.5　階層から移行する
　　　10.4.6　パターンを魅力的なコードベースの土台にする
　　10.5　マイクロサービスシステムを分析する
　　　10.5.1　マイクロサービスシステムでの変更について考える
　　　10.5.2　新しいサービスのメンタルモデルを構築する
　　　10.5.3　複数のGitリポジトリにまたがるChange Couplingを追跡する
　　10.6　コードから原理原則をリバースエンジニアリングする
　　　10.6.1　大きな泥団子を解明する
　　　10.6.2　親近感と美しさを混同しない
　　　10.6.3　早い段階から継続的に分析する
　　10.7　練習問題
　　　10.7.1　マイクロサービスの結合を調べる：DRYかWETか
　　　10.7.2　モノリスを分解する
　　　10.7.3　醜いコードを美しくする
　第11章　隠れたボトルネックを明らかにする：デリバリーと自動化
　　11.1　アーキテクチャの内容を理解する
　　　11.1.1　自動テストをアーキテクチャ層として捉える
　　11.2　テストコードのターゲットをプロファイルする
　　　11.2.1　アーキテクチャの境界を指定する
　　　11.2.2　分析結果を解釈する
　　11.3　自動テストのセーフティネットを作成する
　　　11.3.1　すべてのイテレーションでテストを監視する
　　　11.3.2　変更パターンからテストについて考える
　　11.4　自動テストのデスマーチを回避する
　　　11.4.1　パラメータ化されたテストを使って重複を減らす
　　　11.4.2　テストコードは単なるテストコードにあらず
　　　11.4.3　テストの基準をカプセル化する
　　　11.4.4　テストでの重複するコードの使用を評価する
　　11.5　人間による問題解決のための設計
　　　11.5.1　継続的なフィードバックのための計画
　　　11.5.2　継続的フィードバックのための分割統治
　　　11.5.3　コードカバレッジに基づく逆転の発想
　　　11.5.4　自動化がうまくいかなかった場合のコスト
　　11.6　練習問題
　　　11.6.1　テストのテストでホットスポットに対処する
　　　11.6.2　テストコードから高価な変更パターンを特定する
　　　11.6.3　テストコードのリファクタリング
第3部　コードの社会的側面
　第12章　社会的バイアス、グループ、偽の連続殺人犯
　　12.1　正しい人々が声を上げない理由
　　　12.1.1　チームにおけるプロセスロス
　　　12.1.2　社会的バイアス
　　　12.1.3　テクノロジーの選択と文化との結び付き
　　12.2　多元的無知
　　　12.2.1　質問とデータでバイアスに挑む
　　12.3　実際の集団思考
　　　12.3.1　権威の役割
　　　12.3.2　従来のブレインストーミングから脱却する
　　12.4　チームの手口を明らかにする
　　　12.4.1　コミットメッセージを議論の材料として使う
　　　12.4.2　チームのコミットクラウドで物語を読み解く
　　12.5　コードから組織の指標を掘り出す
　　12.6　練習問題
　　　12.6.1　チームの手口を特定する
　　　12.6.2　メイントピックを掘り下げる
　第13章　コードベースで組織的な指標を発見する
　　13.1　プロジェクトの息の根を止める方法：入門ガイド
　　　13.1.1　スケールアップする次元を間違えてはならない
　　　13.1.2　人月は今も神話のまま
　　　13.1.3　責任の拡散
　　13.2　調整問題のホットスポット分析
　　　13.2.1　オープンソースソフトウェアとプロプライエタリソフトウェアの違いを理解する
　　　13.2.2　複数の作成者が関与するホットスポットを分析する
　　13.3　コードでコンウェイの法則を特定する
　　　13.3.1　既存のシステムでコンウェイの法則を使う
　　　13.3.2　コンウェイの法則を可視化する
　　　13.3.3　作成者のエイリアスを解決する
　　　13.3.4　個人からチームへのスケールアップ：コードでのソーシャルネットワーク
　　13.4　チーム間の依存関係に対処する
　　13.5　練習問題
　　　13.5.1　成果物が減少した理由を調べる
　　　13.5.2　分析をモノレポの一部に制限する
　第14章　技術的な問題が組織的な問題を引き起こすとき
　　14.1　コードでつなぎ止める
　　　14.1.1　バッドコードは不幸の始まり：科学的な関連性
　　14.2　コードの臭いが調整の問題を引き起こすとき
　　　14.2.1　ホットスポットが複数の作成者を引き寄せる仕組み
　　　14.2.2　プロジェクトを破綻させる技術的要因に注意する
　　　14.2.3　チーム間で矛盾している非機能要件に注意する
　　14.3　組織の摩擦を可視化する
　　　14.3.1　チーム間の依存関係を認識する
　　　14.3.2　チームとアーキテクチャを合理化する
　　14.4　不健全なコードでトラック係数を計測する
　　　14.4.1　知識サイロ
　　　14.4.2　トラック係数を計算するためにメイン開発者を特定する
　　　14.4.3　トラックの進路から外れる
　　14.5　コードの人的な側面を明らかにする
　　14.6　練習問題
　　　14.6.1　Vue.jsのトラック係数を調べる
　第15章　システムの知識マップを作成する
　　15.1　知識の分布を知る
　　　15.1.1　作成者を調べる
　　15.2　ソーシャルデータでメンタルマップを拡張する
　　　15.2.1　知識マップを探索する
　　　15.2.2　知識マップをアーキテクチャレベルに拡張する
　　15.3　開発者パターンで真相を探る
　　　15.3.1　フラクタル図を使って開発者の作業を可視化する
　　　15.3.2　所有権モデルを区別する
　　15.4　フラクタル図を使ってオフボーディングのリスクを減らす
　　　15.4.1　代わりの人材を採用する
　　　15.4.2　トラックをよける
　　15.5　使用と誤用を区別する
　　　15.5.1　貢献データをパフォーマンスの評価に使うのは間違い
　　　15.5.2　未来に目を向ける
　　15.6　練習問題
　　　15.6.1　影響を明らかにする：トラックに二度ひかれる
　　　15.6.2　オフボーディングリスクに優先順位を付ける
　第16章　未来に向かって
　　16.1　さらに深く調査する
　　　16.1.1　調査範囲をソースコード以外に広げる
　　　16.1.2　ホットスポットのレントゲン検査
　　　16.1.3　開発者ネットワークを分析する
　　　16.1.4　ペアプログラミングのために分析をカスタマイズする
　　16.2　次のステップを見守る
　　　16.2.1　コードリーディングをサポートする
　　　16.2.2　動的な情報を統合する
　　16.3　新たな時代：AIの世界でのプログラミング
　　　16.3.1　機械の反乱に立ち向かう
　　　16.3.2　AIの課題を解決する
　　16.4　進化の逆進：ローコードアプローチ
　　　16.4.1　ビジュアルプログラミングでの複雑さのシフト
　　16.5　進化可能なコードを書く
付録
　付録A　練習問題の解答
　　A.1　第1部　理解しにくいコードを特定する
　　　A.1.1　第3章　ホットスポットの検出：コードの犯罪者プロファイルを作成する
　　　A.1.2　第4章　ホットスポットの応用：人の視点に立ってコードを可視化する
　　　A.1.3　第5章　劣化している構造を突き止める
　　　A.1.4　第6章　複雑なコードを修正する
　　　A.1.5　第7章　技術的負債のビジネスへの影響を伝える
　　A.2　第2部　支援的なソフトウェアアーキテクチャの構築
　　　A.2.1　第8章　コードは協力的な目撃者
　　　A.2.2　第9章　アーキテクチャのレビュー：データに基づく設計の見直し
　　　A.2.3　第10章　従うべきは美しさ
　　　A.2.4　第11章　隠れたボトルネックを明らかにする：デリバリーと自動化
　　A.3　第3部　コードの社会的側面
　　　A.3.1　第12章　社会的バイアス、グループ、偽の連続殺人犯
　　　A.3.2　第13章　コードベースで組織的な指標を発見する
　　　A.3.3　第14章　技術的な問題が組織的な問題を引き起こすとき
　　　A.3.4　第15章　システムの知識マップを作成する
　付録B　エンクロージャの可視化
参考文献
索引

著：Adam Tornhill
○ Adam Tornhill（あだむ・とーんひる）
工学と心理学の両方の学位を持つ、スウェーデンのプログラマー。チームが優れたソフトウェアを構築できるようにするコード分析ツールを設計しているCodeSceneの創設者。レトロコンピューティングや武道など、多岐にわたる興味を持っている。

監：園田道夫
○ 園田 道夫（そのだ みちお）
セキュリティ・スタジアム、日本ネットワークセキュリティ協会、独立行政法人情報処理推進機構（IPA）、セキュリティ・キャンプ、情報危機管理コンテスト、サイバー大学IT 総合学部、SECCON、AVTOKYO、国立研究開発法人情報通信研究機構（NICT）、CYDER、サイバー・コロッセオ、SecHack365、RPCI、CIDLE などに関わる。人材育成に関わるふりして、人材に育成されてきました。最近は、サッカー観戦の合間に仕事をしています。

訳：株式会社クイープ
○ 株式会社クイープ
コンピューターシステムの開発、ローカライズ、コンサルティングを手がけている。主な訳書に『Pythonによる因果推論・因果探索』（インプレス）、『Pythonクイックリファレンス 第4版』（オライリー・ジャパン）、『爆速Python』（翔泳社）、『Pythonによる時系列予測』（マイナビ出版）などがある。