Tweet
Tweet

Slide 1

Slide 1 text

© HataLuck and Person Inc. © HataLuck and Person Inc. PHPで品質と生産性向上を 目指すやり方 第3木曜LT会 #9 2024.09.19 千葉 茂 / @ohageeq

Slide 2

Slide 2 text

© HataLuck and Person Inc. 千葉　茂 / @ohageeq 執行役員 CTO 自己紹介 ■　技術: Kotlin, Go, AWS 💕 ■　好きなおはぎ: 今西軒(京都) ■　経歴: 2012年 サイバーエージェント入社 2022年 現職、業務委託入社 2023年 正社員入社 2024年 執行役員CTO就任

Slide 3

Slide 3 text

© HataLuck and Person Inc. 会社紹介 株式会社HataLuck and Person MISSION: 「はたらく」を楽しく VALUE: 「働きがい」を科学する シフトワーカーの潜在能力を 解放する 染谷　剛史 設立　 代表者 2017年1月 事業内容 リテールテック事業 はたらきがいテック事業 主要株主

Slide 4

Slide 4 text

© HataLuck and Person Inc. 事業内容 シフトワーカーの労働生産性を高める機能を ALL in ONEで提供

Slide 5

Slide 5 text

© HataLuck and Person Inc. アジェンダ ■ 背景: 開発の状況 ■ 品質および生産性向上のための取り組み PHPで品質と生産性向上を目指すやり方

Slide 6

Slide 6 text

© HataLuck and Person Inc. 背景: 開発の状況

Slide 7

Slide 7 text

© HataLuck and Person Inc. プロダクト変遷と現在 背景: 開発の状況 2018 2019 2020 2021 2022 2023 2024 マネージドサービス （Firebase） 主体に開発 外注／業務委託中心に PHPベースで開発 現はたLuck 正式リリース シフト機能 開発着手 プロパー不在 新基盤 開発開始 新基盤 開発停止 FS脱却 プロジェクト 新権限の 開発 シフト機能 1stリリース ● 基盤をゼロから作った人が20年時点で既にいない状況 ● マルチプロダクト戦略、MVP→PMF移行期で当時の意思決定 で技術スタックが増えてしまっている

Slide 8

Slide 8 text

© HataLuck and Person Inc. 当時の技術スタック 背景: 開発の状況 Infra Server MobileApp Tools Front ML/ DataPipline

Slide 9

Slide 9 text

© HataLuck and Person Inc. 改善前の開発状況 1. 大小含めて毎日バグ対応をしている 2. 緊急性が高いバグ以外のデプロイは２週間に１回 3. 古いバージョンの言語が使われているままである 4. プロジェクト間で利用言語が統一されていないことで、　 業務ロジック共通化ができない 背景: 開発の状況

Slide 10

Slide 10 text

© HataLuck and Person Inc. 自身の開発歴 ３年 背景: 開発の状況 １０年 5.x? 5.x? １年未満 動的型付け言語は経験がほとんどない 品質をあげることはできるのだろうか...

Slide 11

Slide 11 text

© HataLuck and Person Inc. 型付けが強い言語にフルリプレイスしよう！ 全ての実装コードにテストを書いてから機能開発だ！ とはならない

Slide 12

Slide 12 text

© HataLuck and Person Inc. 開発生産性指標を目安にする Four keysでELITEを目指す！ 背景: 開発の状況 https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

Slide 13

Slide 13 text

© HataLuck and Person Inc. なぜFour Keysを指標とするか ■ 失敗の変更率を下げる - 1ヶ月にかけるバグ対応を極力ゼロにする - %が上がった場合に機能開発を止める判断軸になる ■ デプロイ頻度を向上する - ２週間に１回ビッグバンデプロイがバグを仕込んでしまう 原因の１つ - 小さく失敗して積み上げられるバグの数を減らす ■ リードタイムを短くする - １つのPRの変更量を少ないとバグが気づくことができる - 後方互換があれば即座にmainブランチにマージしデプロイ される 背景: 開発の状況

Slide 14

Slide 14 text

© HataLuck and Person Inc. 品質および生産性向上のための取り組み

Slide 15

Slide 15 text

© HataLuck and Person Inc. PHPのバージョンを上げる ■ 型の表現や厳密さが向上した - type hintingが使える - Union型により型があいまいな箇所を型宣言できる - null safeが扱えるようになる 丸々1ヶ月リグレッションチェック→外部QA会社に依頼 大きな障害はなくバージョンアップ完了 生産性向上のための取り組み 変更前 変更後 PHP 7.3 PHP 8.2 Laravel 7 Laravel 9

Slide 16

Slide 16 text

© HataLuck and Person Inc. 失敗の変更率を下げる① Phpmetricsでコード品質を図る 生産性向上のための取り組み ■ 保守容易性指数 = MI (Maintainability Index Metrics) ■ 循環複雑度 = CCN (Cyclomatic complexity Number) 基準値より低いコードをCIで検知可能に 上記のような低品質なコードに対して ➔ テストコードの必須化 ➔ 開発者での確認手順の厳格化 ➔ リファクタリング工数を計画に盛り込む 指標を下回る = 変更による 障害が起きやすい！

Slide 17

Slide 17 text

© HataLuck and Person Inc. MI, CCNの指標 失敗の変更率を下げる① クラス数合計 数千クラス 変更不可能 2% 注力機能 0.7% 変更困難 注力機能 5% 10% メンテナンス不可能、テストが困難 MI <= 20以下 CCN >= 40以上

Slide 18

Slide 18 text

© HataLuck and Person Inc. 失敗の変更率を下げる② コード規約・静的解析 生産性向上のための取り組み 動的型付けを静的型付けとして扱えるように ■ PHPStan + LaraStan ■ php-cs-fixer 型の厳格検査を必須化しエディタやCIで見落とさない ➔ 新規コードは必須 ➔ 既存コードは修正できる範囲で対応する

Slide 19

Slide 19 text

© HataLuck and Person Inc. デプロイ頻度を向上する、リードタイムを短くする 生産性向上のための取り組み ■ 些細な変更でも後方互換があるものは毎日デプロイする (休日前、休日を除く) - 失敗の変更率を下げる取り組みがある前提で活きている ■ レビュー負荷を下げる - design doc等でモデリングや設計意図がわかるようにする phpunit-snapshot-assertions ■ リグレッションチェックを行えるようになる ■ 手を加えたところはテストコードを追加することで後退を 検知する

Slide 20

Slide 20 text

© HataLuck and Person Inc. 今後取り入れていきたいこと ■ Feature Flags - リードタイムや復旧時間を短くできる - 開発者の成果 = 本番デプロイと顧客提供 = 機能リリース を分けることができる ■ オブザーバビリティ監視 - Datadog等で全てのレイヤーでのリクエストを追えるよう にする - APIの呼び出し元、先の障害点の分析力が上がり将来課題 になる点を見通しが立てられる 生産性向上のための取り組み

Slide 21

Slide 21 text

© HataLuck and Person Inc. © HataLuck and Person Inc.