PHPInsightsで技術的負債の可視化始めました

私たちは「はたらこねっと」という求人広告サービスを開発しています。
「はたらこねっと」は2000年からサービスを開始しました。サービス開始以降何度かリプレイスを行っていますが、レガシーなコードがまだまだ残ってしまっている状況です。
そんなはたらこねっとに残ってしまっている技術的負債やレガシーコードを、PHPInsightsで可視化する取り組みを開始しました。
本トークでは、PHPInsightsを利用してコードを解析し、技術的負債を特定する方法について紹介します。
技術的負債の可視化にご興味のある方におすすめのトークです！

Transcript

1. PHPInsightsで 技術的負債の可視化 始めました ディップ株式会社　はたらこねっと開発課 赤堀 海
2. アジェンダ 01. 自己紹介 02. 発表の背景 03. 複雑度の可視化 04. 重み（優先度）を出す 05. 今後の展望 06. まとめ 2

3. 01. 自己紹介

4. 自己紹介 • 名前：赤堀　海
 
 • 会社名：ディップ株式会社/はたらこねっと開発課
 
 • 担当業務：はたらこねっと求職者向けサイトの開発
 
 • 趣味：
 ・バンド（ギターボーカル） 
 ・ダンス（半年前から始めました！） 
 
 • 目指すエンジニア：歌って踊れるエンジニア 
 01 4

5. 総合求人情報サイト 6
 引用： https://www.hatarako.net https://www.dip-net.co.jp/service 社員・派遣・パートで
 お仕事探しをする求職者と求人企業 
 を繋ぐ日本最大級の求人サイトです。 
 01 はたらこねっとの紹介
6. 02. 発表の背景

7. 02 7
 発表の背景 はたらこねっとの開発チームでは、 昔の使っていない コードがそのまま放置さ れているね... コードが汚くて 実装しにくい... リファクタリング しないと... という言葉よく耳にしました。
8. 02 はたらこねっとのリファクタリング課題 8
 ①どのファイルにどれくらいの量の負債があるのか把握できていない。 ②どのファイルからリファクタリングを始めていいのか分からない。 ③リファクタリングをする効果が見えにくいため優先度が低くなってしまっている。 

9. 03. 複雑度の可視化

10. 03 負債の可視化 10
 →技術的負債をファイルごとに数値化しよう！ Code（コードの評価）、Complexity（複雑さの評価）、Architecture（アーキテクチャの評価）、Style（コーディングスタイルの評価） の4項目を、パーセンテージで評価してくれる静的解析ツール。 PHP Insightsとは？ 循環的複雑度（サイクロマティック複雑度）とは？ ソフトウェア測定法の一つでソースコードがどれぐらい複雑であるかをメソッド単位で数値にして表す指標。
 （計測方法の詳細はそれ自体複雑ですが）基本的には「if/else・for・switch」などの分岐やループが増えるに従い数値が増えて いきます。（何も分岐が含まれないコードは「1」）
 PHP Insightsで「循環的複雑度」を出す ①どのファイルにどれくらいの量の負債があるのか把握できていない。
11. 03 循環的複雑度の重要性 11
 循環的複雑度が高い • プログラムは複雑になる
 • バグの混入リスク、発見されたバグの修 正にかかる時間が増加する
 循環的複雑度が低い • プログラムの可読性、保守性、移植性が 高まる
 • テストに必要なテストパターンの数が減り、カ バレッジも上げることができる

12. 03 循環的複雑度の指標 11

13. 03 循環的複雑度を出す 12
 PHP insightsのCyclomatic Complexity（循環的な複雑さ）を活用して循環的複雑度を
 出すことができます。

14. 03 負債の可視化 ①どのファイルにどれくらいの量の負債があるのか把握 できていない。 解決！！
 （複雑度が10以上のファイルの一覧を作成 ） ↓ 13

15. 04. 重み（優先度）を出す

16. →どのファイルで一番労力を使っているのかを明確にし、労力が高い順に優先度を決める！ 
 
 
 
 
 ⒈ Gitで直近1年間のファイル別変更回数を取得 
 
 ⒉ 「循環的複雑度 × 変更回数 = 労力（重み）」と考えて計算！ 
 
 ⒊ 労力の多いファイルから優先度をつける。 
 
 04 重み（優先度）を出す 15
 循環的複雑度 × ファイル変更回数 で開発の労力（重み）を出す ②どのファイルからリファクタリングを始めていいのか分からない。
17. 04 ファイル別変更回数（直近1年間）の取得 16
 Gitで以下のコマンドを実行することで git log --name-only --oneline | grep -v ' ' | sort | uniq -c | sort -n 
 ファイル別変更回数 (直近1年間)を取得できる
18. 04 「循環的複雑度 × 変更回数 ＝ 労力（重み）」を計算 17
 例） 循環的複雑度 35 変更回数（1年間） 10 × × ＝ 労力（重み） ＝ 350
19. 04 労力の多いファイルから優先度をつける 18
 ②どのファイルからリファクタリングを始めて いいか分からない。 解決！！

20. 05. 今後の展望

21. 05 今後の課題 22
 ③リファクタリングをする効果が見えにくいため優先度が低くなってしまっている。 
 解決する！！

22. 05 今後の動き 22
 ⒈ 複雑度や重みの数値をダッシュボード化することで更なる可視化を目指す。 
 
 
 
 ⒉ 一部の優先度が高いファイルからリファクタリングを開始し、メンバーの実装時間への影響を 計測する。
 
 
 
 ⒊ 定量的な評価を元にリファクタリングの優先度を上げる。
23. 06. まとめ

24. 　　①どのファイルにどれくらいの負債があるか把握できていない...
 
 　　　 
 
 　　②どのファイルからリファクタリングを始めるべきか見当がつかない...
 
 　　　 
 
 　　③リファクタリングの優先度が低く時間が取れない...
 
 　　　 
 06 24
 まとめ → 「循環的複雑度」を出して「負債の量」を把握する！ → 「重み」を出して「優先度」を決める！ → 一部でリファクタリングを行い、メンバーの 「実装時間への影響」を測定する。
 　測定した定量的な評価を元にリファクタリングの 「優先度」を上げる。

25. まずは、
 06 25
 終わりに 自分達のシステムに技術的負債がどれくらいあるのか
 「循環的複雑度」を出すだけでもやってみてください！
26. 綺麗なコード・負債のないコードを一緒 に目指しましょう！！
27. ご清聴ありがとうございました。
28. 25
 参考文献 過去の発表者はあまり参考文献を書いて 人が多め、必要なら記載するつもり