自走プログラマー 表紙
「自走プログラマー 」という本が出ます！
この本は僕と清水川さん、tell-kさんで、株式会社ビープラウ ドの仕事として書いた本です。
自走プログラマー には僕の10年来の開発ノウハウを詰め込みました。清水川さんtell-kさんに至ってはもっと長い経験があります。その3人が、入門本ではない本を本気で書きました。さらにビープラウ ドのつよつよメンバーが何度も何度もレビューしてくれました。
僕は自走プログラマー を多くの人にぜひ読んでほしいと思っています。ですが、「とにかく買ってほしい」とはあまり思っていません。
なぜかというと、普段、 僕（著者全員）が伝えたいこと・伝えてきたことを書いた本 だからです。
なので「多くの人に読んで欲しい」、「これで助けになってほしい」と思っています。むしろビープラウ ドでは自走プログラマー （とPython プロフェッショナルプログラミング）を読んでもらったうえで普段話をしたいです。
私個人としても PyQ や Shodo を作りながら会得したこと、ビープラウ ドで学んできたことを詰め込んだ内容の本になっています。
プログラミングで手戻りが多くありませんか？
レビューなどで、多くの指摘をうけて 手戻りが大きくなっていませんか ？
実際に 本番環境で運用しはじめてから問題に気づく ことは多くないですか？
自走プログラマー はそういった人のための本です。自走プログラマー の前書きより引用します。
開発現場で起こった実際の問題とその解決法をもとに，文法以外に必要な「プロジェクトの各段階でプログラマー がやること」「その選択をどう判断するのか」「どうコードを実装して実現していくのか」を解説します。
こんな方におすすめ：
プログラムを書けるけど，レビュー指摘などで手戻りが多い人
優れたエンジニアになりたい人
設計の仕方や，メンテナンス性の高いプログラムの書き方を知りたい人
自走プログラマー は120個のプラク ティスを通して学べる本です。
各プラク ティスには具体的な失敗とベストプラク ティス、説明が書かれています。
120個のプラク ティスはこちらです（以下、長いです）。
気になるものがあるか見てみてください。本の雰囲気も伝わると思います。
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.1 データ設計
2.2 テーブル定義
49 NULLをなるべく避ける
50 一意制約をつける
51 参照頻度が低いカラムはテーブルを分ける
52 予備カラムを用意しない
53 ブール値でなく日時にする
54 データはなるべく物理削除をする
55 typeカラムを神格化しない
56 有意コードをなるべく定義しない
57 カラム名 を統一する
2.3 Django ORMとの付き合い方
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.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.1 要件定義
111 いきなり作り始めてはいけない
112 作りたい価値から考える
113 100％の要件定義を目指さない
5.2 画面モックアップ
114 文字だけで伝えず，画像や画面で伝える
115 モックアップ は完成させよう
116 遷移，入力，表示に注目しよう
117 コアになる画面から書こう
118 モックアップ から実装までをイメージしよう
119 最小で実用できる部分から作ろう
120 ストーリーが満たせるかレビューしよう
こうやって見ると、よく書いたもんだなと思います。
著者の3人が個別のプラク ティスを分業して書きました。
ちなみに僕の担当は1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 22, 23, 25, 28, 29, 30, 31, 32, 49, 50, 51, 52, 53, 54, 55, 56, 57, 69, 70, 71, 72, 73, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120です！
手取り足取り教えてくれる本ではありません
網羅的かつ段階的に設計やアプリケーション開発を教える本ではありません。
ですので「入門書はとりあえず終わったので次に何かを教えてくれる本が欲しいな」という人には残念ながら向いていません。
本が課題やサンプルを提示して、 「あなたもこれを作ってみよう」という本ではありません 。
ですが、設計やアプリケーション開発に重要なこと、ノウハウやプラク ティスはたくさんお伝えしています。
何か作りたいものがあって、挑戦しているがうまくいかないことが多く悩んでいる人にはオススメします 。
逆に、何か作りたいものも分からない人や、自力でプログラムを書いてみたことがあまりない人にはオススメしません。
もし先輩プログラマー の人でこの本を後輩さんに読ませたいなというときは、この本がアドバイス や導きのキッカケになると嬉しいです。
もしかしたら、キッチリ題材を作って学ばしてあげる必要があるかもしれません。1プラク ティスに書かれている内容が、先輩的には十分とは思えないかもしれません。
そのときはぜひ、直接後輩さんや他メンバーにあなた自身のノウハウを教えてあげてください。
自走プログラマー は、 Python に限らない広い範囲で使える知識を読める本Python の本とは少し違います。どちらかというと、リーダブルコードに近いかもしれません。
内容はプログラミング言語 Python を使って書かれていますし、Python 製のライブラリーやフレームワーク を元にした説明が中心になります。
なので、プログラミングも詳しくないし、Python も詳しくないという人には分かりにくいかもしれません。
逆に、Ruby やRuby on Rails に慣れている人などは勉強になると思います。具体的にPython 製のライブラリーを紹介しているトピックなどはありますが、その部分は「Ruby でもこういうライブラリーはあるのかな？」と考えて読んでいただければと思います。
長い長い執筆期間と込めたノウハウ
この本は著者陣が仕事の中で他の人に教えたことを中心に執筆しています。
たとえばコードレビューや、社内でのサポート、社内外の研修、コンサルティング の中で伝えてきたことをまとめています。
ビープラウ ド社内のメンバーも積極的にレビュー、コメントしてくれて、社内のかなりのノウハウが取り込まれています。
執筆に際しては社内で半年から1年をかけてネタを集めて、選別する時間を設けました。
著者の3人が日々の業務で伝えたことや感じたこと、過去に社内で伝えたことをネタ帳として集めてから執筆しています。
たとえば「ログには5W1H を書こう」という僕が執筆を担当したプラク ティスがあるのですが、これは5年前（2015年）から社内では共有していた知識です。これは社内でも好評で、「ロギングって大事だけど、何を書くべきかを学べる場所がなかった」とフィードバックを受けていました。
そのノウハウがやっと日の目を見ることになって、僕個人としてはとても嬉しいです。こんなにうれしいことはない。。
それ以外にもこの本は紆余曲折あり、一旦けっこう書いた内容を、構成や構造を変えて新しくしたりと大変でした。
執筆メンバーが抜けて再スタートしたり、正直、時間をかなり書けたので費用対効果はかなり悪い本になってしまったなと思っています。
ですがその分、長い時間を使っただけに本当に良い内容だけが本に抽出されたように思います。
ぜひ、この本を読んで日々のプログラミングやチームの改善に役立ててもらえると嬉しいです。
電子書籍 は発売中です！
Epub/PDF版は技術評論社のサイトから購入できます （2月22日より）。
PDFで欲しい！という方は技術評論社 からご購入ください。
他に知りたいこととか気になることがあれば何でも @hirokiky に聞いてください。
他にオススメの記事
shacho.beproud.jp
blog.hirokiky.org
shodo.ink
