Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

JX Tech Talk #python
『Pythonista 達が語る速報サービス開発の舞台裏』
https://jxpress.connpass.com/event/215106/
2021-06-23(水) 19:30-

JX通信社主催のTech Talkイベントの登壇資料になります。

kimihiro_n

June 23, 2021
Tweet

More Decks by kimihiro_n

Other Decks in Technology

Transcript

  1. 新しいメンバーに 

    Make debut

    してもらいやすくするための

    開発体制 with Python

    @kimihiro_n


    View full-size slide

  2. おまえ誰よ

    @kimihiro_n

    ・サーバーサイドエンジニア 

    ・Python, Go (, Android)

    ・サーバレス(主にAWS)


    ・趣味: ロードバイク、イラスト制作



    2

    View full-size slide

  3. 背景・話すこと

    チームの開発メンバー増加

    ・サービスの改善速度を上げるためメンバー拡大中

    ・新メンバーでもすんなり入れる開発体制を作りたい


    
チームに適合するための要素

    ・「開発の進め方」「雰囲気・文化」etc…

    ・今回は「開発の進め方」にフォーカス

    ・「文化」の方はスクラムベース


    3

    View full-size slide

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

    View full-size slide

  5. コーディング規約

    コードスタイルの統一

    ・人によってスタイルがまちまちだと混乱が生まれてしまう

    ・→ 統一ルールが不可欠



    PEP 8

    ・PEP 8 を守っていれば大きなスタイルのすれ違いはない

    ・とはいえ拾えないルールも結構ある

      ・Import の順

      ・シングル、ダブルクオート

      ・変数の大文字小文字

    
 5

    View full-size slide

  6. CI による Lint チェック

    どうやって PEP 8 を守るか

    ・コードレビューで目視チェック?

      ・コードレビューの本質ではない

      ・スタイルの違いで都度議論するのは不毛

        ・スタイルの違いに「優劣」はない

    → CI に組み込んで Bot と壁打ちしてもらう




    Flake8

    ・PEP 8 の Linter

    ・ルール設定やプラグイン拡張ができる

    6

    View full-size slide

  7. 型ヒントによるアノテーション

    型ヒントを書く

    ・基本的に型ヒントを書くように

      ・関数の挙動が把握しやすい

      ・IDE による補完強化

      ・潜在的なバグの検知

    ・型の整合性も CI でチェックしたい




    Pyright

    ・コードフローに基づいた型チェック

    ・VSCode と親和性が高い

    ・プロジェクト設定が柔軟

    ・インストールに npm がいる(つらい)
 7

    View full-size slide

  8. 安心のためのテストコード

    テストコード

    ・既存のコードを壊していないことを保証する安全帯

    ・改修による予期せぬ影響に気付ける

     → 新メンバーにとっても心理的安全性が高い

    ・テストも当然 CI へ組み込んでおく

    ・Django の場合、RDB に実際に接続するテストも書きやすい

    ・CI 上で Docker Compose してテスト

      ・動作環境に近いテストができる

      ・実行遅いのが欠点

    Django のテスト

    8

    View full-size slide

  9. CI による Product Ready な開発

    「コーディングルール」

    「型チェック」

    「テスト」を CI に組み込んで自動チェック

     → 「Product Ready」なコードが完成 

       本質的な部分だけをレビューできる


    「型アノテーション」「テストコード」

    の追加は慣れが必要

     ・最初はコーディングルールにのみ準拠

     ・コードレビューしつつ順次追加してもらう


    実際の運用

    9

    View full-size slide

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

    View full-size slide

  11. ローカル開発環境


    
・セットアップにあれこれインストールがいらない

      ・clone して数コマンド叩けば完了が理想

    ・開発環境の操作で他人に影響を及ぼさない

    ・ローカルのデータはローカルで閉じている

        ・AWS とかにアクセスしに行かない

    ・壊れたら clone からやり直せる

    ・Windows でも Mac でも同じように動く



    開発環境の理想系

    11

    View full-size slide

  12. docker compose による開発環境


    
・docker compose up の1コマンドで完結するように

      ・複雑な依存も Dockerfile 内でインストール

      ・データベースも一緒に立ち上げられる

        ・壊してもすぐ作り直せる

      ・プラットフォーム固有機能(Amazon DynamoDB など)

    → エミュレータを活用 (DynamoDB Local)

      ・Windows でも動く(やや罠あり)

    docker compose

    12

    View full-size slide

  13. 検証環境

    検証環境の活用

    ・ローカルだけでは検証しきれない点

      ・常時最新のデータが入ってくる

      ・データの規模、負荷

      ・APIキー、外部サービス上の制約

      ・実際のサーバー上での挙動


    検証環境の構築

    ・検証環境を本番と同じ構成で構築

      ・データ量なども大体同じ

      ・GitLab でタグを打てばデプロイできるように

    
 13

    View full-size slide

  14. 検証環境の渋滞解消

    検証環境の渋滞

    ・当初検証環境が1つしかなかった

      ・利用したい人で順番待ちの発生

      ・開発スピードのボトルネックに

    kubernetes による複数環境

    ・Kubernetes でブランチごとに環境をつくれるように

    ・任意のフロントコードと API を組み合わせて検証可能

      → 複数のメンバーが同時に検証をすすめられるように

    Link: APIとフロントのテスト環境を気軽に作れるようにして、動作検証の渋滞を解消したはなし
    14

    View full-size slide

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

    View full-size slide

  16. どんな技術を選ぶか

    ・一般的な技術選定に加えて考慮すべき点

    ・既存のメンバーでどれくらい対応出来るか

    ・新しく人が入ってきた場合に受け入れられるか

       ・広義には「人が採用出来るか」

      ・得られるもの

        ・慣れた技術: 安心・安全

    ・新しい技術: モチベアップ、技術力向上




    チームとしてどんな技術を使うか

    16

    View full-size slide

  17. 例: Django

    ・Web 開発をする上でおそらく最も大きな分岐点

    ・RDB を使った開発であれば爆速で動くものが作れる

    ・ただし、他のフレームワークへの差し替えは容易でない


    ・Django を導入する覚悟

      ・プロダクトが大きくなっても付き合っていけるか

      ・Django が書けるメンバーを集められるか

        ・Pythonista でも Django 未経験は大勢

        ・SQL を隠すので初学者には触りやすい面も

    ・ただしパフォーマンスには注意

      ・型アノテーションと相性が悪い問題

    
 17

    View full-size slide

  18. まとめ

    ・CI を整えることで新メンバーのコーディングをサポート

      ・安全かつチームのルールに沿った開発を可能に

      ・既存コードが壊れてないことの安心感


    ・すぐ触れる開発・検証環境の構築

      ・どのレポジトリでもコントリビュートしやすく


    ・新しいメンバーを見据えた技術選定

      ・受け入れやすさも考慮して選ぶ



    Make debut!
    19

    View full-size slide