まえがき

第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　ストーリーが満たせるかレビューしよう

参考文献

索引