自走プログラマー（株式会社ビープラウド, 清水川貴之, 清原弘貴, tell-k）
書籍情報
- 著者:株式会社ビープラウド(監修), 清水川貴之(著), 清原弘貴(著), tell-k(著)
- 発行日:2020-02-27
- ISBN:9784297111977
- URL:https://gihyo.jp/book/2020/978-4-297-11197-7
書籍目次
- まえがき
- 第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 ちょっとした修正のつもりでコードを際限なく書き換えてしまう
- 1.1 関数設計
- 第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を組み立てる
- 2.1 データ設計
- 第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 ソースコードの更新が確実に動作に反映される工夫をしよう
- 3.1 エラーハンドリング
- 第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アドレスにアクセスする
- 4.1 プロジェクト構成
- 第5章 やることの明確化
- 5.1 要件定義
- 111 いきなり作り始めてはいけない
- 112 作りたい価値から考える
- 113 100％の要件定義を目指さない
- 5.2 画面モックアップ
- 114 文字だけで伝えず，画像や画面で伝える
- 115 モックアップは完成させよう
- 116 遷移，入力，表示に注目しよう
- 117 コアになる画面から書こう
- 118 モックアップから実装までをイメージしよう
- 119 最小で実用できる部分から作ろう
- 120 ストーリーが満たせるかレビューしよう
- 5.1 要件定義
- 参考文献
- 索引