自走プログラマー
Pythonの先輩が教えるプロジェクト開発のベストプラクティス120

[表紙]自走プログラマー ~Pythonの先輩が教えるプロジェクト開発のベストプラクティス120

B5変形判/288ページ

定価(本体2,980円+税)

ISBN 978-4-297-11197-7

電子版

→学校・法人一括購入ご検討の皆様へ

書籍の概要

この本の概要

「初心者本はひととおり読んだけれど,次に何をしてよいかわからない」
「簡単なコードは書けるけれど,中規模システムは作れない」
本書は,そんなプログラミング迷子が設計からコードまで書けるスキルを身につけるための指南書です。
開発現場で起こった実際の問題とその解決法をもとに,文法以外に必要な「プロジェクトの各段階でプログラマーがやること」「その選択をどう判断するのか」「どうコードを実装して実現していくのか」を解説します。コードにはPythonを使用していますが,ほかのプログラム言語でも共通する知識が満載。より効率的かつ効果的にプログラムを書ける「自走できるプログラマー」へ導きます。

こんな方におすすめ

  • プログラムを書けるけど,レビュー指摘などで手戻りが多い人
  • 優れたエンジニアになりたい人
  • 設計の仕方や,メンテナンス性の高いプログラムの書き方を知りたい人

著者の一言

プログラミングは,パソコンがあれば無料で始められます。初学者向けの本もたくさんあり,特にここ数年は今まで以上に多くの人がプログラミングを始めています。裾野はどんどん広がっていき,2020年からの初等教育でのプログラミングの必修化もそれを後押ししていくでしょう。あと何年か後には,プログラミングが今よりももっと日常的に行われる世の中になっているかもしれません。
こうした状況はとても喜ばしいことですが,プログラミングが一部の人のだけが持つスキルでなくなれば,仕事でプログラミングする人にはより高いスキルが求められることになります。競争が激しくなっていくなかで,より秀でたプログラマーになるためには,何が求められるでしょうか?
プログラミングで何かを作るには,文法の他にアプリケーションを設計するスキルや,ライブラリを選定するスキル,Webアプリケーションなら本運用し続ける環境を整えるスキル,運用するスキル,などさまざまなスキルが必要です。これらのスキルのうち,「プログラミングで何かを作るプロセスとスキル」「プログラミングで作りたいものを設計するスキル」をお伝えするのが本書です。本書を読み終わったとき,次のようになれたらすばらしいと思いませんか?

  • 自分の作りたいものを着実に作るプロセスがわかっている
  • どう設計すればアプリケーションとして良いものができるかがわかっている
  • どういう場合にどのライブラリを使えば良いかわかっている

本書はそんな,単にプログラミング言語だけでないプログラミングの「中級な」「設計を含んだ」「うまく作るための」内容をお伝えする本です。少し読んでみると「プログラミングそのものの話題が少ない」と少し戸惑うかもしれません。ですがそれこそがプログラミング能力を活かして何かを作るために必要なことです。

我々ビープラウドは,在籍するスタッフの多くがコードを扱います。代表取締役も,営業の役割を担っている人間も,コードを読み書きします。現在の仕事は多くが受託開発で,大量のトラフィックを捌く必要があるコンシューマ向けのWebシステムや,ビジネス向けのWeb業務システム,機械学習によるデータ処理とWebの連携などが多くを占めているWeb系ソフトウェア開発という職種です。
ビープラウドでの開発プロジェクトは2~3ヶ月という短いスパンのプロジェクトを2~3名で開発することが多いため,1人が関わる範囲が広く,必然的に書くコードの量も多くなります。私たちにとってプログラマーとは,設計書をコードにする単純作業者のことではなく,やりたいことをまとめ,設計からコードにし,そしてリリースするまでをすべて1人でできる人のことを指しています。本当にすばらしいサービスやアプリケーションをつくり出すには,自走できるプログラマーが必要です。
とはいえ,すべてのプログラマーがはじめから自走できたわけではなく,組織のメンバーは常に入れ替わっていき,新しく参加するメンバーの中にはこれからいろいろなことを学んでいく人もいます。それは,技術的なつまづきと学びを繰り返して,その背景にある原理原則をメンバーそれぞれが見つけていく,長い旅のようなものです。ビープラウドには,この学びの旅をサポートする「教え合う文化」が根づいており,つまづいたときには先輩が親身になって助けてくれます。そこで先輩達が教えてきた履歴を見ると,新しいメンバーがなぜか必ずつまづいてしまうパターンがいくつもあることがわかってきました。こういった,設計からコードまで書けるようになるために知っておいてほしい技術的なトピックを集め,この本にまとめました。
本書は,プログラミング入門ならぬ,脱入門者を目指す開発者向けの指南書です。自走できるプログラマーであれば知っているであろういろいろな手法や観点を元に,「プロジェクトの各段階でプログラマーがやること」「その選択をどう判断するのか」「どうコードを実装して実現していくのか」を紹介します。一部の最新技術に注目するのではなく,実際のプロジェクトに適用して,プロジェクトを完成させるための指針をまとめました。

目次

まえがき

第1章 コード実装

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章 モデル設計

2.1 データ設計

  • 46 マスターデータとトランザクションデータを分けよう
  • 47 トランザクションデータは正確に記録しよう
  • 48 クエリで使いやすいテーブル設計をする

2.2 テーブル定義

  • 49 NULLをなるべく避ける
  • 50 一意制約をつける
  • 51 参照頻度が低いカラムはテーブルを分ける
  • 52 予備カラムを用意しない
  • 53 ブール値でなく日時にする
  • 54 データはなるべく物理削除をする
  • 55 typeカラムを神格化しない
  • 56 有意コードをなるべく定義しない
  • 57 カラム名を統一する

2.3 Django ORMとの付き合い方

  • 58 DBのスキーママイグレーションとデータマイグレーションを分ける
  • 59 データマイグレーションはロールバックも実装する
  • 60 Django ORMでどんなSQLが発行されているか気にしよう
  • 61 ORMのN+1問題を回避しよう
  • 62 SQLから逆算してDjango ORMを組み立てる

第3章 エラー設計

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章 システム設計

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章 やることの明確化

5.1 要件定義

  • 111 いきなり作り始めてはいけない
  • 112 作りたい価値から考える
  • 113 100%の要件定義を目指さない

5.2 画面モックアップ

  • 114 文字だけで伝えず,画像や画面で伝える
  • 115 モックアップは完成させよう
  • 116 遷移,入力,表示に注目しよう
  • 117 コアになる画面から書こう
  • 118 モックアップから実装までをイメージしよう
  • 119 最小で実用できる部分から作ろう
  • 120 ストーリーが満たせるかレビューしよう

参考文献

索引

著者プロフィール

清水川貴之(しみずかわたかゆき)

2003年からPythonを主言語として使い始め,Webアプリケーションの開発を中心に活用してきた。現職のビープラウドでは開発の他,Python関連書籍の執筆や研修講師も行っている。個人では,一般社団法人PyCon JPの理事として日本各地で開催されているPython Boot CampでPython講師を務めている。Python mini Hack-a-thonなどPython関連イベント運営のかたわら,国内外のカンファレンスへ登壇しPython技術情報を発信するなど,公私ともにPythonとその関連技術の普及活動を行っている。共著書/共訳書:『Pythonプロフェッショナルプログラミング第3版(2018 秀和システム刊)』『エキスパートPythonプログラミング改訂2版(2018アスキードワンゴ刊)』『独学プログラマー(2018 日経BP 社刊)』『Sphinxをはじめよう第2版(2017 オライリー・ジャパン刊)』
Twitter:@shimizukawa
URL:http://清水川.jp/


清原弘貴(きよはらひろき)

2012年10月よりBeProud所属。2011年から本格的にPythonを使っている。Djangoが好きで,日本で最大級のDjangoイベントDjangoCongress JP(https://djangocongress.jp)の主催をしたり,Webアプリケーションやライブラリを作ったり,Django本体のソースコードへパッチを送ったりしている。個人でShodo(https://shodo.ink),dig-en(https://dig-en.com),PileMd(https://pilemd.com),仕事でPyQ(https://pyq.jp)など,多数のWebサービス・アプリを企画,開発している。共著書に『Pythonプロフェッショナルプログラミング第3版(2018 秀和システム刊)』『Pythonエンジニアファーストブック(2017 技術評論社刊)』がある。
Twitter:@hirokiky
URL:http://hirokiky.org/


tell-k(てるけー)

2005年からPHP/Perlを利用したWebアプリケーション開発の仕事に従事し,2011年から本格的に仕事でPythonを使い始めた。最近はもっぱらお猫様のお世話に忙しい。共著書に『Pythonプロフェッショナルプログラミング第3版(2018秀和システム刊)』がある。
Twitter:@tell_k
GitHub:tell-k