■■まえがき
■■■第1章 コード実装
■■1.1 関数設計
■1 関数名は処理内容を想像できる名前にする
■2 関数名ではより具体的な意味の英単語を使おう
■3 関数名から想像できる型の戻り値を返す
■4 副作用のない関数にまとめる
■5 意味づけできるまとまりで関数化する
■6 リストや辞書をデフォルト引数にしない
■7 コレクションを引数にせずintやstrを受け取る
■8 インデックス番号に意味を持たせない
■9 関数の引数に可変長引数を乱用しない
■10 コメントには「なぜ」を書く
■11 コントローラーには処理を書かない
■■1.2 クラス設計
■12 辞書でなくクラスを定義する
■13 dataclassを使う
■14 別メソッドに値を渡すためだけに属性を設定しない
■15 インスタンスを作る関数をクラスメソッドにする
■■1.3 モジュール設計
■16 utils.pyのような汎用的な名前を避ける
■17 ビジネスロジックをモジュールに分割する
■18 モジュール名のオススメ集
■■1.4 ユニットテスト
■19 テストにテスト対象と同等の実装を書かない
■20 1つのテストメソッドでは1つの項目のみ確認する
■21 テストケースは準備、実行、検証に分割しよう
■22 単体テストをする観点から実装の設計を洗練させる
■23 テストから外部環境への依存を排除しよう
■24 テスト用のデータはテスト後に削除しよう
■25 テストユーティリティーを活用する
■26 テストケース毎にテストデータを用意する
■27 必要十分なテストデータを用意する
■28 テストの実行順序に依存しないテストを書く
■29 返り値がリストの関数のテストで要素数をテストする
■30 テストで確認する内容に関係するデータのみ作成する
■31 過剰なmockを避ける
■32 カバレッジだけでなく重要な処理は条件網羅をする
■■1.5 実装の進め方
■33 公式ドキュメントを読もう
■34 一度に実装する範囲を小さくしよう
■35 基本的な機能だけ実装してレビューしよう
■36 実装方針を相談しよう
■37 実装予定箇所にコメントを入れた時点でレビューしよう
■38 必要十分なコードにする
■39 開発アーキテクチャドキュメント
■■1.6 レビュー
■40 PRの差分にレビューアー向け説明を書こう
■41 PRに不要な差分を持たせないようにしよう
■42 レビューアーはレビューの根拠を明示しよう
■43 レビューのチェックリストを作ろう
■44 レビュー時間をあらかじめ見積もりに含めよう
■45 ちょっとした修正のつもりでコードを際限なく書き換えてしまう
■■■第2章 モデル設計
■■2.1 データ設計
■46 マスターデータとトランザクションデータを分けよう
■47 トランザクションデータは正確に記録しよう
■48 クエリで使いやすいテーブル設計をする
■■2.2 テーブル定義
■49 NULLをなるべく避ける
■50 一意制約をつける
■51 参照頻度が低いカラムはテーブルを分ける
■52 予備カラムを用意しない
■53 ブール値でなく日時にする
■54 データはなるべく物理削除をする
■55 typeカラムを神格化しない
■56 有意コードをなるべく定義しない
■57 カラム名を統一する
■■2.3 Django ORMとの付き合い方
■58 DBのスキーママイグレーションとデータマイグレーションを分ける
■59 データマイグレーションはロールバックも実装する
■60 Django ORMでどんなSQLが発行されているか気にしよう
■61 ORMのN＋1問題を回避しよう
■62 SQLから逆算してDjango ORMを組み立てる
■■■第3章 エラー設計
■■3.1 エラーハンドリング
■63 臆さずにエラーを発生させる
■64 例外を握り潰さない
■65 try節は短く書く
■66 専用の例外クラスでエラー原因を明示する
■■3.2 ロギング
■67 トラブル解決に役立つログを出力しよう
■68 ログがどこに出ているか確認しよう
■69 ログメッセージをフォーマットしてロガーに渡さない
■70 個別の名前でロガーを作らない
■71 info、errorだけでなくログレベルを使い分ける
■72 ログにはprintでなくloggerを使う
■73 ログには5W1Hを書く
■74 ログファイルを管理する
■75 Sentryでエラーログを通知／監視する
■■3.3 トラブルシューティング・デバッグ
■76 シンプルに実装しパフォーマンスを計測して改善しよう
■77 トランザクション内はなるべく短い時間で処理する
■78 ソースコードの更新が確実に動作に反映される工夫をしよう
■■■第4章 システム設計
■■4.1 プロジェクト構成
■79 本番環境はシンプルな仕組みで構築する
■80 OSが提供するPythonを使う
■81 OS標準以外のPythonを使う
■82 Docker公式のPythonを使う
■83 Pythonの仮想環境を使う
■84 リポジトリのルートディレクトリはシンプルに構成する
■85 設定ファイルを環境別に分割する
■86 状況依存の設定を環境変数に分離する
■87 設定ファイルもバージョン管理しよう
■■4.2 サーバー構成
■88 共有ストレージを用意しよう
■89 ファイルをCDNから配信する
■90 KVS（Key Value Store）を利用しよう
■91 時間のかかる処理は非同期化しよう
■92 タスク非同期処理
■■4.3 プロセス設計
■93 サービスマネージャーでプロセスを管理する
■94 デーモンは自動で起動させよう
■95 Celeryのタスクにはプリミティブなデータを渡そう
■■4.4 ライブラリ
■96 要件から適切なライブラリを選ぼう
■97 バージョンをいつ上げるのか
■98 フレームワークを使おう（巨人の肩の上に乗ろう）
■99 フレームワークの機能を知ろう
■■4.5 リソース設計
■100 ファイルパスはプログラムからの相対パスで組み立てよう
■101 ファイルを格納するディレクトリを分散させる
■102 一時的な作業ファイルは一時ファイル置き場に作成する
■103 一時的な作業ファイルには絶対に競合しない名前を使う
■104 セッションデータの保存にはRDBかKVSを使おう
■■4.6 ネットワーク
■105 127.0.0.1と0.0.0.0の違い
■106 ssh port forwardingによるリモートサーバーアクセス
■107 リバースプロキシ
■108 Unixドメインソケットによるリバースプロキシ接続
■109 不正なドメイン名でのアクセスを拒否する
■110 hostsファイルを変更してドメイン登録と異なるIPアドレスにアクセスする
■■■第5章 やることの明確化
■■5.1 要件定義
■111 いきなり作り始めてはいけない
■112 作りたい価値から考える
■113 100％の要件定義を目指さない
■■5.2 画面モックアップ
■114 文字だけで伝えず、画像や画面で伝える
■115 モックアップは完成させよう
■116 遷移、入力、表示に注目しよう
■117 コアになる画面から書こう
■118 モックアップから実装までをイメージしよう
■119 最小で実用できる部分から作ろう
■120 ストーリーが満たせるかレビューしよう
■■参考文献
■■索引
