Downloaded 10 times
Uploaded byTomoki Kuriyama
緊急Ques - コードのメトリクスに基づくリファクタリング戦略
大規模なコードベースのリファクタリング戦略を、コード自体のメトリクスを元にして立案しているプラクティスを紹介します。
緊急Ques - コードのメトリクスに基づくリファクタリング戦略
- 1. © Kakaku.com Inc.All Rights Reserved. 1 コードのメトリクスに基づく リファクタリング戦略 株式会社カカクコム 食べログシステム本部 技術部 マイクロサービス化チーム 栗山 友樹 2022年09月29日(木)
- 2. © Kakaku.com Inc.All Rights Reserved. 2 栗山 友樹 (weakboson) マイクロサービス化チームリーダー兼テックリード 食べログではサービス開発、DevOpsを経て2019年からマイクロサービス 化チーム マイクロサービス化チームの最近の公開活動 • 食べログのレストラン検索を支える Debezium と Apache Kafka – Qiita • 食べログの内製Pub/Subメッセージング基盤をApache Kafkaにリプレイスした 話 – Qiita • Qiita Night～モノリスからの脱却って実際どうなの？マイクロサービス化につい て赤裸々に語る～
- 3. © Kakaku.com Inc.All Rights Reserved. 3 目次 1. 食べログの紹介と現在の課題 2. お掃除の効果をスコアリングするた めのメトリクスの検討 3. 計測方法と結果 4. まとめ
- 4. © Kakaku.com Inc.All Rights Reserved. 4 食べログの紹介と現在の課題
- 5. © Kakaku.com Inc.All Rights Reserved. 5 食べログについて 日本最大級のレストラン検索・予約サイト • 約9,300万 MAU (2022年6月) • レストランの口コミ、写真 • レストランのネット予約 • 飲食店DX (予約台帳、食べログオーダー、食べログ仕入) • お取り寄せEC (食べログモール)
- 6. © Kakaku.com Inc.All Rights Reserved. 6 食べログのシステム課題 食べログは今年で16年目のサービスで、Railsになってからは14年 が経過しています。
- 7. © Kakaku.com Inc.All Rights Reserved. 7 食べログのシステム課題 食べログは今年で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日
- 8. © Kakaku.com Inc.All Rights Reserved. 8 食べログのシステム課題 これだけ歴史があればあちこちにガタが来ているのは当然で、そ の問題の一つに密結合で低凝集な保守性の悪いアプリケーション のコードが継続的開発の速度を下げ、不具合を増加させていると いう実感があります。
- 9. © Kakaku.com Inc.All Rights Reserved. 9 食べログのシステム課題 独立してそうで独立してないRailsアプリ郡 (サブシステム) Railsアプリ間で共有されるコード 分散されたモノリス システムがコードやDBを共有することで結合していてる状態
- 10. © Kakaku.com Inc.All Rights Reserved. 10 食べログのシステム課題 食べログのコードを高凝集・疎結合で保守性の高いコードにリ ファクタリングしたい！
- 11. © Kakaku.com Inc.All Rights Reserved. 11 この発表のスコープは……
- 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 コードのメトリクスで品質を可視化する先行事例 • 堀田圭佑・佐野 由希子・肥後芳樹・楠本真二: 修正頻度の比較に基づ くソフトウェア修正作業量に対する重複コードの影響に関する調査, 情 報処理学会論文誌 Vol.52 No. 9 2788–2798 (Sep. 2011) • Aki Asahara (Sider): Siderに強力な新機能が追加。コード品質の可視 化、リファクタリングすべきファイルの可視化が可能に, Sider社ブロ グ (Jun. 2021) お掃除の優先順位を考えるにあたりいくつかの先行事例を参考にした。
- 17. © Kakaku.com Inc.All Rights Reserved. 17 コードのメトリクスで品質を可視化する先行事例 • 鷲崎弘宜: 品質ダッシュボードを含むアジャイル品質保証の技術とパターン, Test Engineers Meetup #4 (March 30, 2022) から引用
- 18. © Kakaku.com Inc.All Rights Reserved. 18 スコアリングするためのメトリクスを検討 難易度 メリット:開発速度の向上・不具合の低減 コードの見通し改善効果 ビジネス的重要性
- 19. © Kakaku.com Inc.All Rights Reserved. 19 スコアリングするためのメトリクスを検討 難易度 メリット:開発速度の向上・不具合の低減 コードの見通し改善効果 ビジネス的重要性 抽象度が高い 直接計測できない
- 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 デッドコード量 Rubyの標準ライブラリCoverageを使ってproduction環境で実際に 実行されたコードを計測して算出。 有効行数 - 実行された行数 = デッドコード行数
- 24. © Kakaku.com Inc.All Rights Reserved. 24 コードの更新回数 gitのマージコミット間の統計情報から算出。 追加・削除のどちらかあれば1回更新にカウント。 追加 削除
- 25. © Kakaku.com Inc.All Rights Reserved. 25 スコアリングするためのコードのグループ化 課題の説明で触れた「サブシステム 」をグループ単位とした。 独立してそうで独立してないRailsアプリ郡 (サブシステム) 共有コードは優先順位をつけづらいので除外
- 26. © Kakaku.com Inc.All Rights Reserved. 26 サブシステム単位でメトリクスをプロット ※ 管理系機能は除外 ~たまにしか使われない機能があり、計測中に実 行されてないコードが本当に不要である信頼性が 低い
- 27. © Kakaku.com Inc.All Rights Reserved. 27 サブシステム単位でメトリクスをプロット 更新回数とデッドコード行数には強い相関が見え る。
- 28. © Kakaku.com Inc.All Rights Reserved. 28 サブシステム単位でメトリクスをプロット ビジネス的により重要 見 通 し 改 善 効 果 が 大 き い 難 易 度 が 高 い デッドコード量 更新回数
- 29. © Kakaku.com Inc.All Rights Reserved. 29 サブシステム単位でメトリクスをプロット デッドコード量 更新回数 ビジネス的重要性を最重視して、プロットの右側 の集団をスコアリングすることにした。 ビジネス的により重要
- 30. © Kakaku.com Inc.All Rights Reserved. 30 ICEスコアリング ICEスコア = 影響力 (Impact) x 信頼度 (Confidence) x 容易性 (Ease) • 影響力: 改善対象の成果やKPIに与える効果の量 • 信頼度: 成功する可能性や確率 • 容易性: 実行しやすさ それぞれ1~10の相対基準で付ける ICEスコア (ICE score) とは、改善案や着手すべき施策が多い際に優 先すべきものを順序づける手法のこと。
- 31. © Kakaku.com Inc.All Rights Reserved. 31 ICEスコアリング ICEスコア = 影響力 (Impact) x 信頼度 (Confidence) x 容易性 (Ease) • 影響力: コードの更新回数、デッドコード量 (多いほど見通し改善効果大) • 信頼度: いまの段階で差異なし • 容易性: デッドコード量 (少ない程容易) ICEスコア (ICE score) とは、改善案や着手すべき施策が多い際に優 先すべきものを順序づける手法のこと。
- 32. © Kakaku.com Inc.All Rights Reserved. 32 影響力・容易性を決める 優先 順位 サブシステム 更新 回数 デッド コード 影響力 容易性 ICEスコア SP版 51 K 11.0 K PC版レストラン機能 38 K 8.6 K スマホアプリAPI 32 K 3.5 K 飲食店向け管理機能 31 K 4.2 K
- 33. © Kakaku.com Inc.All Rights Reserved. 33 影響力・容易性を決める 優先 順位 サブシステム 更新 回数 デッド コード 影響力 容易性 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 体制を考慮して 高め
- 34. © Kakaku.com Inc.All Rights Reserved. 34 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版」が最大
- 35. © Kakaku.com Inc.All Rights Reserved. 35 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」から取り掛かることにした。
- 36. © Kakaku.com Inc.All Rights Reserved. 36 お掃除の進捗がわかるダッシュボードを用意 継続的に日次集計(毎朝9時)して デッドコードの推移がわかるダッ シュボードを用意。 お掃除の進捗が確認できる。
- 37. © Kakaku.com Inc.All Rights Reserved. 37 お掃除の進捗がわかるダッシュボードを用意 実はまだ本格的にお掃除を開始して ないので、時間経過で減って見える のは残念ながら改善の進捗ではない はず。 おそらくproductionでもまれにしか 実行されないコードが新たに計測さ れてデッドコードが減って見える。
- 38. © Kakaku.com Inc.All Rights Reserved. 38 お掃除の進捗がわかるダッシュボードを用意 SP版のデッドコードがたまに大き く増加するのは、おそらく前日の 遅い時間に大きなコード変更が あったせい。 集計時刻の朝9時までに実行され てないコードが増大したせいだと 想定される。 (そして翌々日朝9時までには実行 されて、デッドコード量は同程度 の数値に落ち着く。)
- 39. © Kakaku.com Inc.All Rights Reserved. 39 まとめ
- 40. © Kakaku.com Inc.All Rights Reserved. 40 まとめ できたこと • 2つのメトリクス「デッドコード」と「コードの更新回数」が計 測できた • メトリクスからICEスコアを付け、スコアを元にお掃除の優先順 位が決められた これから • ソースコードと統計数値化する前のデッドコードをマッピングし て、お掃除できるコードを可視化・削除 • デッドコードをお掃除した内部品質改善効果を計測して仮説を検 証
Editor's Notes
- #2 株式会社カカクコムの栗山です。 本日の発表タイトルは「コードのメトリクスに基づくリファクタリング戦略」です。 よろしくお願いします。
- #3 サクッと私の自己紹介です。 Qiita などソーシャルメディアでは id: weakboson として活動してます。 2019年からマイクロサービス化チームでやってます。 最近のお仕事は一部Qiitaで公開しています。
- #4 本日のお品書きでございます。
- #6 最初に食べログの紹介をさせてください。 食べログは日本最大級のレストラン検索・予約サイトで、レストランの口コミや予約の他に、現在は飲食店DX、モバイルオーダーや食材の仕入、 それにお取り寄せECの食べログモールもやっておりまして、外食産業のインフラ、エコシステムのようなサービスになってきています。
- #10 それともう一つ課題を挙げると、食べログはマイクロサービス化の文脈で「分散されたモノリス」という状態にあります。 これは食べログ本体のリポジトリの一部のスクショで、黄色く囲んだフォルダ1つ1つがRailsアプリで社内ではサブシステムと呼んでいるのですが、緑で囲んだ共有コードに依存していて、独立したデプロイが実現できてません。 例えばここでrestaurantというアプリのためにtabelog_modelsに手を加えると、smartphoneというアプリに影響することがあるんですね。
- #12 ということでこの発表は、ISO 9162-1における……
- #13 内部品質をスコープにしてお話します！
- #17 お掃除の優先順位を考えるにあたりいくつかの先行事例を参考にしました。 1つ目の論文は「一般的に重複コードはソフトウェアの修正作業量を増大させるおそれがあると考えられている」という経験則のようなものをOSSのプロダクトで定量したものですが、 その経験則と真逆の結果が出ていて興味深いです。
- #18 鷲崎先生のアジャイル品質パターンでソースコードのメトリクスは重要なアジャイル品質メトリクスと紹介されいて、 考えうるメトリクスが網羅的に紹介されていました。 ちなみにこれは最近になって弊社の荻野さんに教えてもらって知ったもので、先に知っていればよかったですね。 私達がこの度計測したメトリクスはこの表の「コード変更」と「コード有効性」に相当するものだと解釈しました。
- #19 お掃除で得られるメリットが開発速度の向上と不具合の低減であると定義しますと、 「ビジネス的重要性」、「コードの見通し改善効果」そして「難易度」でスコアリングできると仮定しました。
- #20 ただこの3つのメトリクスは抽象度が高く、直接計測できません。
- #21 そこで、具体性が高く、計測が容易な下位のメトリクスを仮定しました。 ビジネス的に重要なコードは開発案件が多く、コードの更新回数が多いと仮定しました。 更新回数はコードをCMS管理していればかんたんに計測できます。 お掃除による見通し改善効果と難易度は共に実行されないコードの量と相関すると仮定しました。 実行されないコードはこのあとデッドコードと呼びます。 デッドコード量は多いほど見通し改善効果が大きいと仮定しましたが、多いほど難易度も高くなるトレードオフの関係にもあると仮定しました。
- #22 スコアリングに使いたいメトリクスと、計測できるメトリクスの関係はこのようになります。 先が太い矢印がスコアリングしたいメトリクスで、青い矢印が計測できるメトリクスです。
- #23 メトリクスが決まったのでいよいよ計測します。
- #24 このCoverageライブラリのoneshot_linesカバレッジモードは
- #26 それとスコアリングのためのコードのグループを定義します。 課題の説明で触れた「サブシステム」という単位をグループの単位としました。 共有コードは優先順位をつけづらいので除外しました。
- #27 デッドコード行数を縦軸、更新回数を横軸、コード総数を大きさでプロットするとこうなりました。 （※ の補足を説明）
- #28 なんかもう一目瞭然なんですが、更新回数とデッドコード行数には強い相関がありました。 大きくハズレているのは「飲食店向け管理機能」と「スマホアプリAPI」ですね。
- #29 これに前述のメトリクスの関係性を重ねるとこうなります。
- #30 （補記をそのまま説明）
- #31 というわけでこの4つのサブシステムをスコアリングして優先順位を決めます。 こういう取り掛かるべき対象が多いときはICEスコアリングの考えが使えると思います。 ICEスコアのICEは影響力、信頼度、容易性の英単語の頭文字です。
- #32 メトリクスがICEのどれに該当するか考えます。 コードの更新回数はシンプルに影響力 だと考えられますが、デッドコード量は影響力と難易度の両方でトレードオフになると考えられます。 信頼性は今の段階では差異なしと考えました。
- #33 4サブシステムと計測メトリクスを表にして、影響力、容易性を決めます。
- #34 ICEスコアリングでは明確な基準はなくてもよいそうで、ここまでかっちりメトリクス計測してきてなんですが、ヒアリングや組織体制も考慮してざっくりと付けてみます。 「影響力」は更新回数とデッドコード量共に最大の「SP版」に思い切って10を付けます。 「容易性」は数値上は「スマホアプリAPI」と「飲食店向け管理機能」が同程度ですが、 「スマホアプリAPI」の担当部署にはこのお掃除と近いミッションを持った「システム改善チーム」があるので高めに付けました。