緊急Ques - コードのメトリクスに基づくリファクタリング戦略

© Kakaku.com Inc. All Rights Reserved. 1
コードのメトリクスに基づく
リファクタリング戦略
株式会社カカクコム食べログシステム本部
技術部マイクロサービス化チーム
栗山友樹
2022年09月29日(木)

栗山友樹 (weakboson)
マイクロサービス化チームリーダー兼テックリード
食べログではサービス開発、DevOpsを経て2019年からマイクロサービス
化チーム
マイクロサービス化チームの最近の公開活動
• 食べログのレストラン検索を支える Debezium と Apache Kafka – Qiita
• 食べログの内製Pub/Subメッセージング基盤をApache Kafkaにリプレイスした
話 – Qiita
• Qiita Night～モノリスからの脱却って実際どうなの？マイクロサービス化につい
て赤裸々に語る～

目次 1. 食べログの紹介と現在の課題
2. お掃除の効果をスコアリングするた
めのメトリクスの検討
3. 計測方法と結果
4. まとめ

食べログの紹介と現在の課題

食べログについて
日本最大級のレストラン検索・予約サイト
• 約9,300万 MAU (2022年6月)
• レストランの口コミ、写真
• レストランのネット予約
• 飲食店DX (予約台帳、食べログオーダー、食べログ仕入)
• お取り寄せEC (食べログモール)

食べログのシステム課題
食べログは今年で16年目のサービスで、Railsになってからは14年
が経過しています。

食べログは今年で16年目のサービスで、Railsになってからは14年
が経過しています。
Windows OSがVistaから11まで4回代替わりする年月です。
バージョン日本語版発売日
Windows XP 2001年9月6日
Windows Vista 2006年11月30日
Windows 7 2009年9月1日

これだけ歴史があればあちこちにガタが来ているのは当然で、そ
の問題の一つに密結合で低凝集な保守性の悪いアプリケーション
のコードが継続的開発の速度を下げ、不具合を増加させていると
いう実感があります。

独立してそうで独立してないRailsアプリ郡 (サブシステム)
Railsアプリ間で共有されるコード
分散されたモノリス
システムがコードやDBを共有することで結合していてる状態

食べログのコードを高凝集・疎結合で保守性の高いコードにリ
ファクタリングしたい！

この発表のスコープは……

この発表のスコープは……内部品質です！

リファクタリングの前にお掃除が必要
密結合で技術的負債が溜まったアプリケーションというのは散
らかった部屋のようなものです。散らかった部屋を見て「よし、
部屋を分けよう！」なんていきなり言いだす人はあまりいなく
て、まずはいらないものを捨てたり、ホコリや汚れをキレイに
掃除したり、収納グッズを買って用途ごとに置き場所を決めた
りするなどして、部屋を整理しようと考えるのが自然です。

お掃除の前に優先順位づけが必要
食べログのコード量は非常に多いので、全体を満遍なく掃除して
いては、メリットを得られる時期が遅くなります。メリットを最
大化できるように、どの部屋を先にお掃除するかの優先順位を付
ける必要があります。

お掃除の効果をスコアリングするた
めのメトリクスの検討

コードのメトリクスで品質を可視化する先行事例
• 堀田圭佑・佐野由希子・肥後芳樹・楠本真二: 修正頻度の比較に基づ
くソフトウェア修正作業量に対する重複コードの影響に関する調査, 情
報処理学会論文誌 Vol.52 No. 9 2788–2798 (Sep. 2011)
• Aki Asahara (Sider): Siderに強力な新機能が追加。コード品質の可視
化、リファクタリングすべきファイルの可視化が可能に, Sider社ブロ
グ (Jun. 2021)
お掃除の優先順位を考えるにあたりいくつかの先行事例を参考にした。

コードのメトリクスで品質を可視化する先行事例
• 鷲崎弘宜: 品質ダッシュボードを含むアジャイル品質保証の技術とパターン,
Test Engineers Meetup #4 (March 30, 2022) から引用

スコアリングするためのメトリクスを検討
難易度
メリット:開発速度の向上・不具合の低減
コードの見通し改善効果
ビジネス的重要性

難易度
ビジネス的重要性
抽象度が高い
直接計測できない

難易度
コードの更新回数
実行されないコードの量
(以下デッドコード量)
• 多いほど効果が大きい
• 多いほど難易度が高い
ビジネス的重要性開発案件の数
抽象度が高い
直接計測できない
具体性が高い
直接計測できる

スコアリングに使いたいメトリクスと計測できるメトリクスの関係
デッドコード量
更新回数
ビジネス的により重要
見
通
し
改
善
効
果
が
大
き
い
難
易
度
が
高
い
• 細い矢印: 計測可能なメトリクス
• 先の太い矢印: スコアリングに使いたいメトリクス

計測方法と結果

Rubyの標準ライブラリCoverageを使ってproduction環境で実際に
実行されたコードを計測して算出。
有効行数 - 実行された行数 = デッドコード行数

コードの更新回数
gitのマージコミット間の統計情報から算出。
追加・削除のどちらかあれば1回更新にカウント。
追加削除

スコアリングするためのコードのグループ化
課題の説明で触れた「サブシステム」をグループ単位とした。
独立してそうで独立してないRailsアプリ郡 (サブシステム)
共有コードは優先順位をつけづらいので除外

サブシステム単位でメトリクスをプロット
※ 管理系機能は除外
~たまにしか使われない機能があり、計測中に実
行されてないコードが本当に不要である信頼性が
低い

更新回数とデッドコード行数には強い相関が見え
る。

見
通
し
改
善
効
果
が
大
き
い
難
易
度
が
高
い
更新回数

更新回数
ビジネス的重要性を最重視して、プロットの右側
の集団をスコアリングすることにした。

ICEスコアリング
ICEスコア = 影響力 (Impact) x 信頼度 (Confidence) x 容易性 (Ease)
• 影響力: 改善対象の成果やKPIに与える効果の量
• 信頼度: 成功する可能性や確率
• 容易性: 実行しやすさ
それぞれ1~10の相対基準で付ける
ICEスコア (ICE score) とは、改善案や着手すべき施策が多い際に優
先すべきものを順序づける手法のこと。

ICEスコアリング
ICEスコア = 影響力 (Impact) x 信頼度 (Confidence) x 容易性 (Ease)
• 影響力: コードの更新回数、デッドコード量 (多いほど見通し改善効果大)
• 信頼度: いまの段階で差異なし
• 容易性: デッドコード量 (少ない程容易)
ICEスコア (ICE score) とは、改善案や着手すべき施策が多い際に優
先すべきものを順序づける手法のこと。

影響力・容易性を決める
優先
順位
サブシステム
更新
回数
デッド
コード
影響力容易性 ICEスコア
SP版 51 K 11.0 K
PC版レストラン機能 38 K 8.6 K
スマホアプリAPI 32 K 3.5 K
飲食店向け管理機能 31 K 4.2 K

影響力・容易性を決める
優先
順位
サブシステム
更新
回数
デッド
コード
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
体制を考慮して
高め

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版」が最大

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」から取り掛かることにした。

お掃除の進捗がわかるダッシュボードを用意
継続的に日次集計(毎朝9時)して
デッドコードの推移がわかるダッ
シュボードを用意。
お掃除の進捗が確認できる。

実はまだ本格的にお掃除を開始して
ないので、時間経過で減って見える
のは残念ながら改善の進捗ではない
はず。
おそらくproductionでもまれにしか
実行されないコードが新たに計測さ
れてデッドコードが減って見える。

SP版のデッドコードがたまに大き
く増加するのは、おそらく前日の
遅い時間に大きなコード変更が
あったせい。
集計時刻の朝9時までに実行され
てないコードが増大したせいだと
想定される。
(そして翌々日朝9時までには実行
されて、デッドコード量は同程度
の数値に落ち着く。)

まとめ

まとめ
できたこと
• 2つのメトリクス「デッドコード」と「コードの更新回数」が計
測できた
• メトリクスからICEスコアを付け、スコアを元にお掃除の優先順
位が決められた
これから
• ソースコードと統計数値化する前のデッドコードをマッピングし
て、お掃除できるコードを可視化・削除
• デッドコードをお掃除した内部品質改善効果を計測して仮説を検
証

緊急Ques - コードのメトリクスに基づくリファクタリング戦略

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 緊急Ques - コードのメトリクスに基づくリファクタリング戦略

Semelhante a 緊急Ques - コードのメトリクスに基づくリファクタリング戦略 (20)

緊急Ques - コードのメトリクスに基づくリファクタリング戦略

Notas do Editor