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
なぜPHPStanやPHP CodeSnifferを導入するのか 〜受託開発編〜
Search
くろきり
March 09, 2024
0
210
なぜPHPStanやPHP CodeSnifferを導入するのか 〜受託開発編〜
PHPerKaigi2024の登壇資料です。
くろきり
March 09, 2024
Tweet
Share
More Decks by くろきり
See All by くろきり
リアルISUCONの戦い方
kurokiri
0
150
PeachPieを使ってPHPを.NETで動かしてみた
kurokiri
0
220
少人数チーム開発でのレガシープロダクトとの向き合い方
kurokiri
0
1k
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
28
2k
Being A Developer After 40
akosma
90
590k
Practical Orchestrator
shlominoach
186
10k
Agile that works and the tools we love
rasmusluckow
328
21k
How GitHub (no longer) Works
holman
314
140k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
7
610
The Cost Of JavaScript in 2023
addyosmani
48
7.6k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Code Review Best Practice
trishagee
67
18k
Into the Great Unknown - MozCon
thekraken
35
1.7k
Documentation Writing (for coders)
carmenintech
69
4.7k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
11
610
Transcript
PHPerKaigi 2024 @9rokirishima なぜPHPStanやPHP CodeSnifferを導入するのか 〜受託開発編〜
自己紹介 • 緒方 大佑(おがた だいすけ) • X:くろきり(@9rokirishima) • 所属 ◦
Growfit株式会社 ◦ 開発やったりマネージャーやったり
弊社の現在状況 • 基本的に新規案件に適用 • 使用ツール ◦ PHP-CS-Fixer ◦ PHPStan(レベル6) •
BitbucketPipelineを使い、ブランチをpushする時にチェック が走る
なぜ導入したのか?
書き方が違うコード読むの辛い
• 案件跨いでレビューやデバッグしてると少しづつ違うのが読んでい てストレスになってくる ◦ なんなら同じプロダクト内で書き方が違う ◦ PSR-12で統一するというルールはあるけど形骸化 • 保守が弊社じゃなかったとしてもプロダクトの今後のために極力読 みやすいコードにして他社に渡したい
静的解析入れて読みやすいコードを保ちたい
導入までの道のり
メンバーに相談 次のPJから静的解析 入れたいんだけど… (めんどくさがられるかなぁ…)
メンバーに相談 わかりました! !?!?
あっさり導入決定!
これで全て上手くいく!
とはならない
適用したPJの体制 • PM(くろきり) • バックエンドチーム • フロントエンドチーム • ブロックチェーンチーム 静的解析の運用はバックエンドチームにお願いした
しばらく経って 納期迫ってるし修正に時間 かかるので全然使ってないです !? 導入してみてどう?
導入自体にはポジティブだけど 継続しようとするとことろにハードルがある 最初はやってたけど 納期が… うち保守やらないし… 他のところは入れなく てもやれてるし…
反省点 • いきなり運用をお願いしてしまったこと ◦ 急にまかせても上手くできないのは当たり前 • 完了の定義に静的解析によるチェックが含まれていなかった ◦ 「実装でやるべきこと」ではなく「新しい作業」が増えてるように 感じて負担になっている
改めていく
変えたこと • 自分の方でみんなが使える所まで設定とフォローを行う ◦ 新規案件用のベースブランチに予め組み込み、pushすれば 自動でBitbucketPipelineでチェックが走るように ◦ IDEの設定もドキュメントにまとめる • 実装完了の定義に静的解析によるチェックも含める
◦ 今の所は回っている ◦ 上手く進まない時にアラートが上がりやすくなってる
改善余地はまだまだあるけど 徐々によくなっていってる
• 契約形態は関係なくて、プロダクトに必要ならツール入れよう • 導入したいなら皆がやり切れる仕組みまで作る まとめ
ご清聴ありがとうございました!