自走プログラマー―Pythonの先輩が教えるプロジェクト開発のベストプラクティス120 [単行本]

自走プログラマー―Pythonの先輩が教えるプロジェクト開発のベストプラクティス120 の 商品概要

• 要旨（「BOOK」データベースより）

  開発の着実なプロセスが身につく。作りたいものを設計できる。エラーやトラブルに対応できる。プログラミング能力を活かして価値を生み出すための「ソフトウェア開発の地図」。自走できるプログラマーであれば知っているであろういろいろな手法や観点を元に、「プロジェクトの各段階でプログラマーがやること」「その選択をどう判断するのか」「どうコードを実装して実現していくのか」を紹介。一部の最新技術に注目するのではなく、実際のプロジェクトに適用して、プロジェクトを完成させるための指針をまとめた。

• 目次

  ■■まえがき
  
  ■■■第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を使用していますが、ほかのプログラム言語でも共通する知識が満載。より効率的かつ効果的にプログラムを書ける「自走できるプログラマー」へ導きます。

• 著者紹介（「BOOK著者紹介情報」より）（本データはこの書籍が刊行された当時に掲載されていたものです）

  清水川 貴之(シミズカワ タカユキ)
  一般社団法人ＰｙＣｏｎ　ＪＰの理事としてＰｙｔｈｏｎ　Ｂｏｏｔ　ＣａｍｐでＰｙｔｈｏｎ講師を務め、Ｐｙｔｈｏｎ関連書籍の執筆や研修講師も行っている
  
  清原 弘貴(キヨハラ ヒロキ)
  ２０１２年１０月よりＢｅＰｒｏｕｄ所属
  
  tell-k(テルケー)
  ２００５年からＷｅｂアプリケーション開発の仕事に従事

• 著者について

  清水川 貴之 (シミズカワ タカユキ)
  ●清水川 貴之（しみずかわ たかゆき）2003年からPythonを主言語として使い始め、Webアプリケーションの開発を中心に活用してきた。現職のビープラウドでは開発の他、Python関連書籍の執筆や研修講師も行っている。個人では、一般社団法人PyCon JPの理事として日本各地で開催されているPython Boot CampでPython講師を務めている。Python mini Hack-a-thonなどPython関連イベント運営のかたわら、国内外のカンファレンスへ登壇しPython技術情報を発信するなど、公私ともにPythonとその関連技術の普及活動を行っている。共著書／共訳書：『Pythonプロフェッショナルプログラミング第3版（2018 秀和システム刊）』『エキスパートPythonプログラミング改訂2版（2018アスキードワンゴ刊）』『独学プログラマー（2018 日経BP 社刊）』『Sphinxをはじめよう第2版（2017 オライリー・ジャパン刊）』Twitter @shimizukawaURL http://清水川.jp/
  
  清原 弘貴 (キヨハラ ヒロキ)
  ●清原 弘貴（きよはら ひろき）2012年10月よりBeProud所属。2011年から本格的にPythonを使っている。Djangoが好きで、日本で最大級のDjangoイベントDjangoCongress JP（https://djangocongress.jp）の主催をしたり、Webアプリケーションやライブラリを作ったり、Django本体のソースコードへパッチを送ったりしている。個人でShodo（https://shodo.ink）、dig-en（https://dig-en.com）、PileMd（https://pilemd.com）、仕事でPyQ（https://pyq.jp）など、多数のWebサービス・アプリを企画、開発している。共著書に『Pythonプロフェッショナルプログラミング第3版（2018 秀和システム刊）』『Pythonエンジニアファーストブック（2017 技術評論社刊）』がある。Twitter @hirokikyURL http://hirokiky.org/
  
  tell-k（著）　株式会社ビープラウド（監修） (テルケー カブシキガイシャビープラウド)
  ●tell-k（てるけー）2005年からPHP／Perlを利用したWebアプリケーション開発の仕事に従事し、2011年から本格的に仕事でPythonを使い始めた。最近はもっぱらお猫様のお世話に忙しい。共著書に『Pythonプロフェッショナルプログラミング第3版（2018秀和システム刊）』がある。Twitter @tell_kGitHub https://github.com/tell-k

自走プログラマー―Pythonの先輩が教えるプロジェクト開発のベストプラクティス120 の商品スペック