Amazonへ


(2020/04/04 15:31:10時点)

近くの図書館から探してみよう
カーリルは全国の図書館から本を検索できるサービスです

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

この本を読みたい

現在位置から探す
詳しい情報
読み: ジソウ プログラマー : パイソン ノ センパイ ガ オシエル プロジェクト カイハツ ノ ベスト プラクティス ヒャクニジュウ
出版社: 技術評論社
単行本(ソフトカバー): 288 ページ
ISBN-10: 4297111977  ISBN-13: 9784297111977  [この本のウィジェットを作る]
NDC(9) : 007.63

紹介

「初心者本はひととおり読んだけれど、次に何をしてよいかわからない」
「簡単なコードは書けるけれど、中規模システムは作れない」
本書は、そんなプログラミング迷子が設計からコードまで書けるスキルを身につけるための指南書です。
開発現場で起こった実際の問題とその解決法をもとに、文法以外に必要な「プロジェクトの各段階でプログラマーがやること」「その選択をどう判断するのか」「どうコードを実装して実現していくのか」を解説します。コードには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 ストーリーが満たせるかレビューしよう


■■参考文献

■■索引
powered by openBD
ほかのサービスで見る