PHPアプリの品質を(ある程度)保つために出来る事 ?組織編?
- 1. PHPアプリの品質を(ある程度) ? 保つために出来る事 ?～組織編?～ PHP ?カンファレンス ?2017 ? 2017/10/08 ? 株式会社? サイバード ? 三浦? 克浩
- 2. ?自?己紹介 ? 名前：三浦 ?克浩 ? ? Twitter ?ID：@MiuraKatsu ? ? 仕事：恋愛ゲーム ? ? 好きなフレームワーク： Laravel、Sails.js ? ? 浦和レッズ：
- 4. ? シリーズ? 通算14タイトル ? ? 海外展開? 5カ国? 6タイトル ? ? シリーズ以外? 4タイトル ? ? 展開プラットフォーム? 14プラットフォーム ?女性向け恋爱ノベルゲーム
- 5. 前提 ? 新規開発じゃなくて、既存運?用の話 ? ? ソシャゲ運?用＝毎?月なんかしらイベントがある ? ? サーバサイド(PHP)の話中?心 ? ? コードをどう変えるか？じゃなくて変えるため に何をしたのか？
- 6. ? タイトル毎に運?用チー ム ? ? それぞれチームリーダ とメンバー ? ? １チーム３?～６?人 ? ? 海外は別チームの場合 も 全体で５０?～８０?人のエンジニア
- 8. 品質をよくするには？ ? 神がコードを書けば品質が良くなる ? 神がコードレビューをすれば品質が良くなる ? 神だけがコードを書けば品質が良くなる ? 神がコードを書いた部分だけ品質が良くなる ? 神がすべてのコードレビューをすれば品質が 良くなる
- 11. 「神頼み」からの脱却 仕組み化
- 12. 何をしたか？ ? 横断チームの新設 ? ? 開発運?用サイクルの改善 ? ? 品質評価軸の可視化 ? ? 専?門チームの組成
- 14. 横断チームの役割 ? 共通系システムの維持メンテ ? ? 各チーム間の交流のHub ? ? ?日々のカイゼンだけではできないことをする
- 15. 何をしたか？ ? 横断チームの新設 ? ? 開発運?用サイクルの改善 ? ? 品質評価軸の可視化 ? ? 専?門チームの組成
- 16. Development ? -‐?? VCS(Git)によるソース管理 ? Deploy ? -‐?? ??自動デプロイ Service ?Monitoring ? -‐?? ステータス監視 ? 開発運?用サイクルの改善 横断チームが仕組み導?入
- 17. Development ? -‐?? VCS(Git)によるソース管理 ? -‐?? Pull ?Request ?運?用 ? Code ?Check ? ?-‐?? ?コードレビュー ? ?-‐?? ?コーディング規約 ? Deploy ? -‐?? ??自動デプロイ Service ?Monitoring ? -‐?? ステータス監視 ? -‐?? パフォーマンス監視 ? 開発運?用サイクルの改善
- 18. Development ? -‐?? VCS(Git)によるソース管理 ? -‐?? Pull ?Request ?運?用 ? Code ?Check ? ?-‐?? ?コードレビュー ? ?-‐?? ?コーディング規約 ? Test ? -‐?? Syntax ?チェック ? -‐?? ユニットテスト ? -‐?? 継続的インテグレーション Deploy ? -‐?? ??自動デプロイ Service ?Monitoring ? -‐?? ステータス監視 ? -‐?? パフォーマンス監視 ? 開発運?用サイクルの改善 ユニットテストよりCIが先
- 19. Development ? -‐?? VCS(Git)によるソース管理 ? -‐?? Pull ?Request ?運?用 ? Code ?Check ? ?-‐?? ?コードレビュー ? ?-‐?? ?コーディング規約 ? ?-‐?? ?静的解析 Test ? -‐?? Syntax ?チェック ? -‐?? ユニットテスト ? -‐?? 継続的インテグレーション Deploy ? -‐?? ??自動デプロイ Service ?Monitoring ? -‐?? ステータス監視 ? -‐?? パフォーマンス監視 ? -‐?? プロファイリング 開発運?用サイクルの改善
- 20. ?運?用チームで取り組みづらい事を横断チームが 仕組み化??自動化 ? ??自動化できたところに乗っかってもらう ? ? →導?入コストを下げる ? ?横断チームが作ることで標準化される ? ?あるんだから使ってよね、というプレッシャー ? 開発運?用サイクルの改善
- 21. GitHubでソース管理する ? →PullReq運?用ができる ? →→PullReqがくるからコードレビューする ? ?自動デプロイする ? →デプロイの前にCIが回せる ? →→CIが回るからユニットテスト書く 開発運?用サイクルの改善 ? 仕組みを?入れることで?行動が変わる
- 25. 何をしたか？ ? 横断チームの新設 ? ? 開発運?用サイクルの改善 ? ? 品質評価軸の可視化 ? ? 専?門チームの組成
- 26. 品質を定義する ? サービス的な品質：レスポンスが早い。サーバ 負荷が軽い。 ? ? コード的な品質：静的解析のスコアが?高い。テ ストカバレッジが?高い。 数値化できるものを計測する
- 27. 品質評価軸の可視化 ? 評価軸をチーム(タイトル)毎に可視化して公開 ? ? 静的解析スコア/テストカバレッジ/スロークエリー 発?生数/レスポンスタイム/etc ? ? ?自チームの数字が?見えるようになる： ? ? →?自分事になる ? ? 他チームの数字が?見えるようになる： ? ? →勝?手に競い合う
- 28. サービス的な評価軸計測 ? Zabbix? ：統合監視ツール。計測値の可視化 ? ? NewRelic：SaaS型パフォーマンス監視(有料) ? ? Monyog：MySQLモニタリングツール(有料) パフォーマンス監視＆プロファイリング
- 29. コード的な評価軸計測 ? Scrutinizer：静的解析SaaS(有料) ? ? SonarQube：静的解析ツール ? ? Coveralls：カバレッジレポート(有料) 単純に?高ければ?高評価でもない ? 古いタイトルには負の遺産も多い ? 変化を?見ている
- 30. 可視化 ? Zabbix/NewRelic：時系列でグラフ表?示 ? ? Chatwork：Alert/CI結果を通知 ? ? Wiki：バッチリスト。こんなやつ→
- 31. 何をしたか？ ? 横断チームの新設 ? ? 開発運?用サイクルの改善 ? ? 品質評価軸の可視化 ? ? 専?門チームの組成
- 32. 優先度 ? レスポンスが早くなると、売上は上がる ? ? スコアが上がっても、売上は上がらない まずはサービス品質の改善から
- 34. ? インフラチーム ? ? インフラチーム内に顿叠础
- 35. SQL道場 ? 毎週DBAによるSQL指導 ? ? 今週発?生したスロークエリー数の報告 ? ? 今週発?生したイケてないクエリーについての 指導
- 36. ORMの功罪 ? PHPerにはSQLが分からぬ ? ? かならずDB操作をしなければならぬ ? ? 功：PHPerでもDB操作ができる！ ? ? 罪：どんなクエリが吐かれるか、吐いてみない と分からない
- 37. DBAとの対話 ? DBAはクエリーしか?見ない ? ? プログラムの内容は知らない ? ? ゲーム仕様も知らない ? ? 開発者の?言い訳に同情しない
- 38. インフラ担当との対話 ? インフラはサーバ負荷しか?見ない ? ? 負荷理由（exイベント開始）を知らない ? ? サーバ増はコスト増 ? ? 開発者の?言い訳に同情しない
- 41. 改善?方法はひとつじゃない ? クエリーを修正する ? ? プログラムを修正する ? ? サーバをスケールアウト/スケールアップする ? ? RDBからKVSに切替える ? ? ゲーム仕様を変更する
- 43. まとめ ? 運?用だからカイゼンできる ? ? 仕組みを変えると?行動が変わる ? ? 「推測するな。計測せよ」 ? ? ?見える化?大事 ? ? 開発者以外を巻き込む
- 45. ご清聴ありがとうございました。