脳に収まるコードの書き方

推薦の言葉
シリーズエディターによるまえがき
はじめに

第I部　加速

1章　アートかサイエンスか
    1.1　家を建てる
        1.1.1　プロジェクトの問題
        1.1.2　フェーズの問題
        1.1.3　依存関係
    1.2　庭を育てる
        1.2.1　何が庭を育てるのか？
    1.3　エンジニアリングに向けて
        1.3.1　工芸品としてのソフトウェア
        1.3.2　経験則
        1.3.3　ソフトウェアエンジニアリングの初期の概念
        1.3.4　ソフトウェアエンジニアリングの前進
    1.4　まとめ

2章　チェックリスト
    2.1　記憶の補助
    2.2　新規コードベースのためのチェックリスト
        2.2.1　Gitを使え
        2.2.2　ビルドを自動化せよ
        2.2.3　エラーメッセージをすべて有効にせよ
    2.3　既存のコードベースにチェックを追加する
        2.3.1　漸進的改善
        2.3.2　組織をハックする
    2.4　まとめ

3章　複雑さに対処する
    3.1　目的
        3.1.1　持続可能性
        3.1.2　価値
    3.2　なぜプログラミングは難しいのか
        3.2.1　脳のメタファー
        3.2.2　コードは書く回数より読む回数のほうが多い
        3.2.3　可読性
        3.2.4　知的労働
    3.3　ソフトウェアエンジニアリングに向けて
        3.3.1　コンピューターサイエンスとの関係性
        3.3.2　ヒューマンフレンドリーなコード
    3.4　まとめ

4章　バーティカルスライス
    4.1　動くソフトウェアから始める
        4.1.1　データ入力からデータ永続化まで
        4.1.2　最小のバーティカルスライス
    4.2　ウォーキングスケルトン
        4.2.1　特性評価テスト
        4.2.2　Arrange-Act-Assert
        4.2.3　静的解析の節度
    4.3　外側から内側へ（アウトサイドイン）
        4.3.1　JSON を受け取る
        4.3.2　予約をポストする
        4.3.3　ユニットテスト
        4.3.4　DTOとドメインモデル
        4.3.5　フェイクオブジェクト
        4.3.6　リポジトリインターフェイス
        4.3.7　リポジトリ内での作成
        4.3.8　依存を構成する
    4.4　バーティカルスライスを完成させる
        4.4.1　スキーマ
        4.4.2　SQLリポジトリ
        4.4.3　データベースの構成
        4.4.4　スモークテストの実施
        4.4.5　フェイクデータベースによる境界テスト
    4.5　まとめ

5章　カプセル化
    5.1　データの保存
        5.1.1　変換の優先順位
        5.1.2　パラメーター化テスト
        5.1.3　DTOをドメインモデルにコピーする
    5.2　バリデーション
        5.2.1　不正な日付
        5.2.2　レッド/グリーン/リファクタリング
        5.2.3　自然数
        5.2.4　ポステルの法則
    5.3　不変条件の保護
        5.3.1　常に有効
    5.4　まとめ

6章　三角測量
    6.1　短期記憶と長期記憶
        6.1.1　レガシーコードと記憶
    6.2　定員
        6.2.1　オーバーブッキング
        6.2.2　悪魔の代弁者
        6.2.3　既存の予約
        6.2.4　悪魔の代弁者vsレッド/グリーン/リファクタリング
        6.2.5　どれだけテストを書けば十分か？
    6.3　まとめ

7章　分解
    7.1　コードの腐敗
        7.1.1　しきい値
        7.1.2　サイクロマティック複雑度
        7.1.3　80/24ルール
    7.2　脳に収まるコード
        7.2.1　ヘックスフラワー
        7.2.2　凝集
        7.2.3　特性の横恋慕
        7.2.4　ロスト・イン・トランスレーション
        7.2.5　検証せずにパースする
        7.2.6　フラクタルアーキテクチャー
        7.2.7　変数を数える
    7.3　まとめ

8章　API設計
    8.1　API設計の原則
        8.1.1　アフォーダンス
        8.1.2　ポカヨケ
        8.1.3　読む人のために書く
        8.1.4　コメントよりもわかりやすい名前のコードを
        8.1.5　名前をXで置き換える
        8.1.6　コマンドクエリ分離
        8.1.7　コミュニケーション階層
    8.2　API設計の例
        8.2.1　メートル・ドテル
        8.2.2　カプセル化されたオブジェクトとやりとりする
        8.2.3　実装の詳細
    8.3　まとめ

9章　チームワーク
    9.1　Git
        9.1.1　コミットメッセージ
        9.1.2　継続的インテグレーション
        9.1.3　小さなコミット
    9.2　コードの共同所有
        9.2.1　ペアプログラミング
        9.2.2　モブプログラミング
        9.2.3　コードレビューの遅延
        9.2.4　チェンジセットを拒否する
        9.2.5　コードレビュー
        9.2.6　プルリクエスト
    9.3　まとめ

第II部　持続可能性

10章　コードの増大
    10.1　フィーチャーフラグ
        10.1.1　カレンダーフラグ
    10.2　ストラングラーパターン
        10.2.1　メソッドレベルストラングラー
        10.2.2　クラスレベルストラングラー
    10.3　バージョニング
        10.3.1　事前警告
    10.4　まとめ

11章　ユニットテストを編集する
    11.1　ユニットテストのリファクタリング
        11.1.1　セーフティネットの変更
        11.1.2　新しいテストコードの追加
        11.1.3　テストとプロダクションコードを別々にリファクタリングする
    11.2　テストの失敗を確認する
    11.3　まとめ

12章　トラブルシューティング
    12.1　理解
        12.1.1　科学的手法
        12.1.2　シンプルさ
        12.1.3　ラバーダッキング
    12.2　欠陥
        12.2.1　欠陥をテストとして再現する
        12.2.2　スローテスト
        12.2.3　非決定論的欠陥
    12.3　二分法
        12.3.1　Git による二分法
    12.4　まとめ

13章　関心事の分離
    13.1　合成
        13.1.1　ネストした合成
        13.1.2　逐次合成
        13.1.3　参照透明性
    13.2　横断的関心事
        13.2.1　ロギング
        13.2.2　デコレーター
        13.2.3　何をログに出力するか
    13.3　まとめ

14章　リズム
    14.1　個人のリズム
        14.1.1　タイムボックス
        14.1.2　休憩を取る
        14.1.3　意識して時間を使う
        14.1.4　タッチタイプ
    14.2　チームのリズム
        14.2.1　定期的に依存を更新する
        14.2.2　他のことも予定を入れる
        14.2.3　コンウェイの法則
    14.3　まとめ

15章　いつもの顔ぶれ
    15.1　パフォーマンス
        15.1.1　過去の遺物
        15.1.2　視認性
    15.2　セキュリティ
        15.2.1　STRIDE
        15.2.2　なりすまし
        15.2.3　改ざん
        15.2.4　否認
        15.2.5　情報漏えい
        15.2.6　サービス妨害
        15.2.7　権限昇格
    15.3　その他のテクニック
        15.3.1　プロパティベーステスト
        15.3.2　行動コード解析
    15.4　まとめ

16章　ツアー
    16.1　ナビゲーション
        16.1.1　全体像を見る
        16.1.2　ファイル構成
        16.1.3　詳細を見つける
    16.2　アーキテクチャー
        16.2.1　モノリス
        16.2.2　循環参照
    16.3　使ってみる
        16.3.1　テストから学ぶ
        16.3.2　テストの声を聞く
    16.4　まとめ

付録A　プラクティス一覧
    A.1　50/72ルール
    A.2　80/24ルール
    A.3　Arrange-Act-Assert
    A.4　二分法
    A.5　新しいコードベースのためのチェックリスト
    A.6　コマンドクエリ分離
    A.7　変数を数える
    A.8　サイクロマティック複雑度
    A.9　横断的関心事のためのデコレーター
    A.10　悪魔の代弁者
    A.11　フィーチャーフラグ
    A.12　関数型コア・命令型シェル
    A.13　コミュニケーション階層
    A.14　ルールの例外を正当化する
    A.15　検証せずにパースする
    A.16　ポステルの法則
    A.17　レッド/グリーン/リファクタリング
    A.18　依存関係を定期的に更新する
    A.19　欠陥をテストとして再現する
    A.20　コードをレビューする
    A.21　セマンティックバージョニング
    A.22　テストとプロダクションコードを別々にリファクタリングする
    A.23　スライス
    A.24　ストラングラー
    A.25　脅威モデル
    A.26　変換の優先順位
    A.27　X駆動開発
    A.28　名前をXで置き換える

付録B　参考文献

訳者あとがき
索引

コラム目次
    デプロイパイプラインを確立するときによくある課題
    null許容参照型
    ArgumentNullExceptionがNullReferenceExceptionよりも優れている理由は？
    テスト駆動開発のサイエンス
    契約による設計
    ポステルの法則
    昇順に数値表現を書く
    Maybe
    適切な文章
    機動性
    バス係数