自走プログラマー
基本情報
書籍名: 自走プログラマー ~Pythonの先輩が教えるプロジェクト開発のベストプラクティス120
ページ数: 288
金額: 2980円+税
発売時期: 2020/2/27
ステータス
本の概要
(書籍前書きより)
> 本書は、「プログラミング入門者が中級者にランクアップ」するのに必要な知識をお伝えする本です。扱っている120のトピックは、実際の現場で起こった問題とその解決方法を元に執筆しています。このため、扱っているプロジェクトの規模や、失敗パターンのレベル感もさまざまです。各トピックでは具体的な問題とベストプラクティス、なぜそれがベストなのかを解説します。
> 本書は、プログラミング言語Pythonを使って設計や開発プロセスのベストプラクティスを紹介します。Pythonにくわしくない方でも、プログラミング言語の文法を知っている方であれば理解できるようにしています。逆に、プログラミング自体が何かわからない人のための本ではありません。すでにプログラミング言語の文法や書き方、役割を知っている人が、より効率的かつ効果的にプログラムを書く、価値を創る方法をお伝えする本です。
お勧めの読者
(書籍前書きより)
チョットした便利なコードを書けるけど、中〜大規模のシステムを上手に作れない人
プログラムを書けるけど、レビュー指摘などで手戻りが多い人
優れたエンジニアになりたい人
PythonでWebアプリケーションの開発をするときの指針が欲しい人
Python入門を果たしたプログラマーで、仕事でPythonをやっていこうという人
設計の仕方や、メンテナンス性の高いプログラムの書き方を知りたい人
ライブラリの選定を、確信を持ってできるようになりたい人

一言で言うと:
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 |
| 13 | dataclassを使う | hirokiky |
| 14 | 別メソッドに値を渡すためだけに属性を設定しない | hirokiky |
| 15 | インスタンスを作る関数をクラスメソッドにする | hirokiky |
1.3. モジュール設計 | 16 | utils.pyのような汎用的な名前を避ける | hirokiky |
| 17 | ビジネスロジックをモジュールに分割する | hirokiky |
| 18 | モジュール名のオススメ集 | hirokiky |
1.4. ユニットテスト | 19 | テストにテスト対象と同等の実装を書かない | hirokiky |
| 20 | 1つのテストメソッドで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. レビュー | 40 | PRの差分にレビューアー向け説明を書こう | shimizukawa |
| 41 | PRに不要な差分を持たせないようにしよう | shimizukawa |
| 42 | レビューアーはレビューの根拠を明示しよう | shimizukawa |
| 43 | レビューのチェックリストを作ろう | shimizukawa |
| 44 | レビュー時間をあらかじめ見積に含めよう | shimizukawa |
| 45 | ちょっとした修正のつもりでコードを際限なく書き換えてしまう | shimizukawa |
2.1. データ設計 | 46 | マスターデータとトランザクションデータを分けよう | tell-k |
| 47 | トランザクションデータは正確に記録しよう | tell-k |
| 48 | クエリで使いやすいテーブル設計をする | tell-k |
2.2. テーブル定義 | 49 | NULLをなるべく避ける | hirokiky |
| 50 | 一意制約をつける | hirokiky |
| 51 | 参照頻度が低いカラムはテーブルを分ける | hirokiky |
| 52 | 予備カラムを用意しない | hirokiky |
| 53 | ブール値でなく日時にする | hirokiky |
| 54 | データはなるべく物理削除をする | hirokiky |
| 55 | typeカラムを神格化しない | hirokiky |
| 56 | 有意コードをなるべく定義しない | hirokiky |
| 57 | カラム名を統一する | hirokiky |
2.3. Django ORMとの付き合い方 | 58 | DBのスキーママイグレーションとデータマイグレーションを分ける | shimizukawa |
| 59 | データマイグレーションはロールバックも実装する | shimizukawa |
| 60 | Django ORMでどんなSQLが発行されてるか気にしよう | shimizukawa |
| 61 | ORMのN+1問題を回避しよう | shimizukawa |
| 62 | SQLから逆算してDjango ORMを組み立てる | shimizukawa |
3.1. エラーハンドリング | 63 | 臆さずにエラーを発生させる | shimizukawa |
| 64 | 例外を握り潰さない | shimizukawa |
| 65 | try節は短く書く | shimizukawa |
| 66 | 専用の例外クラスでエラー原因を明示する | shimizukawa |
3.2. ロギング | 67 | トラブル解決に役立つログを出力しよう | shimizukawa |
| 68 | ログがどこに出ているか確認しよう | shimizukawa |
| 69 | ログメッセージをフォーマットしてロガーに渡さない | hirokiky |
| 70 | 個別の名前でロガーを作らない | hirokiky |
| 71 | info、errorだけでなくログレベルを使い分ける | hirokiky |
| 72 | ログにはprintでなくloggerを使う | hirokiky |
| 73 | ログには5W1Hを書く | hirokiky |
| 74 | ログファイルを管理する | tell-k |
| 75 | Sentry でエラーログを通知/監視する | shimizukawa |
3.3. トラブルシューティング・デバッグ | 76 | シンプルに実装しパフォーマンスを計測して改善しよう | shimizukawa |
| 77 | トランザクション内はなるべく短い時間で処理する | shimizukawa |
| 78 | ソースコードの更新が確実に動作に反映される工夫をしよう | shimizukawa |
4.1. プロジェクト構成 | 79 | 本番環境はシンプルな仕組みで構築する | shimizukawa |
| 80 | OSが提供するPythonを使う | shimizukawa |
| 81 | OS標準以外のPythonを使う | shimizukawa |
| 82 | Docker公式のPythonを使う | shimizukawa |
| 83 | Pythonの仮想環境を使う | shimizukawa |
| 84 | リポジトリのルートディレクトリはシンプルに構成する | shimizukawa |
| 85 | 設定ファイルを環境別に分割する | shimizukawa |
| 86 | 状況依存の設定を環境変数に分離する | shimizukawa |
| 87 | 設定ファイルもバージョン管理しよう | tell-k |
4.2. サーバー構成 | 88 | 共有ストレージを用意しよう | tell-k |
| 89 | ファイルをCDNから配信する | tell-k |
| 90 | KVS(Key Value Store)を利用しよう | tell-k |
| 91 | 時間の掛かる処理は非同期化しよう | tell-k |
| 92 | タスク非同期処理 | shimizukawa |
4.3. プロセス設計 | 93 | サービスマネージャーでプロセスを管理する | shimizukawa |
| 94 | デーモンは自動で起動させよう | tell-k |
| 95 | Celeryのタスクにはプリミティブなデータを渡そう | 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. ネットワーク | 105 | 127.0.0.1と0.0.0.0の違い | shimizukawa |
| 106 | ssh port forwardingによるリモートサーバーアクセス | shimizukawa |
| 107 | リバースプロキシ | shimizukawa |
| 108 | Unixドメインソケットによるリバースプロキシ接続 | shimizukawa |
| 109 | 不正なドメイン名でのアクセスを拒否する | shimizukawa |
| 110 | hostsファイルを変更してドメイン登録と異なるIPアドレスにアクセスする | shimizukawa |
5.1. 要件定義 | 111 | いきなり作り始めてはいけない | hirokiky |
| 112 | 作りたい価値から考える | hirokiky |
| 113 | 100%の要件定義を目指さない | hirokiky |
5.2. 画面モック | 114 | 文字だけで伝えず、画像や画面で伝える | hirokiky |
| 115 | モックアップは完成させよう | hirokiky |
| 116 | 遷移、入力、表示に注目しよう | hirokiky |
| 117 | コアになる画面から書こう | hirokiky |
| 118 | モックアップから実装までをイメージしよう | hirokiky |
| 119 | 最小で実用できる部分から作ろう | hirokiky |
| 120 | ストーリーが満たせるかレビューしよう | hirokiky |
扱っている分野
参照しているライブラリ、ミドルウエア、ドキュメント、サービス、ツール
Python公式
Django公式
サードパーティーライブラリのドキュメント
パッケージ
ミドルウェア
サービス
デスクトップツール
標準仕様
裏話
英語名は The Self-Propelled Programmer
かな
日本語に直訳すると「自走式プログラマー」、なんだかすごそう
あるいは The Self-Driven Programmer
、こっちの方が通りが良さそう
企画開始は 2017/5/23(火)
出版が2020年2月なので、3年弱かかっている
企画開始当初、3年くらいという話をしていたら出版まで本当に3年かかった
じっくり時間をかけて中級向けに役立つ情報をまとめようとした
当初計画では、下書きを書いたら社内で実践してもらってフィードバックを集めようと計画
最後締め切りを区切られてから時間を捻出してまとめた

は締め切りがゆるいとオーバーしちゃうのを再実感
(途中1年ほどかなり厳しいプロジェクトに入っていて、
心の余裕もなかった)
やる気になってから非常に濃い密度で進められた
社内Slackの各チャンネルを追って、適用できそうか、できないとしたらなぜかを考えて反映した
書いた内容はGitHubにあるので、社内Slackで必要なシーンを見かけたら伝えた
実践してもらった結果を聞いて、原稿に反映した
先輩T
だと思って習ったけど実は Xさん
かもしれない(トピック 98)
しかもXさん、意外とTwitterでフォロワー多かったり、コミュニティでなにかしてたりもしそう。
先輩Tさん、猫のツイートしかしてない。
このネタで1講演できるくらいの価値ありそう。
知り合いの感想
terapyon:
買って読みました。けっこう早い段階でDjango前提の話がでてきてそこは読み解きづらかったので飛ばしました。そうやって飛ばしながら読めるのはよかった。全体的には良い内容で、Pythonに特化した感じではなくもっと一般的なことを伝えたいんだなと思いました
aodag:
いいね、ああいいねえ
詳細を読むと、例で説明しきれていない気もするけど、トピックタイトルと要点だけ読んでいくと伝えたいことがよくわかる。毎回説明してたのを本にまとめたんでしょ。
その他、言及等
> 「独学」で始め、「自走」し、「達人」に至るわけですね。
> この本を一言で表すなら Pythonのベストプラクティスの結晶 という感じです.
> いや, まじで, やばいです. 普段なら読んだ本から使えそうな部分をメモしてまとめるのですが, この本に紹介されている内容はすべてメモしたくなったし, 全ページ黄色マーカー引きたいし, 自分が困っていた問題にピンポイントに刺さってるのがいくつもあって本当に良かったです.
> この本はたまたま技術評論社のWebサイトで適当に本を探してたら見つけて, 目次見た感じ良さそうだったので買ったのですが, まさかここまで素晴らしくて実用的だとは思いませんでした.
> 読み始めたきっかけとして、自分は機械学習エンジニアとして現在働いているが、できることの幅を広げるために最近はソフトウェアエンジニアとしてのスキルをもっと伸ばしたいと考えている。
> 自走プログラマーは、Pythonを使ったアプリケーション開発のアンチパターンとベストプラクティスを例示して学ぶことができる書籍で、今回の自分の状況にすごくフィットしていて楽しく学習することができた。
>ソフトウェア開発の経験が浅い人は1章から順番に読めばよいし、
> コードは書けるけど設計が微妙という人は5章から読めばよく、
> 読み手のことを考えた構成で素晴らしいと思いました。
> "自走プログラマー"は読みやすい! それ重要です。読みづらい本はどんどん積ん読になってます。 #stapy
> ベストプラクティスは必ずしも正解ではないので、読書会で意見交換しあうのがお薦め。なるほど! #stapy
> 「自走プログラマー」のお薦めポイント現場レベルでありそうな知見やサンプルコード。自分事に近い知見は本当ありがたいですよねー #stapy
> 「この後輩説明上手いな」という気付き。ここに気がつくノもすごいなぁ。#stapy

自走プログラマー 紹介トークありがとうございました!「後輩説明うまいな」からの「こう説明すればいいんだ」という発想は、執筆時には想定してませんでしたw こんど本を紹介する際には使わせてもらいますね
#stapyトーク資料
> こちらの書籍はメインタイトルにもサブタイトルにも「Django」の文字は入っていないんですよね。
> Djangoの学習と並行してPython自体の学習も行っていますので、Djangoはとりあえず置いておいて、Python自体のレベルの底上げに役立つ書籍を探していました。そしてこの本を見つけたのです。
> 「ベストプラクティス120」ということで、いろいろなテーマが扱われていて読みやすそうですので買ってみることにしました。
> そして中身をよくよく読んでみると嬉しい誤算と言うのか、Djangoを題材にしたベストプラクティスがかなり出てくるんですよね。これはほぼDjangoの本なのではないかと錯覚するくらいに。
> それもそのはず、著者をよく見てみると、著者のおふたりはDjangoにもご関係のある方々なのですよね。

自走プログラマー の内容がSOで質問されていたので回答してみた
>個人開発で教えてくれる人いないからこの本はホント役に立つ。
>本番リリースするためにも必要なことがたくさん詰まってる。
>・「個人的に無意識にできていること・できてないこと」がそれぞれ明確になる(思わず息を呑むことも)
>・PRによるレビューの経験が少ないので、レビュアーの視点を書いてくれてるのがとても助かる。
>どういう部分に気をつけてもらいたいか、後輩を指導する時にも利用できそう。
>ただ、本書を読むにあたって、Djangoの基本的な知識が必要な部分がある。
>それにしても、この本に登場する「先輩T」がめっちゃ優しい。悟りでも開いているのだろうか。
>@touki_1513 - 午後1:43 · 2022年11月4日 「自走プログラマー」は、Python・Django技術者向けだったが、内容は普遍的なコーディング・テスト・DB設計規約のベストプラクティスの話で、とても参考になった。レビューやPR・要件定義にも踏み込んでいて、全部すぐ実践はできなくても、WFの工程別にチームで意識したいと思った。手元に欲しい
> Python での開発のベストプラクティスが実践に即して学べるいい本でした。
> 個人的には dataclass の使い方やログ、例外のあたりの内容が勉強になりました。
> 3章 エラー設計やロギングの話がよかった。基本的で大切なことが書いているので読み直したい。
> 1,3章あたりはPythonやプログラミングのお作法的なことが学べてよい。またプルリクや設計の初学者があまり触れない話もあり。リーダブルコードが抽象的でよくわからない人にとって良いかも
> 「Pythonを今まで何となく書いてきたけど、業務では全然…」というレベル感の人が読むには最適
> amazonレビューにもあったが、Web/Djangoをわかっていないのと読みづらい。web系エンジニア向けの内容なので、MLエンジニアには親和性が低い話も多い
> 情報が最新ではないので、頭の中で取捨選択が必要かも
> コードに型アノテーションがついていないことが少し気になる(Pythonのバージョンが低い場合も考慮している?)
> エンジニア転職をした私が、本書のコード実装を読みもう少し早く知っておきたかったことや実際に言われた事等を記載し今後の糧にする。