自走プログラマー ～Pythonの先輩が教えるプロジェクト開発のベストプラクティス120（技術評論社） [電子書籍]

自走プログラマー ～Pythonの先輩が教えるプロジェクト開発のベストプラクティス120（技術評論社） の 商品概要

• 「初心者本はひととおり読んだけれど，次に何をしてよいかわからない」
  「簡単なコードは書けるけれど，中規模システムは作れない」
  本書は，そんなプログラミング迷子が設計からコードまで書けるスキルを身につけるための指南書です。
  開発現場で起こった実際の問題とその解決法をもとに，文法以外に必要な「プロジェクトの各段階でプログラマーがやること」「その選択をどう判断するのか」「どうコードを実装して実現していくのか」を解説します。コードにはPythonを使用していますが，ほかのプログラム言語でも共通する知識が満載。より効率的かつ効果的にプログラムを書ける「自走できるプログラマー」へ導きます。
  

• 目次

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

自走プログラマー ～Pythonの先輩が教えるプロジェクト開発のベストプラクティス120（技術評論社） の商品スペック