新しいメンバーに Make debut してもらいやすくするための開発体制 with Python

Slide 1

Slide 1 text

新しいメンバーに   Make debut  してもらいやすくするための  開発体制 with Python  @kimihiro_n 

Slide 2

Slide 2 text

おまえ誰よ  @kimihiro_n  ・サーバーサイドエンジニア   ・Python, Go (, Android)  ・サーバレス(主にAWS)    ・趣味: ロードバイク、イラスト制作      2

Slide 3

Slide 3 text

背景・話すこと  チームの開発メンバー増加  ・サービスの改善速度を上げるためメンバー拡大中  ・新メンバーでもすんなり入れる開発体制を作りたい     チームに適合するための要素  ・「開発の進め方」「雰囲気・文化」etc…  ・今回は「開発の進め方」にフォーカス  ・「文化」の方はスクラムベース    3

Slide 4

Slide 4 text

01 コーディング CIで支える Product Ready な Python 開発

Slide 5

Slide 5 text

コーディング規約  コードスタイルの統一  ・人によってスタイルがまちまちだと混乱が生まれてしまう  ・→ 統一ルールが不可欠      PEP 8  ・PEP 8 を守っていれば大きなスタイルのすれ違いはない  ・とはいえ拾えないルールも結構ある  　　・Import の順  　　・シングル、ダブルクオート  　　・変数の大文字小文字    5

Slide 6

Slide 6 text

CI による Lint チェック  どうやって PEP 8 を守るか  ・コードレビューで目視チェック？  　　・コードレビューの本質ではない  　　・スタイルの違いで都度議論するのは不毛  　　　　・スタイルの違いに「優劣」はない  → CI に組み込んで Bot と壁打ちしてもらう        Flake8  ・PEP 8 の Linter  ・ルール設定やプラグイン拡張ができる  6

Slide 7

Slide 7 text

型ヒントによるアノテーション  型ヒントを書く  ・基本的に型ヒントを書くように  　　・関数の挙動が把握しやすい  　　・IDE による補完強化  　　・潜在的なバグの検知  ・型の整合性も CI でチェックしたい        Pyright  ・コードフローに基づいた型チェック  ・VSCode と親和性が高い  ・プロジェクト設定が柔軟  ・インストールに npm がいる(つらい)  7

Slide 8

Slide 8 text

安心のためのテストコード  テストコード  ・既存のコードを壊していないことを保証する安全帯  ・改修による予期せぬ影響に気付ける  　→ 新メンバーにとっても心理的安全性が高い  ・テストも当然 CI へ組み込んでおく  ・Django の場合、RDB に実際に接続するテストも書きやすい  ・CI 上で Docker Compose してテスト  　　・動作環境に近いテストができる  　　・実行遅いのが欠点  Django のテスト  8

Slide 9

Slide 9 text

CI による Product Ready な開発  「コーディングルール」  「型チェック」  「テスト」を CI に組み込んで自動チェック  　→ 「Product Ready」なコードが完成   　　　本質的な部分だけをレビューできる    「型アノテーション」「テストコード」  の追加は慣れが必要  　・最初はコーディングルールにのみ準拠  　・コードレビューしつつ順次追加してもらう    実際の運用  9

Slide 10

Slide 10 text

02 開発環境 Docker を活用した効率的な開発環境

Slide 11

Slide 11 text

ローカル開発環境     ・セットアップにあれこれインストールがいらない  　　・clone して数コマンド叩けば完了が理想  ・開発環境の操作で他人に影響を及ぼさない  ・ローカルのデータはローカルで閉じている  　　　　・AWS とかにアクセスしに行かない  ・壊れたら clone からやり直せる  ・Windows でも Mac でも同じように動く      開発環境の理想系  11

Slide 12

Slide 12 text

docker compose による開発環境     ・docker compose up の1コマンドで完結するように  　　・複雑な依存も Dockerfile 内でインストール  　　・データベースも一緒に立ち上げられる  　　　　・壊してもすぐ作り直せる  　　・プラットフォーム固有機能(Amazon DynamoDB など)  → エミュレータを活用 (DynamoDB Local)  　　・Windows でも動く(やや罠あり)  docker compose  12

Slide 13

Slide 13 text

検証環境  検証環境の活用  ・ローカルだけでは検証しきれない点  　　・常時最新のデータが入ってくる  　　・データの規模、負荷  　　・APIキー、外部サービス上の制約  　　・実際のサーバー上での挙動    検証環境の構築  ・検証環境を本番と同じ構成で構築  　　・データ量なども大体同じ  　　・GitLab でタグを打てばデプロイできるように    13

Slide 14

Slide 14 text

検証環境の渋滞解消  検証環境の渋滞  ・当初検証環境が1つしかなかった  　　・利用したい人で順番待ちの発生  　　・開発スピードのボトルネックに  kubernetes による複数環境  ・Kubernetes でブランチごとに環境をつくれるように  ・任意のフロントコードと API を組み合わせて検証可能  　　→ 複数のメンバーが同時に検証をすすめられるように  Link: APIとフロントのテスト環境を気軽に作れるようにして、動作検証の渋滞を解消したはなし 14

Slide 15

Slide 15 text

03 技術選定チームとしての言語・ライブラリの選び方

Slide 16

Slide 16 text

どんな技術を選ぶか  ・一般的な技術選定に加えて考慮すべき点  ・既存のメンバーでどれくらい対応出来るか  ・新しく人が入ってきた場合に受け入れられるか  　　　・広義には「人が採用出来るか」  　　・得られるもの  　　　　・慣れた技術: 安心・安全  ・新しい技術: モチベアップ、技術力向上        チームとしてどんな技術を使うか  16

Slide 17

Slide 17 text

例: Django  ・Web 開発をする上でおそらく最も大きな分岐点  ・RDB を使った開発であれば爆速で動くものが作れる  ・ただし、他のフレームワークへの差し替えは容易でない    ・Django を導入する覚悟  　　・プロダクトが大きくなっても付き合っていけるか  　　・Django が書けるメンバーを集められるか  　　　　・Pythonista でも Django 未経験は大勢  　　　　・SQL を隠すので初学者には触りやすい面も  ・ただしパフォーマンスには注意  　　・型アノテーションと相性が悪い問題    17

Slide 18

Slide 18 text

まとめ

Slide 19

Slide 19 text

まとめ  ・CI を整えることで新メンバーのコーディングをサポート  　　・安全かつチームのルールに沿った開発を可能に  　　・既存コードが壊れてないことの安心感    ・すぐ触れる開発・検証環境の構築  　　・どのレポジトリでもコントリビュートしやすく    ・新しいメンバーを見据えた技術選定  　　・受け入れやすさも考慮して選ぶ      Make debut! 19

Slide 20

Slide 20 text

ThankYou!