Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PHPで品質と生産性向上を目指すやり方 / Improve quality and prod...
Search
Shigeru Chiba
September 19, 2024
Technology
0
26
PHPで品質と生産性向上を目指すやり方 / Improve quality and productivity with PHP
メタップスホールディングス主催
第三木曜LT会#9
にて登壇した内容です
Shigeru Chiba
September 19, 2024
Tweet
Share
More Decks by Shigeru Chiba
See All by Shigeru Chiba
エンジニア採用ノウハウ0から継続的な採用に至るまで / Try recruiting engineers
ohageeq
0
210
プロダクトの正しい「やめ方」/ How to make decision to stop developing product
ohageeq
1
260
Other Decks in Technology
See All in Technology
大幅アップデートされたRagas v0.2をキャッチアップ
os1ma
2
520
統計データで2024年の クラウド・インフラ動向を眺める
ysknsid25
2
840
サーバレスアプリ開発者向けアップデートをキャッチアップしてきた #AWSreInvent #regrowth_fuk
drumnistnakano
0
190
5分でわかるDuckDB
chanyou0311
10
3.2k
プロダクト開発を加速させるためのQA文化の築き方 / How to build QA culture to accelerate product development
mii3king
1
260
ゼロから創る横断SREチーム 挑戦と進化の軌跡
rvirus0817
2
260
UI State設計とテスト方針
rmakiyama
2
460
生成AIのガバナンスの全体像と現実解
fnifni
1
180
WACATE2024冬セッション資料(ユーザビリティ)
scarletplover
0
190
【re:Invent 2024 アプデ】 Prompt Routing の紹介
champ
0
140
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
150
あの日俺達が夢見たサーバレスアーキテクチャ/the-serverless-architecture-we-dreamed-of
tomoki10
0
430
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.5k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
66k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.3k
Speed Design
sergeychernyshev
25
670
Code Review Best Practice
trishagee
65
17k
For a Future-Friendly Web
brad_frost
175
9.4k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Optimizing for Happiness
mojombo
376
70k
Building Your Own Lightsaber
phodgson
103
6.1k
Transcript
© HataLuck and Person Inc. © HataLuck and Person Inc.
PHPで品質と生産性向上を 目指すやり方 第3木曜LT会 #9 2024.09.19 千葉 茂 / @ohageeq
© HataLuck and Person Inc. 千葉 茂 / @ohageeq 執行役員 CTO
自己紹介 ▪ 技術: Kotlin, Go, AWS 💕 ▪ 好きなおはぎ: 今西軒(京都) ▪ 経歴: 2012年 サイバーエージェント入社 2022年 現職、業務委託入社 2023年 正社員入社 2024年 執行役員CTO就任
© HataLuck and Person Inc. 会社紹介 株式会社HataLuck and Person MISSION:
「はたらく」を楽しく VALUE: 「働きがい」を科学する シフトワーカーの潜在能力を 解放する 染谷 剛史 設立 代表者 2017年1月 事業内容 リテールテック事業 はたらきがいテック事業 主要株主
© HataLuck and Person Inc. 事業内容 シフトワーカーの労働生産性を高める機能を ALL in ONEで提供
© HataLuck and Person Inc. アジェンダ ▪ 背景: 開発の状況 ▪
品質および生産性向上のための取り組み PHPで品質と生産性向上を目指すやり方
© HataLuck and Person Inc. 背景: 開発の状況
© HataLuck and Person Inc. プロダクト変遷と現在 背景: 開発の状況 2018 2019
2020 2021 2022 2023 2024 マネージドサービス (Firebase) 主体に開発 外注/業務委託中心に PHPベースで開発 現はたLuck 正式リリース シフト機能 開発着手 プロパー不在 新基盤 開発開始 新基盤 開発停止 FS脱却 プロジェクト 新権限の 開発 シフト機能 1stリリース • 基盤をゼロから作った人が20年時点で既にいない状況 • マルチプロダクト戦略、MVP→PMF移行期で当時の意思決定 で技術スタックが増えてしまっている
© HataLuck and Person Inc. 当時の技術スタック 背景: 開発の状況 Infra Server
MobileApp Tools Front ML/ DataPipline
© HataLuck and Person Inc. 改善前の開発状況 1. 大小含めて毎日バグ対応をしている 2. 緊急性が高いバグ以外のデプロイは2週間に1回
3. 古いバージョンの言語が使われているままである 4. プロジェクト間で利用言語が統一されていないことで、 業務ロジック共通化ができない 背景: 開発の状況
© HataLuck and Person Inc. 自身の開発歴 3年 背景: 開発の状況 10年
5.x? 5.x? 1年未満 動的型付け言語は経験がほとんどない 品質をあげることはできるのだろうか...
© HataLuck and Person Inc. 型付けが強い言語にフルリプレイスしよう! 全ての実装コードにテストを書いてから機能開発だ! とはならない
© HataLuck and Person Inc. 開発生産性指標を目安にする Four keysでELITEを目指す! 背景: 開発の状況
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
© HataLuck and Person Inc. なぜFour Keysを指標とするか ▪ 失敗の変更率を下げる -
1ヶ月にかけるバグ対応を極力ゼロにする - %が上がった場合に機能開発を止める判断軸になる ▪ デプロイ頻度を向上する - 2週間に1回ビッグバンデプロイがバグを仕込んでしまう 原因の1つ - 小さく失敗して積み上げられるバグの数を減らす ▪ リードタイムを短くする - 1つのPRの変更量を少ないとバグが気づくことができる - 後方互換があれば即座にmainブランチにマージしデプロイ される 背景: 開発の状況
© HataLuck and Person Inc. 品質および生産性向上のための取り組み
© HataLuck and Person Inc. PHPのバージョンを上げる ▪ 型の表現や厳密さが向上した - type
hintingが使える - Union型により型があいまいな箇所を型宣言できる - null safeが扱えるようになる 丸々1ヶ月リグレッションチェック→外部QA会社に依頼 大きな障害はなくバージョンアップ完了 生産性向上のための取り組み 変更前 変更後 PHP 7.3 PHP 8.2 Laravel 7 Laravel 9
© HataLuck and Person Inc. 失敗の変更率を下げる① Phpmetricsでコード品質を図る 生産性向上のための取り組み ▪ 保守容易性指数
= MI (Maintainability Index Metrics) ▪ 循環複雑度 = CCN (Cyclomatic complexity Number) 基準値より低いコードをCIで検知可能に 上記のような低品質なコードに対して ➔ テストコードの必須化 ➔ 開発者での確認手順の厳格化 ➔ リファクタリング工数を計画に盛り込む 指標を下回る = 変更による 障害が起きやすい!
© HataLuck and Person Inc. MI, CCNの指標 失敗の変更率を下げる① クラス数合計 数千クラス
変更不可能 2% 注力機能 0.7% 変更困難 注力機能 5% 10% メンテナンス不可能、テストが困難 MI <= 20以下 CCN >= 40以上
© HataLuck and Person Inc. 失敗の変更率を下げる② コード規約・静的解析 生産性向上のための取り組み 動的型付けを静的型付けとして扱えるように ▪
PHPStan + LaraStan ▪ php-cs-fixer 型の厳格検査を必須化しエディタやCIで見落とさない ➔ 新規コードは必須 ➔ 既存コードは修正できる範囲で対応する
© HataLuck and Person Inc. デプロイ頻度を向上する、リードタイムを短くする 生産性向上のための取り組み ▪ 些細な変更でも後方互換があるものは毎日デプロイする (休日前、休日を除く)
- 失敗の変更率を下げる取り組みがある前提で活きている ▪ レビュー負荷を下げる - design doc等でモデリングや設計意図がわかるようにする phpunit-snapshot-assertions ▪ リグレッションチェックを行えるようになる ▪ 手を加えたところはテストコードを追加することで後退を 検知する
© HataLuck and Person Inc. 今後取り入れていきたいこと ▪ Feature Flags -
リードタイムや復旧時間を短くできる - 開発者の成果 = 本番デプロイと顧客提供 = 機能リリース を分けることができる ▪ オブザーバビリティ監視 - Datadog等で全てのレイヤーでのリクエストを追えるよう にする - APIの呼び出し元、先の障害点の分析力が上がり将来課題 になる点を見通しが立てられる 生産性向上のための取り組み
© HataLuck and Person Inc. © HataLuck and Person Inc.