「自走プログラマー」という本が出ます！
この本は僕と清水川さん、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 トラブルシューティング・デバッグ
4.1 プロジェクト構成
4.2 サーバー構成
4.3 プロセス設計
- 93 サービスマネージャーでプロセスを管理する
- 94 デーモンは自動で起動させよう
- 95 Celeryのタスクにはプリミティブなデータを渡そう
4.4 ライブラリ
4.5 リソース設計
4.6 ネットワーク
5.1 要件定義
- 111 いきなり作り始めてはいけない
- 112 作りたい価値から考える
- 113 100％の要件定義を目指さない
5.2 画面モックアップ
こうやって見ると、よく書いたもんだなと思います。 著者の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製のライブラリーやフレームワークを元にした説明が中心になります。 なので、プログラミングも詳しくないし、Pythonも詳しくないという人には分かりにくいかもしれません。 逆に、RubyやRuby on Railsに慣れている人などは勉強になると思います。具体的にPython製のライブラリーを紹介しているトピックなどはありますが、その部分は「Rubyでもこういうライブラリーはあるのかな？」と考えて読んでいただければと思います。
長い長い執筆期間と込めたノウハウ
この本は著者陣が仕事の中で他の人に教えたことを中心に執筆しています。 たとえばコードレビューや、社内でのサポート、社内外の研修、コンサルティングの中で伝えてきたことをまとめています。 ビープラウド社内のメンバーも積極的にレビュー、コメントしてくれて、社内のかなりのノウハウが取り込まれています。
執筆に際しては社内で半年から1年をかけてネタを集めて、選別する時間を設けました。 著者の3人が日々の業務で伝えたことや感じたこと、過去に社内で伝えたことをネタ帳として集めてから執筆しています。 たとえば「ログには5W1Hを書こう」という僕が執筆を担当したプラクティスがあるのですが、これは5年前（2015年）から社内では共有していた知識です。これは社内でも好評で、「ロギングって大事だけど、何を書くべきかを学べる場所がなかった」とフィードバックを受けていました。 そのノウハウがやっと日の目を見ることになって、僕個人としてはとても嬉しいです。こんなにうれしいことはない。。
#自走プログラマー やっとこの話が日の目を見ることになった。。（社内では紀元前から共有していた） pic.twitter.com/VdFnDXZdC4
— Hiroki KIYOHARA@Shodoベータ利用募集中 (@hirokiky) 2020年2月20日
それ以外にもこの本は紆余曲折あり、一旦けっこう書いた内容を、構成や構造を変えて新しくしたりと大変でした。 執筆メンバーが抜けて再スタートしたり、正直、時間をかなり書けたので費用対効果はかなり悪い本になってしまったなと思っています。 ですがその分、長い時間を使っただけに本当に良い内容だけが本に抽出されたように思います。
ぜひ、この本を読んで日々のプログラミングやチームの改善に役立ててもらえると嬉しいです。
電子書籍は発売中です！ （2020年2月22日より発売）物理本も発売中です！（2020年2月27日より発売）
Epub/PDF版は技術評論社のサイトから購入できます（2月22日より）。 PDFで欲しい！という方は技術評論社からご購入ください。
他に知りたいこととか気になることがあれば何でも @hirokiky に聞いてください。
