チームで「きちんと」Laravel を使っていくための取り組み
•
3 likes•4,964 views
2018/03/14 開催の「【 ヒカ☆ラボ 】【Laravel5、CakePHP3など】ベンチャー企業のリアルなPHP事情」の資料です。 https://atnd.org/events/95005
Recommended
More Related Content
What's hot
What's hot (19)
Similar to チームで「きちんと」Laravel を使っていくための取り組み
Similar to チームで「きちんと」Laravel を使っていくための取り組み (20)
More from Shohei Okada
More from Shohei Okada (20)
チームで「きちんと」Laravel を使っていくための取り組み
- 2. 岡田 正平（おかだ しょうへい）@okashoi • 株式会社ウィルゲート 2015年新卒入社 • 開発室 ソリューションユニット 所属 • PHP, Laravel, Vue.js • 資料は後ほど公開します 2 自己紹介 Slides:
- 3. 3 株式会社ウィルゲート
- 4. 4 株式会社ウィルゲート
- 5. 5 株式会社ウィルゲート
- 6. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 6 チームで「きちんと」Laravel を使っていくための取り組み
- 7. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 7 チームで「きちんと」Laravel を使っていくための取り組み
- 8. • 2017年4月から新規プロダクトの開発がはじまる（Laravel） • web コンサルティングのノウハウをシステム化 • 以降、新しくチームに受け入れた人数 = 5名 • Laravel 未経験者が多い（新卒、業務委託） • チーム内で Laravel に関する理解がもっとも深いのが私 8 背景 | チームの状況
- 9. • Laravel は「設計を自力でできないと道に迷ってしまいがち」 9 背景 | Laravel の特徴 ※スライド「PHP 2大 web フレームワークの徹底比較！」より
- 10. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 10 チームで「きちんと」Laravel を使っていくための取り組み
- 11. 前提： 「きちんと」使う ≠ 全ての機能を使いこなしている • 時として「使う必要がない」「チームでの運用は難しい」 という判断もする • 「使ったほうがいい」と思えば使う 使うからにはチームみんなが理解し、使える状態を目指す 11 解決したい課題 | 前提
- 16. 16 解決したい課題 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能 悲しみ のもと • 誤った使い方 • 車輪の再発明 → バグ混入の可能性・メンテコストの増加
- 17. 17 解決したい課題 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能 Laravel が提供していて 「きちんと」 使えている機能 時間の経過とともにシステムの開発は進む →「使いたい機能」の領域が広がる
- 18. 18 解決したい課題 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能 Laravel が提供していて 「きちんと」 使えている機能 生まれゆく 悲しみ を減らすために 「チームで」理解している範囲を拡大していきたい
- 19. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 19 チームで「きちんと」Laravel を使っていくための取り組み
- 20. • ドキュメントの整備 • 実装前の方針すり合わせ（設計レビュー） • 「コーディングに関する相談会」の定期実施 20 やったこと
- 21. • 「Laravel のお作法」や「コーディング規約」 あるいは「設計のベストプラクティス」のようなものまで • 必要に応じてチームメンバーが参照できる状態にする 21 やったこと | ドキュメントの整備
- 22. • 「ガイドライン」と称した具体的なコード例も準備 • 同一のリポジトリ内に作成（開発環境のみで実際に動く） • ガイドライン作成のプルリク自体がドキュメントにもなる 22 やったこと | ドキュメントの整備
- 23. • 実装を始める前に所定のフォーマットで実装方針をまとめる • まとめた実装方針をもとに 所定のレビュワーがレビューし方針をすり合わせる • Laravel が提供している機能で実現できないか？ • 提供されている機能を正しく使えているか？ 23 やったこと | 実装前の方針すり合わせ（設計レビュー）
- 24. 24 やったこと | 実装前の方針すり合わせ（設計レビュー） ※Notifications を活用する例 半分以上伏せてますが……
- 25. • 週に1回30分 チームメンバー全員参加（他のチームの人も参加OK） • コーディングについてなんでも（Laravel に限らず）相談できる • 「ここどうしたらいいですか？」 • 「こんな記事を見つけたんですが、どう思います？」 など • コーディングに関する意識のすりあわせ・ノウハウ共有が目的 • 他人に対する批判はナシ（お互いに注意する） ✕「こんなことも知らないの？」 ✕「その考え方はダメ」 25 やったこと |「コーディングに関する相談会」の定期実施
- 26. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 26 チームで「きちんと」Laravel を使っていくための取り組み
- 27. • チームで初めて使う Laravel の機能や、新しく始めることの 導入がしやすくなった • テストコードや Laravel Mix 導入など • 生まれそうな 悲しみ を未然に防げるようになった • チームメンバー間で「良いコード」について会話するようになった • 作業中にも「ここの実装って～」というような 会話が生じるようになった ➢ 「良いコード」を意識するようになれば Laravel が提供する機能に目が向いていくはず（……という期待） 27 良かったこと
- 28. • プルリクのレビューの負担が減った • 実装方針のすり合わせができているので フィードバック→修正 のサイクルが減った • 副次効果として「プルリクを細かく分けて出す」風潮を作り出せた • レビューのタイミングですり合わせる • コーディングに関する相談会に他のチームの人も参加可能にしたこと • 他チームのノウハウ・観点を知ることができる 28 良かったこと
- 29. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 29 チームで「きちんと」Laravel を使っていくための取り組み
- 30. • 新しく入ったメンバーに全ドキュメントを目を通してもらう必要はない • 現実的にそれができる量ではなくなった • 「最初に最低限目を通してもらうもの」は選出する必要 • 設計レビュワー（1人）の負担が思ったより大きかった • プルリクレビューの負担軽減を相殺して足が出るくらい • 実装者が方針を修正するタイミングが早まったので チームとしてはプラス • ただし、ここがボトルネックになってしまうこともあった • 「自分のレビューは正しいのか？」という終わらない問い 30 学んだこと
- 31. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 31 チームで「きちんと」Laravel を使っていくための取り組み
- 32. • すでに生まれてしまった 悲しみ の救済 • 規約・ドキュメントを更新していく仕組みづくり • レビュワーの育成 32 今後の展望
- 33. • すでに生まれてしまった 悲しみ の救済 • 規約・ドキュメントを更新していく仕組みづくり • レビュワーの育成 33 今後の展望
- 34. 34 今後の展望 | すでに生まれてしまった悲しみの救済 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能 Laravel が提供していて 「きちんと」 使えている機能 （これまで）生まれゆく 悲しみ を減らすために 「チームで」理解している範囲を拡大していく仕組みを作った
- 35. 35 今後の展望 | すでに生まれてしまった悲しみの救済 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能 Laravel が提供していて 「きちんと」 使えている機能
- 36. 例）独自実装になってしまった認可機構 • 実装が開放閉鎖原則に反していてる ← 悲しみ ➢ Laravel が提供している Gate, Policy に置き換える 36 今後の展望 | すでに生まれてしまった悲しみの救済
- 37. • すでに生まれてしまった 悲しみ の救済 • 規約・ドキュメントを更新していく仕組みづくり • レビュワーの育成 37 今後の展望
- 38. レビュワーの負担を分散・ボトルネック解消のために やっていること1 • 実装や設計の参考になる記事を読ませて、感想・意見・疑問を聞く • 「良いコード」に関するより深い対話 • SOLID 原則 • 驚き最小の原則 など • それらのために Laravel はどのような機能を提供してるのか？ 38 今後の展望 | レビュワーの育成
- 39. やっていること2 • レビューの際に自発的に考えさせるコミュニケーションを取る • 「こうした方がいい」ではなく「どうしたらいいだろう？」と問う • 「自己説得」（=自分で理解した状況）は行動の変化が発生しやすい 参考） 39 今後の展望 | レビュワーの育成 Chapter 2 メンタリングの技術