はじめに
コードを書くだけではなくて、開発周辺の知識を得るために読みました。
個人的に参考になった部分をメモしていきます。2，4，6，などの番号は本書の目次番号です。
第1章 コード実装
2 関数名ではより具体的な意味の英単語を使おう
→ 参考：プログラマのためのネーミング辞書 https://codic.jp/
4 副作用のない関数にまとめる
→ 副作用とはデータが更新されることを意味する。
更新系の関数でない(例えば正しいタイトルか確認する)関数ならば値を更新させないこと。
6 リストや辞書をデフォルト引数にしない
→ その関数が使いにくくなるので、引数は単純な値にしたほうがよい。
8 インデックス番号に意味を持たせない
→ コードが読みにくくなる。
10 コメントには「なぜ」を書く
→ 仕様はコードを読めばわかる。また、なぜこう処理しないのかを書いてもよい。
14 別メソッドに値を渡すためだけに属性を設定しない
→ 考えることや覚えることを減らせる。
16 utils.pyのような汎用的な名前を避ける
→ クラスの意味を明確にする。
19 テストにテスト対象と同等の実装を書かない
→ テストが同じ結果になる。文字列や数値はテスト内に直接書く。
21 テストケースは準備、実行、検証に分割しよう
→ テストコードを読みやすくするため。（Arrange Act Assertパターンとも)
23 テストから外部環境への依存を排除しよう
→ 処理が遅い上にデータが残ってしまう。
26 テストケース毎にテストデータを用意する
→ データの使いまわしは意図しないテストの失敗を招く。
31 過剰なmockを避ける
→ 単純なデータで確認できるならmockは使わない。
34 一度に実装する範囲を小さくしよう
→ 困難は分割せよ。
44 レビュー時間をあらかじめ見積もりに含めよう
→ 実装時間の2割をめどに。
第2章 モデル設計
46 マスターデータとトランザクションデータを分けよう
→ マスターデータ・・・基礎となるデータ。商品情報や従業員情報など。
トランザクションデータ・・・履歴となるデータ。購買履歴や給与支払い履歴など。
48 クエリで使いやすいテーブル設計をする
→ 正規化しすぎるとJOINしなければならず、性能が落ちてしまう。
50 一意制約をつける
→ 想定しないデータを入れないため。
51 参照頻度が低いカラムはテーブルを分ける
→ テーブルの肥大化を防げる。
56 有意コードをなるべく定義しない
→ 有意コード・・・FD10001のようなFDが区分で10001が番号のようなコード。
like検索は遅いのでなるべく使いたくない。
58 DBのスキーママイグレーションとデータマイグレーションを分ける
→ マイグレーションは「移行」の意。
どこかで処理が失敗した場合に原因の切り分けが難しくなる。
第3章 エラー設計
64 例外を握り潰さない
→ 例外をなかったことにして処理を続けてもどのみちどこかで処理が止まる。
71 info、errorだけでなくログレベルを使い分ける
→ debug・・・ローカルでのみ出力
info・・・挙動確認に必要な情報
74 ログファイルを管理する
→ Unix系であれば/var/log以下にログを集約する。
また、ログローテーションしてログを一定期間で圧縮する。
75 Sentryでエラーログを通知/監視する
→ Sentryというエラートラッキングサイトがある。 https://sentry.io/welcome/
第4章 システム設計
79 本番環境はシンプルな仕組みで構築する
→ 便利さを求めて多機能なツールを使うと、仕組みが複雑化して運用コストがあがる。
89 ファイルをCDNから配信する
→ CDN(Contents Delivery Network)・・・静的コンテンツを素早く配信してくれるサービスのこと。
主に、AWS CloudFrontやGCP Cloud CDNなどがある。
91 時間のかかる処理は非同期化しよう
→ リアルタイム処理が必要ない場合(メール配信等)は非同期処理する。
93 サービスマネージャーでプロセスを管理する
→ LinuxであればSystemdで管理。
94 デーモンは自動で起動させよう
→ Linuxであればsystemctlで自動機能の設定を。
97 バージョンをいつ上げるのか
→ こまめに上げることで大幅な改修を減らす。
100 ファイルパスはプログラムからの相対パスで組み立てよう
→ どこからプログラムが実行されても動くようにするため。
103 一時的な作業ファイルには絶対に競合しない名前を使う
→ タイムスタンプでは競合する場合があるためツールを使うのが吉。
105 127.0.0.1と0.0.0.0の違い
→ 127.0.0.1はローカルループバックアドレス。そのコンピュータ内のみアクセス可。
0.0.0.0はすべてのネットワークにバインドできる特別なIP。
107 リバースプロキシ
→ ApacheやNginxなどを設置。
リクエストを一旦経由させてサーバ負荷を下げたり、攻撃を軽減できる。
第5章 やることの明確化
112 作りたい価値から考える
→ 作ったあとに必要ないと気づく確率を減らす。
参考図書：匠メソッド、リーン顧客開発、ストーリーとしての競争戦略
118 モックアップから実装までをイメージしよう
→ 実装がイメージできないときは仕様を確認する。
119 最小で実用できる部分から作ろう
→ 最小の完成形を見つければモチベーションを維持できる。
120 ストーリーが満たせるかレビューしよう
→ モックアップが一通り揃った段階で再度レビューする。
感想
ソフトウェア開発の経験が浅い人は1章から順番に読めばよいし、
コードは書けるけど設計が微妙という人は5章から読めばよく、
読み手のことを考えた構成で素晴らしいと思いました。
Python特有の話はあるものの、基本的には他の言語にも応用可能です。
ソフトウェア開発の全体像を捉えたい人には最適の一冊ではないでしょうか。
『自走プログラマー ～Pythonの先輩が教えるプロジェクト開発のベストプラクティス120』
https://gihyo.jp/book/2020/978-4-297-11197-7