generated at
自走プログラマー

基本情報
書籍名: 自走プログラマー ~Pythonの先輩が教えるプロジェクト開発のベストプラクティス120
出版社: 技術評論社
ページ数: 288
金額: 2980円+税
発売時期: 2020/2/27
カテゴリ: #Python / #Web技術 / #指南書
Amazonリンク: https://amzn.to/3aNzcN1

ステータス

本の概要
(書籍前書きより)
> 本書は、「プログラミング入門者が中級者にランクアップ」するのに必要な知識をお伝えする本です。扱っている120のトピックは、実際の現場で起こった問題とその解決方法を元に執筆しています。このため、扱っているプロジェクトの規模や、失敗パターンのレベル感もさまざまです。各トピックでは具体的な問題とベストプラクティス、なぜそれがベストなのかを解説します。
> 本書は、プログラミング言語Pythonを使って設計や開発プロセスのベストプラクティスを紹介します。Pythonにくわしくない方でも、プログラミング言語の文法を知っている方であれば理解できるようにしています。逆に、プログラミング自体が何かわからない人のための本ではありません。すでにプログラミング言語の文法や書き方、役割を知っている人が、より効率的かつ効果的にプログラムを書く、価値を創る方法をお伝えする本です。

お勧めの読者
(書籍前書きより)
チョットした便利なコードを書けるけど、中〜大規模のシステムを上手に作れない人
プログラムを書けるけど、レビュー指摘などで手戻りが多い人
優れたエンジニアになりたい人
PythonでWebアプリケーションの開発をするときの指針が欲しい人
Python入門を果たしたプログラマーで、仕事でPythonをやっていこうという人
設計の仕方や、メンテナンス性の高いプログラムの書き方を知りたい人
ライブラリの選定を、確信を持ってできるようになりたい人

shimizukawa一言で言うと:
Python入門者から中級者になりたい人

対象としていない読者:
プログラミング入門、Python入門、科学計算、スクレイピング、機械学習、を学びたい
直接的な答えだけ欲しい人

この本を書いた目的
プログラミングの守破離のうち、 をまとめて伝えたい。
BeProudで中心的に活動しているメンバーは、各種公式ドキュメントや過去の経験で守の知識を持っている
各プロジェクトでは、 を実践しつつ、必要に応じてを交えているが、チーム開発では、 はあまりやらない。
新メンバー(rookie)が開発プロジェクトに参加すると、 がまだ身についていない状態で、 を実践しないといけない状態になり、混乱してしまう。
こういった状況を打開するべく、本書ではBeProudをまとめました。

執筆の想い
> 私たちにとってプログラマーとは,設計書をコードにする単純作業者のことではなく,やりたいことをまとめ,設計からコードにし,そしてリリースするまでをすべて1人でできる人のことを指しています。本当にすばらしいサービスやアプリケーションをつくり出すには,自走できるプログラマーが必要です。
> とはいえ,すべてのプログラマーがはじめから自走できたわけではなく,組織のメンバーは常に入れ替わっていき,新しく参加するメンバーの中にはこれからいろいろなことを学んでいく人もいます。それは,技術的なつまづきと学びを繰り返して,その背景にある原理原則をメンバーそれぞれが見つけていく,長い旅のようなものです。ビープラウドには,この学びの旅をサポートする「教え合う文化」が根づいており,つまづいたときには先輩が親身になって助けてくれます。そこで先輩達が教えてきた履歴を見ると,新しいメンバーがなぜか必ずつまづいてしまうパターンがいくつもあることがわかってきました。こういった,設計からコードまで書けるようになるために知っておいてほしい技術的なトピックを集め,この本にまとめました。
> 本書は,プログラミング入門ならぬ,脱入門者を目指す開発者向けの指南書です。自走できるプログラマーであれば知っているであろういろいろな手法や観点を元に,「プロジェクトの各段階でプログラマーがやること」「その選択をどう判断するのか」「どうコードを実装して実現していくのか」を紹介します。一部の最新技術に注目するのではなく,実際のプロジェクトに適用して,プロジェクトを完成させるための指針をまとめました。


著者・関係者による紹介blog
>この本は著者陣が仕事の中で他の人に教えたことを中心に執筆しています。 たとえばコードレビューや、社内でのサポート、社内外の研修、コンサルティングの中で伝えてきたことをまとめています。 ビープラウド社内のメンバーも積極的にレビュー、コメントしてくれて、社内のかなりのノウハウが取り込まれています。
> 執筆に際しては社内で半年から1年をかけてネタを集めて、選別する時間を設けました。 著者の3人が日々の業務で伝えたことや感じたこと、過去に社内で伝えたことをネタ帳として集めてから執筆しています。 たとえば「ログには5W1Hを書こう」という僕が執筆を担当したプラクティスがあるのですが、これは5年前(2015年)から社内では共有していた知識です。これは社内でも好評で、「ロギングって大事だけど、何を書くべきかを学べる場所がなかった」とフィードバックを受けていました。 そのノウハウがやっと日の目を見ることになって、僕個人としてはとても嬉しいです。こんなにうれしいことはない。。

> 「理由を考えるための設計・実装の選択肢」が、前書きに書かれている「プログラミング入門者が中級者にランクアップするのに必要な知識」の本質
> 中級以上のプログラマーが、日々どのようなことにこだわり、思考を積み上げているかを知ることもできるでしょう(中にはそこまで考える必要あるの?というものもあるでしょう)


章構成と執筆担当

chapter-and-author
#タイトル著者
1.1. 関数設計1関数名は処理内容を想像できる名前にするhirokiky
2関数名ではより具体的な意味の英単語を使おうhirokiky
3関数名から想像できる型の戻り値を返すhirokiky
4副作用のない関数にまとめるhirokiky
5意味づけできるまとまりで関数化するhirokiky
6リストや辞書をデフォルト引数にしないhirokiky
7コレクションを引数にせずでintやstrを受け取るhirokiky
8インデックス番号に意味を持たせないhirokiky
9関数の引数に可変長引数を乱用しないhirokiky
10コメントには「なぜ」を書くhirokiky
11コントローラーには処理を書かないhirokiky
1.2. クラス設計12辞書でなくクラスを定義するhirokiky
13dataclassを使うhirokiky
14別メソッドに値を渡すためだけに属性を設定しないhirokiky
15インスタンスを作る関数をクラスメソッドにするhirokiky
1.3. モジュール設計16utils.pyのような汎用的な名前を避けるhirokiky
17ビジネスロジックをモジュールに分割するhirokiky
18モジュール名のオススメ集hirokiky
1.4. ユニットテスト19テストにテスト対象と同等の実装を書かないhirokiky
201つのテストメソッドで1つの項目のみ確認するhirokiky
21テストケースは準備、実行、検証に分割しようtell-k
22単体テストをする観点から実装の設計を洗練させるhirokiky
23テストから外部環境への依存を排除しようhirokiky
24テスト用のデータはテスト後に削除しようtell-k
25テストユーティリティーを活用するhirokiky
26テストケース毎にテストデータを用意するtell-k
27必要十分なテストデータを用意するtell-k
28テストの実行順序に依存しないテストを書くhirokiky
29返り値がリストの関数のテストで要素数をテストするhirokiky
30テストで確認する内容に関係するデータのみ作成するhirokiky
31過剰なmockを避けるhirokiky
32カバレッジだけでなく重要な処理は条件網羅をするhirokiky
1.5. 実装の進め方33公式ドキュメントを読もうshimizukawa
34一度に実装する範囲を小さくしようshimizukawa
35基本的な機能だけ実装してレビューしようshimizukawa
36実装方針を相談しようtell-k
37実装予定箇所にコメントを入れた時点でレビューしようshimizukawa
38必要十分なコードにするtell-k
39開発アーキテクチャドキュメントshimizukawa
1.6. レビュー40PRの差分にレビューアー向け説明を書こうshimizukawa
41PRに不要な差分を持たせないようにしようshimizukawa
42レビューアーはレビューの根拠を明示しようshimizukawa
43レビューのチェックリストを作ろうshimizukawa
44レビュー時間をあらかじめ見積に含めようshimizukawa
45ちょっとした修正のつもりでコードを際限なく書き換えてしまうshimizukawa
2.1. データ設計46マスターデータとトランザクションデータを分けようtell-k
47トランザクションデータは正確に記録しようtell-k
48クエリで使いやすいテーブル設計をするtell-k
2.2. テーブル定義49NULLをなるべく避けるhirokiky
50一意制約をつけるhirokiky
51参照頻度が低いカラムはテーブルを分けるhirokiky
52予備カラムを用意しないhirokiky
53ブール値でなく日時にするhirokiky
54データはなるべく物理削除をするhirokiky
55typeカラムを神格化しないhirokiky
56有意コードをなるべく定義しないhirokiky
57カラム名を統一するhirokiky
2.3. Django ORMとの付き合い方58DBのスキーママイグレーションとデータマイグレーションを分けるshimizukawa
59データマイグレーションはロールバックも実装するshimizukawa
60Django ORMでどんなSQLが発行されてるか気にしようshimizukawa
61ORMのN+1問題を回避しようshimizukawa
62SQLから逆算してDjango ORMを組み立てるshimizukawa
3.1. エラーハンドリング63臆さずにエラーを発生させるshimizukawa
64例外を握り潰さないshimizukawa
65try節は短く書くshimizukawa
66専用の例外クラスでエラー原因を明示するshimizukawa
3.2. ロギング67トラブル解決に役立つログを出力しようshimizukawa
68ログがどこに出ているか確認しようshimizukawa
69ログメッセージをフォーマットしてロガーに渡さないhirokiky
70個別の名前でロガーを作らないhirokiky
71info、errorだけでなくログレベルを使い分けるhirokiky
72ログにはprintでなくloggerを使うhirokiky
73ログには5W1Hを書くhirokiky
74ログファイルを管理するtell-k
75Sentry でエラーログを通知/監視するshimizukawa
3.3. トラブルシューティング・デバッグ76シンプルに実装しパフォーマンスを計測して改善しようshimizukawa
77トランザクション内はなるべく短い時間で処理するshimizukawa
78ソースコードの更新が確実に動作に反映される工夫をしようshimizukawa
4.1. プロジェクト構成79本番環境はシンプルな仕組みで構築するshimizukawa
80OSが提供するPythonを使うshimizukawa
81OS標準以外のPythonを使うshimizukawa
82Docker公式のPythonを使うshimizukawa
83Pythonの仮想環境を使うshimizukawa
84リポジトリのルートディレクトリはシンプルに構成するshimizukawa
85設定ファイルを環境別に分割するshimizukawa
86状況依存の設定を環境変数に分離するshimizukawa
87設定ファイルもバージョン管理しようtell-k
4.2. サーバー構成88共有ストレージを用意しようtell-k
89ファイルをCDNから配信するtell-k
90KVS(Key Value Store)を利用しようtell-k
91時間の掛かる処理は非同期化しようtell-k
92タスク非同期処理shimizukawa
4.3. プロセス設計93サービスマネージャーでプロセスを管理するshimizukawa
94デーモンは自動で起動させようtell-k
95Celeryのタスクにはプリミティブなデータを渡そうtell-k
4.4. ライブラリ96要件から適切なライブラリを選ぼうtell-k
97バージョンをいつ上げるのかshimizukawa
98フレームワークを使おう(巨人の肩の上に乗ろう)shimizukawa
99フレームワークの機能を知ろうshimizukawa
4.5. リソース設計100ファイルパスはプログラムからの相対パスで組み立てようtell-k
101ファイルを格納するディレクトリを分散させるshimizukawa
102一時的な作業ファイルは一時ファイル置き場に作成するshimizukawa
103一時的な作業ファイルには絶対に競合しない名前を使うshimizukawa
104セッションデータの保存にはRDBかKVSを使おうshimizukawa
4.6. ネットワーク105127.0.0.1と0.0.0.0の違いshimizukawa
106ssh port forwardingによるリモートサーバーアクセスshimizukawa
107リバースプロキシshimizukawa
108Unixドメインソケットによるリバースプロキシ接続shimizukawa
109不正なドメイン名でのアクセスを拒否するshimizukawa
110hostsファイルを変更してドメイン登録と異なるIPアドレスにアクセスするshimizukawa
5.1. 要件定義111いきなり作り始めてはいけないhirokiky
112作りたい価値から考えるhirokiky
113100%の要件定義を目指さないhirokiky
5.2. 画面モック114文字だけで伝えず、画像や画面で伝えるhirokiky
115モックアップは完成させようhirokiky
116遷移、入力、表示に注目しようhirokiky
117コアになる画面から書こうhirokiky
118モックアップから実装までをイメージしようhirokiky
119最小で実用できる部分から作ろうhirokiky
120ストーリーが満たせるかレビューしようhirokiky

扱っている分野

参照しているライブラリ、ミドルウエア、ドキュメント、サービス、ツール
Python公式
logging - Python 用ロギング機能 - Python 3.8.1 ドキュメント https://docs.python.org/ja/3/library/logging.html#logging.Formatter
Logging Flow - Logging HOWTO - Python 3.8.1 ドキュメント https://docs.python.org/ja/3/howto/logging.html#logging-flow
TypedDict仕様提案:PEP-589 https://www.python.org/dev/peps/pep-0589/
ソケットプログラミング HOWTO - Python 3.8.1 ドキュメント https://docs.python.org/ja/3/howto/sockets.html

Django公式

サードパーティーライブラリのドキュメント

パッケージ

ミドルウェア
Docker公式のPython https://hub.docker.com/_/python
名前ベースのバーチャルホスト - Apache https://httpd.apache.org/docs/2.4/ja/vhosts/name-based.html
名前ベースのバーチャルホスト - Nginx http://nginx.org/en/docs/http/request_processing.html
暗黙的なコミットを発生させるステートメント - MySQL https://dev.mysql.com/doc/refman/5.6/ja/implicit-commit.html

サービス
プログラマーのためのネーミング辞書 codic https://codic.jp

デスクトップツール

標準仕様
RFC 7239 - Forwarded HTTP Extension https://tools.ietf.org/html/rfc7239

裏話
英語名は The Self-Propelled Programmer かな
日本語に直訳すると「自走式プログラマー」、なんだかすごそう
あるいは The Self-Driven Programmer 、こっちの方が通りが良さそう
企画開始は 2017/5/23(火)
出版が2020年2月なので、3年弱かかっている
企画開始当初、3年くらいという話をしていたら出版まで本当に3年かかった
じっくり時間をかけて中級向けに役立つ情報をまとめようとした
当初計画では、下書きを書いたら社内で実践してもらってフィードバックを集めようと計画
最後締め切りを区切られてから時間を捻出してまとめた
shimizukawaは締め切りがゆるいとオーバーしちゃうのを再実感
(途中1年ほどかなり厳しいプロジェクトに入っていて、心の余裕もなかった)
やる気になってから非常に濃い密度で進められた
社内Slackの各チャンネルを追って、適用できそうか、できないとしたらなぜかを考えて反映した
書いた内容はGitHubにあるので、社内Slackで必要なシーンを見かけたら伝えた
実践してもらった結果を聞いて、原稿に反映した
先輩T だと思って習ったけど実は Xさん かもしれない(トピック 98)
しかもXさん、意外とTwitterでフォロワー多かったり、コミュニティでなにかしてたりもしそう。
先輩Tさん、猫のツイートしかしてない。
このネタで1講演できるくらいの価値ありそう。

知り合いの感想
terapyon:
買って読みました。けっこう早い段階でDjango前提の話がでてきてそこは読み解きづらかったので飛ばしました。そうやって飛ばしながら読めるのはよかった。全体的には良い内容で、Pythonに特化した感じではなくもっと一般的なことを伝えたいんだなと思いました
aodag:
いいね、ああいいねえ
詳細を読むと、例で説明しきれていない気もするけど、トピックタイトルと要点だけ読んでいくと伝えたいことがよくわかる。毎回説明してたのを本にまとめたんでしょ。

その他、言及等
> 「独学」で始め、「自走」し、「達人」に至るわけですね。
> 最高でした.
> この本を一言で表すなら Pythonのベストプラクティスの結晶 という感じです.
> いや, まじで, やばいです. 普段なら読んだ本から使えそうな部分をメモしてまとめるのですが, この本に紹介されている内容はすべてメモしたくなったし, 全ページ黄色マーカー引きたいし, 自分が困っていた問題にピンポイントに刺さってるのがいくつもあって本当に良かったです.
> この本はたまたま技術評論社のWebサイトで適当に本を探してたら見つけて, 目次見た感じ良さそうだったので買ったのですが, まさかここまで素晴らしくて実用的だとは思いませんでした.
> 読み始めたきっかけとして、自分は機械学習エンジニアとして現在働いているが、できることの幅を広げるために最近はソフトウェアエンジニアとしてのスキルをもっと伸ばしたいと考えている。
> 自走プログラマーは、Pythonを使ったアプリケーション開発のアンチパターンとベストプラクティスを例示して学ぶことができる書籍で、今回の自分の状況にすごくフィットしていて楽しく学習することができた。
>ソフトウェア開発の経験が浅い人は1章から順番に読めばよいし、
> コードは書けるけど設計が微妙という人は5章から読めばよく、
> 読み手のことを考えた構成で素晴らしいと思いました。

> "自走プログラマー"は読みやすい! それ重要です。読みづらい本はどんどん積ん読になってます。 #stapy
> 自走プログラマー読みやすいですよね! #stapy
> ベストプラクティスは必ずしも正解ではないので、読書会で意見交換しあうのがお薦め。なるほど! #stapy
> 「自走プログラマー」のお薦めポイント現場レベルでありそうな知見やサンプルコード。自分事に近い知見は本当ありがたいですよねー #stapy
> 「リアルな開発現場でありそうなソースコード」「先輩と後輩の生々しい会話」 #stapy #自走プログラマー
> 「この後輩説明上手いな」という気付き。ここに気がつくノもすごいなぁ。#stapy
shimizukawa 自走プログラマー 紹介トークありがとうございました!「後輩説明うまいな」からの「こう説明すればいいんだ」という発想は、執筆時には想定してませんでしたw こんど本を紹介する際には使わせてもらいますね #stapy
トーク資料

> こちらの書籍はメインタイトルにもサブタイトルにも「Django」の文字は入っていないんですよね。
> Djangoの学習と並行してPython自体の学習も行っていますので、Djangoはとりあえず置いておいて、Python自体のレベルの底上げに役立つ書籍を探していました。そしてこの本を見つけたのです。
> 「ベストプラクティス120」ということで、いろいろなテーマが扱われていて読みやすそうですので買ってみることにしました。
> そして中身をよくよく読んでみると嬉しい誤算と言うのか、Djangoを題材にしたベストプラクティスがかなり出てくるんですよね。これはほぼDjangoの本なのではないかと錯覚するくらいに。
> それもそのはず、著者をよく見てみると、著者のおふたりはDjangoにもご関係のある方々なのですよね。

shimizukawa 自走プログラマー の内容がSOで質問されていたので回答してみた

>@shinya_hd - 午後7:26 · 2022年8月8日 自走プログラマー。
>個人開発で教えてくれる人いないからこの本はホント役に立つ。
>本番リリースするためにも必要なことがたくさん詰まってる。
>一年くらい寝かしていたけど読み始めてる。

>@rinne_grid - 午前11:09 · 2022年8月13日 自走プログラマーの第1章「コード実装」のところ、読んだ。とても良き。
>・「個人的に無意識にできていること・できてないこと」がそれぞれ明確になる(思わず息を呑むことも)
>・PRによるレビューの経験が少ないので、レビュアーの視点を書いてくれてるのがとても助かる。
>・テストコード書きたい
>@rinne_grid - 午前11:14 · 2022年8月13日 個人(単独)開発だと、どうしても得ることができない知見が纏まっている。
>どういう部分に気をつけてもらいたいか、後輩を指導する時にも利用できそう。
>ただ、本書を読むにあたって、Djangoの基本的な知識が必要な部分がある。

>@rinne_grid - 午後10:06 · 2022年8月23日 自走プログラマーの本、全体的にとても良かった。個人的にはコード実装とエラー設計の章が得るものが多かった。おそらくチームメンバーと一緒にこの本の輪読会するとチームとしてスキルアップに繋がる。
>それにしても、この本に登場する「先輩T」がめっちゃ優しい。悟りでも開いているのだろうか。

>@gologius - 午後11:07 · 2022年10月22日 この本結構よかった。ちょうど中級者~上級者くらいのことが読みやすく書いてあった。

>@touki_1513 - 午後1:43 · 2022年11月4日 「自走プログラマー」は、Python・Django技術者向けだったが、内容は普遍的なコーディング・テスト・DB設計規約のベストプラクティスの話で、とても参考になった。レビューやPR・要件定義にも踏み込んでいて、全部すぐ実践はできなくても、WFの工程別にチームで意識したいと思った。手元に欲しい

>@naoki_maejima - 午後5:19 · 2022年11月13日 『自走プログラマー』に書いてあった「実装予定の箇所にコメントした時点でレビュー依頼する」という指南、とても良いな。今まで適当にオレオレ実装したものでPR投げてたけど、自信ない場合はコメントだけでdiff作ったほうが失われる時間が少ない。

>@kimihito_ - 午前9:41 · 2022年12月12日 Djangoのコードを本格的に書いて1年ほど経って、自走プログラマーを再読したけど学びが多い。抜粋版もあるのいい https://t.co/8hCAVEBdOZ

>@kaeru_nantoka - 午後5:01 · 2022年12月29日 「自走プログラマー」読了。Django による web開発のプロジェクトを題材に、複数のベスプラ・アンチパターンを扱っていてスッと入ってきた。テストとかクラス設計とかの入門に良さそう。(入門できた)

> Python での開発のベストプラクティスが実践に即して学べるいい本でした。
> 個人的には dataclass の使い方やログ、例外のあたりの内容が勉強になりました。

> 1章 これはPython使い全員に有用
> 3章 エラー設計やロギングの話がよかった。基本的で大切なことが書いているので読み直したい。
> よかったところ
> 1,3章あたりはPythonやプログラミングのお作法的なことが学べてよい。またプルリクや設計の初学者があまり触れない話もあり。リーダブルコードが抽象的でよくわからない人にとって良いかも
> 「Pythonを今まで何となく書いてきたけど、業務では全然…」というレベル感の人が読むには最適
> 懸念点
> amazonレビューにもあったが、Web/Djangoをわかっていないのと読みづらい。web系エンジニア向けの内容なので、MLエンジニアには親和性が低い話も多い
> 情報が最新ではないので、頭の中で取捨選択が必要かも
> コードに型アノテーションがついていないことが少し気になる(Pythonのバージョンが低い場合も考慮している?)

> エンジニア転職をした私が、本書のコード実装を読みもう少し早く知っておきたかったことや実際に言われた事等を記載し今後の糧にする。