緊急Ques 「食べログの品質ダッシュボード」-コードのメトリクスに基づくリファクタリング戦略

大規模なコードベースのリファクタリング戦略を、コード自体のメトリクスを元にして立案しているプラクティスを紹介します。

Transcript

1. © Kakaku.com Inc. All Rights Reserved. 1 コードのメトリクスに基づく リファクタリング戦略 株式会社カカクコム ⾷べログシステム本部 技術部 マイクロサービス化チーム 栗⼭ 友樹 2022年09⽉29⽇(⽊)
2. © Kakaku.com Inc. All Rights Reserved. 2
3. © Kakaku.com Inc. All Rights Reserved. 3
4. © Kakaku.com Inc. All Rights Reserved. 4 栗⼭ 友樹 (weakboson) マイクロサービス化チームリーダー兼テックリード ⾷べログではサービス開発、DevOpsを経て2019年からマイクロサービス 化チーム マイクロサービス化チームの最近の公開活動 • ⾷べログのレストラン検索を⽀える Debezium と Apache Kafka ‒ Qiita • ⾷べログの内製Pub/Subメッセージング基盤をApache Kafkaにリプレイスした 話 ‒ Qiita • Qiita Night〜モノリスからの脱却って実際どうなの？マイクロサービス化につい て⾚裸々に語る〜
5. © Kakaku.com Inc. All Rights Reserved. 5 ⽬次 1. ⾷べログの紹介と現在の課題 2. お掃除の効果をスコアリングするた めのメトリクスの検討 3. 計測⽅法と結果 4. まとめ
6. © Kakaku.com Inc. All Rights Reserved. 6 ⾷べログの紹介と現在の課題
7. © Kakaku.com Inc. All Rights Reserved. 7 ⾷べログについて ⽇本最⼤級のレストラン検索・予約サイト • 約9,300万 MAU (2022年6⽉) • レストランの⼝コミ、写真 • レストランのネット予約 • 飲⾷店DX (予約台帳、⾷べログオーダー、⾷べログ仕⼊) • お取り寄せEC (⾷べログモール)
8. © Kakaku.com Inc. All Rights Reserved. 8 ⾷べログのシステム課題 ⾷べログは今年で16年⽬のサービスで、Railsになってからは14年 が経過しています。
9. © Kakaku.com Inc. All Rights Reserved. 9 ⾷べログのシステム課題 ⾷べログは今年で16年⽬のサービスで、Railsになってからは14年 が経過しています。 Windows OSがVistaから11まで4回代替わりする年⽉です。 バージョン ⽇本語版発売⽇ Windows XP 2001年9⽉6⽇ Windows Vista 2006年11⽉30⽇ Windows 7 2009年9⽉1⽇ Windows 8 2012年8⽉16⽇ Windows 10 2015年7⽉29⽇ Windows 11 2021年10⽉5⽇
10. © Kakaku.com Inc. All Rights Reserved. 10 ⾷べログのシステム課題 これだけ歴史があればあちこちにガタが来ているのは当然で、そ の問題の⼀つに密結合で低凝集な保守性の悪いアプリケーション のコードが継続的開発の速度を下げ、不具合を増加させていると いう実感があります。
11. © Kakaku.com Inc. All Rights Reserved. 11 ⾷べログのシステム課題 独⽴してそうで独⽴してないRailsアプリ郡 (サブシステム) Railsアプリ間で共有されるコード 分散されたモノリス システムがコードやDBを共有することで結合していてる状態
12. © Kakaku.com Inc. All Rights Reserved. 12 ⾷べログのシステム課題 ⾷べログのコードを⾼凝集・疎結合で保守性の⾼いコードにリ ファクタリングしたい！
13. © Kakaku.com Inc. All Rights Reserved. 13 この発表のスコープは……
14. © Kakaku.com Inc. All Rights Reserved. 14 この発表のスコープは……内部品質です！
15. © Kakaku.com Inc. All Rights Reserved. 15 リファクタリングの前にお掃除が必要 密結合で技術的負債が溜まったアプリケーションというのは散 らかった部屋のようなものです。散らかった部屋を⾒て「よし、 部屋を分けよう！」なんていきなり⾔いだす⼈はあまりいなく て、まずはいらないものを捨てたり、ホコリや汚れをキレイに 掃除したり、収納グッズを買って⽤途ごとに置き場所を決めた りするなどして、部屋を整理しようと考えるのが⾃然です。
16. © Kakaku.com Inc. All Rights Reserved. 16 お掃除の前に優先順位づけが必要 ⾷べログのコード量は⾮常に多いので、全体を満遍なく掃除して いては、メリットを得られる時期が遅くなります。メリットを最 ⼤化できるように、どの部屋を先にお掃除するかの優先順位を付 ける必要があります。
17. © Kakaku.com Inc. All Rights Reserved. 17 お掃除の効果をスコアリングするた めのメトリクスの検討
18. © Kakaku.com Inc. All Rights Reserved. 18 コードのメトリクスで品質を可視化する先⾏事例 • 堀⽥圭佑・佐野 由希⼦・肥後芳樹・楠本真⼆: 修正頻度の⽐較に基づ くソフトウェア修正作業量に対する重複コードの影響に関する調査, 情 報処理学会論⽂誌 Vol.52 No. 9 2788‒2798 (Sep. 2011) • Aki Asahara (Sider): Siderに強⼒な新機能が追加。コード品質の可視 化、リファクタリングすべきファイルの可視化が可能に, Sider社ブロ グ (Jun. 2021) お掃除の優先順位を考えるにあたりいくつかの先⾏事例を参考にした。
19. © Kakaku.com Inc. All Rights Reserved. 19 コードのメトリクスで品質を可視化する先⾏事例 • 鷲崎弘宜: 品質ダッシュボードを含むアジャイル品質保証の技術とパターン, Test Engineers Meetup #4 (March 30, 2022) から引⽤
20. © Kakaku.com Inc. All Rights Reserved. 20 スコアリングするためのメトリクスを検討 難易度 メリット:開発速度の向上・不具合の低減 コードの⾒通し改善効果 ビジネス的重要性
21. © Kakaku.com Inc. All Rights Reserved. 21 スコアリングするためのメトリクスを検討 難易度 メリット:開発速度の向上・不具合の低減 コードの⾒通し改善効果 ビジネス的重要性 抽象度が⾼い 直接計測できない
22. © Kakaku.com Inc. All Rights Reserved. 22 スコアリングするためのメトリクスを検討 難易度 メリット:開発速度の向上・不具合の低減 コードの更新回数 実⾏されないコードの量 (以下デッドコード量) • 多いほど効果が⼤きい • 多いほど難易度が⾼い コードの⾒通し改善効果 ビジネス的重要性 開発案件の数 抽象度が⾼い 直接計測できない 具体性が⾼い 直接計測できる
23. © Kakaku.com Inc. All Rights Reserved. 23 スコアリングに使いたいメトリクスと計測できるメトリクスの関係 デッドコード量 更新回数 ビジネス的により重要 ⾒ 通 し 改 善 効 果 が ⼤ き い 難 易 度 が ⾼ い • 細い⽮印: 計測可能なメトリクス • 先の太い⽮印: スコアリングに使いたいメトリクス
24. © Kakaku.com Inc. All Rights Reserved. 24 計測⽅法と結果
25. © Kakaku.com Inc. All Rights Reserved. 25 デッドコード量 Rubyの標準ライブラリCoverageを使ってproduction環境で実際に 実⾏されたコードを計測して算出。 有効⾏数 - 実⾏された⾏数 = デッドコード⾏数
26. © Kakaku.com Inc. All Rights Reserved. 26 コードの更新回数 gitのマージコミット間の統計情報から算出。 追加・削除のどちらかあれば1回更新にカウント。 追加 削除
27. © Kakaku.com Inc. All Rights Reserved. 27 スコアリングするためのコードのグループ化 課題の説明で触れた「サブシステム 」をグループ単位とした。 独⽴してそうで独⽴してないRailsアプリ郡 (サブシステム) 共有コードは優先順位をつけづらいので除外
28. © Kakaku.com Inc. All Rights Reserved. 28 サブシステム単位でメトリクスをプロット ※ 管理系機能は除外 ~たまにしか使われない機能があり、計測中に実 ⾏されてないコードが本当に不要である信頼性が 低い
29. © Kakaku.com Inc. All Rights Reserved. 29 サブシステム単位でメトリクスをプロット 更新回数とデッドコード⾏数には強い相関が⾒え る。
30. © Kakaku.com Inc. All Rights Reserved. 30 サブシステム単位でメトリクスをプロット ビジネス的により重要 ⾒ 通 し 改 善 効 果 が ⼤ き い 難 易 度 が ⾼ い デッドコード量 更新回数
31. © Kakaku.com Inc. All Rights Reserved. 31 サブシステム単位でメトリクスをプロット デッドコード量 更新回数 ビジネス的重要性を最重視して、プロットの右側 の集団をスコアリングすることにした。 ビジネス的により重要
32. © Kakaku.com Inc. All Rights Reserved. 32 ICEスコアリング ICEスコア = 影響⼒ (Impact) x 信頼度 (Confidence) x 容易性 (Ease) • 影響⼒: 改善対象の成果やKPIに与える効果の量 • 信頼度: 成功する可能性や確率 • 容易性: 実⾏しやすさ それぞれ1~10の相対基準で付ける ICEスコア (ICE score) とは、改善案や着⼿すべき施策が多い際に優 先すべきものを順序づける⼿法のこと。
33. © Kakaku.com Inc. All Rights Reserved. 33 ICEスコアリング ICEスコア = 影響⼒ (Impact) x 信頼度 (Confidence) x 容易性 (Ease) • 影響⼒: コードの更新回数、デッドコード量 (多いほど⾒通し改善効果⼤) • 信頼度: いまの段階で差異なし • 容易性: デッドコード量 (少ない程容易) ICEスコア (ICE score) とは、改善案や着⼿すべき施策が多い際に優 先すべきものを順序づける⼿法のこと。
34. © Kakaku.com Inc. All Rights Reserved. 34 影響⼒・容易性を決める 優先 順位 サブシステム 更新 回数 デッド コード 影響⼒ 容易性 ICEスコア SP版 51 K 11.0 K PC版レストラン機能 38 K 8.6 K スマホアプリAPI 32 K 3.5 K 飲⾷店向け管理機能 31 K 4.2 K
35. © Kakaku.com Inc. All Rights Reserved. 35 影響⼒・容易性を決める 優先 順位 サブシステム 更新 回数 デッド コード 影響⼒ 容易性 ICEスコア SP版 51 K 11.0 K 10 3 PC版レストラン機能 38 K 8.6 K 7 4 スマホアプリAPI 32 K 3.5 K 3 8 飲⾷店向け管理機能 31 K 4.2 K 3 6 体制を考慮して ⾼め
36. © Kakaku.com Inc. All Rights Reserved. 36 ICEスコアを算出 優先 順位 サブシステム 更新 回数 デッド コード 影響⼒ 容易性 ICEスコア SP版 51 K 11.0 K 10 3 30 PC版レストラン機能 38 K 8.6 K 7 4 28 スマホアプリAPI 32 K 3.5 K 3 8 24 飲⾷店向け管理機能 31 K 4.2 K 3 6 18 ICEスコアは「SP版」が最⼤
37. © Kakaku.com Inc. All Rights Reserved. 37 ICEスコアを元に優先順位を決める 優先 順位 サブシステム 更新 回数 デッド コード 影響⼒ 容易性 ICEスコア 2 SP版 51 K 11.0 K 10 3 30 3 PC版レストラン機能 38 K 8.6 K 7 4 28 1 スマホアプリAPI 32 K 3.5 K 3 8 24 4 飲⾷店向け管理機能 31 K 4.2 K 3 6 18 ⼩さく PoC をしたいので、ICEスコアは「SP版」が最⼤ですが「スマホアプ リAPI」から取り掛かることにした。
38. © Kakaku.com Inc. All Rights Reserved. 38 お掃除の進捗がわかるダッシュボードを⽤意 継続的に⽇次集計(毎朝9時)して デッドコードの推移がわかるダッ シュボードを⽤意。 お掃除の進捗が確認できる。
39. © Kakaku.com Inc. All Rights Reserved. 39 お掃除の進捗がわかるダッシュボードを⽤意 実はまだ本格的にお掃除を開始して ないので、時間経過で減って⾒える のは残念ながら改善の進捗ではない はず。 おそらくproductionでもまれにしか 実⾏されないコードが新たに計測さ れてデッドコードが減って⾒える。
40. © Kakaku.com Inc. All Rights Reserved. 40 お掃除の進捗がわかるダッシュボードを⽤意 SP版のデッドコードがたまに⼤き く増加するのは、おそらく前⽇の 遅い時間に⼤きなコード変更が あったせい。 集計時刻の朝9時までに実⾏され てないコードが増⼤したせいだと 想定される。 (そして翌々⽇朝9時までには実⾏ されて、デッドコード量は同程度 の数値に落ち着く。)
41. © Kakaku.com Inc. All Rights Reserved. 41 まとめ
42. © Kakaku.com Inc. All Rights Reserved. 42 まとめ できたこと • 2つのメトリクス「デッドコード」と「コードの更新回数」が計 測できた • メトリクスからICEスコアを付け、スコアを元にお掃除の優先順 位が決められた これから • ソースコードと統計数値化する前のデッドコードをマッピングし て、お掃除できるコードを可視化・削除 • デッドコードをお掃除した内部品質改善効果を計測して仮説を検 証