PHP CONFERENCE JAPAN 2020のLTに登壇する際の資料
https://fortee.jp/phpcon-2020/proposal/2f75bfc5-b6ad-433b-afc9-732e3fd75aa8
チームメンバーをエンパワーメントしよう!レガシープロジェクト改善事始めぬさし( @nukisashineko )1/19
View Slide
チームをエンパワーメントする● 輪読会、勉強会、モブプロ等○ スキルマップを広げ、基礎力の向上● Developer Experience(開発体験)の向上○ 環境の質向上、手動運用を自動化する等2/19
方針・指針1. できることからやるのが一番早い2. 簡単で自動化可能なものから始める何から改善していけばいいの?3/19● できること=手を動かした経験があるもの● できること ≠ 知ってること (経験がないもの)
方針・指針1. できることからやるのが一番早い2. 簡単で自動化可能なものから始める1. すぐに効果が出ること2. チームへ効果が出ること4/19コスパ良く改善するには何から改善していけばいいの?も重要
改善対象のプロジェクトを紹介● 10年を超えたサービス● ローカル開発環境はない○ debug不可能● アプリ・DBはオンプレ○ ロギングが貧弱● CIは無い5/19
改善可能な点● debugを動かせるようにする● CIの導入● 新しいツールやSaaSの導入……● etc.6/19
7/19「じゃあ何からやったの?」debugを動かせるようにした!活動報告(1) - 環境改善選択理由:「できることだった!」
debug環境作成 - 作って配る8/19● 1週間目→検証用のovaファイルを入手● 1ヶ月目→debug可能環境へ再構築● 2ヶ月目→repository化&チームメンバーに配布作業時間は1[時間/日]
debug環境作成 - メンバーに使ってもらう9/19● debugを文化にする○ ドキュメントは丁寧に○ remote debug設定は簡単化 (gitに含める)○ debuggerの使い方をハンズオンする(都度)「作ったよ!」で終わらず使い続けて広める
debug環境作成 - 結果10/19● debugが使える!○ 調査時間の大幅削減 (printf debugと比較)● 問題の切り分けが容易に!○ ローカル環境があるという強み
11/19「次は何をやったの?」GitHub Actions(CI)を導入しました活動報告(2) - 自動化による省力化
CIの導入 - 指摘の自動化 - master merge12/19「PR依頼の前にmaster mergeしといてよ」
CIの導入 - 指摘の自動化 - Linter dry run13/19「PR依頼の前にLinterの実行をしといてよ」
CIの導入 - 結果14/19● PRの往復時間削減!○ レビュイーが修正点に気づける● 本質的な指摘が増えた!○ 時間をロジック検討に多く使える
改善の際に注意すべきこと● 改善はチームメンバーの参意を確認○ チームで保守・運用するため● 大きな変化はゆっくり起こす○ 唐突で大きな変化は定着しない15/19
改善の際に注意すべきこと - 例を元に● 例:Linterの導入○ よくあるパターン (完璧主義)■ 「Linterで機械的なレビューを行うため 全部のファイルへ置換を行います!」■ 「確認範囲が拡大して難しいから後で」16/19
改善の際に注意すべきこと - 例を元に● 例:Linterの導入○ やるべきパターン (導入を目指す)■ 「影響範囲が広がらないように 新規ファイルに限って適用します!」■ 「それならお試しで導入してみたいね」17/19
何からやればいい?という人へ1. Linter (PHP-CS-Fixer, PHPMD, Phan)2. Github Actions3. SaaSの監視ツールExtra.debug環境の用意18/19PR高速化自動化の事始め導入が楽で高機能開発体験に効果的難易度高め
まとめ - チームをエンパワーメント事始め!● できるものから始める● 作ったらチームの文化にする● 独りよがりな開発にしない19/19