$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
静的解析ではじめる負債コード解消
Search
daiki1020
December 14, 2020
Programming
0
4.8k
静的解析ではじめる負債コード解消
daiki1020
December 14, 2020
Tweet
Share
Other Decks in Programming
See All in Programming
無秩序からの脱却 / Emergence from chaos
nrslib
2
11k
関数実行の裏側では何が起きているのか?
minop1205
1
360
分散DBって何者なんだ... Spannerから学ぶRDBとの違い
iwashi623
0
150
Evolving NEWT’s TypeScript Backend for the AI-Driven Era
xpromx
0
220
チーム開発の “地ならし"
konifar
8
6.6k
Combinatorial Interview Problems with Backtracking Solutions - From Imperative Procedural Programming to Declarative Functional Programming - Part 1
philipschwarz
PRO
0
110
Web エンジニアが JavaScript で AI Agent を作る / JSConf JP 2025 sponsor session
izumin5210
4
2.1k
『実践MLOps』から学ぶ DevOps for ML
nsakki55
2
500
20 years of Symfony, what's next?
fabpot
2
200
手軽に積ん読を増やすには?/読みたい本と付き合うには?
o0h
PRO
1
130
WebRTC と Rust と8K 60fps
tnoho
2
1.6k
Media Capture and Streams: W3C仕様と現場での知見
nowaki28
0
110
Featured
See All Featured
Designing for humans not robots
tammielis
254
26k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
990
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Mobile First: as difficult as doing things right
swwweet
225
10k
A designer walks into a library…
pauljervisheath
210
24k
4 Signs Your Business is Dying
shpigford
186
22k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
31
2.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.4k
Code Reviewing Like a Champion
maltzj
527
40k
Why You Should Never Use an ORM
jnunemaker
PRO
60
9.6k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Transcript
静的解析からはじめる 負債コード解消 株式会社ラクス 藤岡大樹
自己紹介 株式会社ラクス 開発本部 楽楽販売・労務開発課 藤岡大樹 入社3年目 業務内容:機能開発 サポート 上流設計 など
クラウド型販売管理システム 導入社数1,000社超 10年以上続くサービス Webデータベース ブラウザを使ってCRUDができる
販売管理業務など用途に特化したDBを作れる 構成 PHP + PostgreSQL
課題 長年続くサービスになると… 未使用の関数が放置 コメントと処理が違う そもそもコメントがない 1つの関数の役割が多い …
可読性の低下 開発効率が下がる
デグレコワイ 呼び出し元を辿っていくと 「これ使ってないやん」 関係ないと思ってたのに 共通ロジックなってるやん。。。 今の開発規約と合ってなくて 読みにくい
デグレコワイ 呼び出し元を辿っていくと 「これ使ってないやん」 関係ないと思ってたのに 共通ロジックなってるやん。。。 今の開発規約と合ってなくて 読みにくい 見送ろっか…
静的解析ではじめる負債コード解消 inspection 機能開発で触ったファイル内の検知箇所を併せて修正する
Inspectionってなに? 多くのテンプレートが用意されていてエラーレベルを選ぶだけ テンプレートを元に自分用にカスタマイズも可能!
Inspection活用事例① 未使用の変数や関数を検知 Settings > inspections ◦ PHP ◦ Unused ◦
Unused local variable ◦ Unused private method
Inspection活用事例② コメントがない関数を検知 Settings > inspections ◦ PHP ◦ PHPDocs ◦
Missing PHPDoc comment
Inspection活用事例③ 引数の数が一致していない 関数呼び出しを検知 Settings > inspections ◦ PHP ◦ Type
compatibility ◦ Parameter type
Inspection活用事例④ 自分でカスタマイズして検知 例)条件式の曖昧な比較(==)を検知したい! Settings > inspections ◦ General ◦ Structual
Search Inspection デモ
Inspection活用事例④ 自分でカスタマイズして検知(デモ内容) 例)条件式の曖昧な比較(==)を検知したい! 1. Optionsに追加する
Inspection活用事例④ 自分でカスタマイズして検知(デモ内容) 例)条件式の曖昧な比較(==)を検知したい! 2. 検知したい内容を入力する ◦ テンプレートをもとにカスタマイズもできる
Inspection活用事例④ 自分でカスタマイズして検知(デモ内容) 例)条件式の曖昧な比較(==)を検知したい! 3. テンプレート名を決める 4. 完了
結果 検知箇所を一気に修正するのではなく、触ったファイルと一緒に 修正することで効率を向上できた 余計なファイルを改めで査読する必要もなく、そこまで開発作業の影響に ならない 少しずつ着実に負債コードを減らせている すべてが解消するには時間がかかるが、デグレを起こさないよう慎重に
まとめ 自分たちで強いルールを作ることで負債コードが放置されるのを 防ぐよう工夫した PhpStormだけでも多様な静的解析ができる カスタマイズが可能なのでチーム特有のチェックができる みなさんも自分たちのルールを もう一度見直してみてはいかかでしょうか?
ご清聴 ありがとうございました