Submit Search
Upload
緊急Ques - コードのメトリクスに基づくリファクタリング戦略
•
Download as PPTX, PDF
•
0 likes
•
2,924 views
Tomoki Kuriyama
Follow
大規模なコードベースのリファクタリング戦略を、コード自体のメトリクスを元にして立案しているプラクティスを紹介します。
Read less
Read more
Software
Report
Share
Report
Share
1 of 40
Download now
Recommended
Qiita Night 足場固めからやるマイクロサービス
Qiita Night 足場固めからやるマイクロサービス
Tomoki Kuriyama
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
Atsushi Nakamura
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
Recommended
Qiita Night 足場固めからやるマイクロサービス
Qiita Night 足場固めからやるマイクロサービス
Tomoki Kuriyama
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
Atsushi Nakamura
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
増田 亨
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
DockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
Kenjiro Kubota
リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計
増田 亨
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
Fumihiko Kinoshita
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
IMJ Corporation
くま(Kuma)でメッシュなマイクロサービス
くま(Kuma)でメッシュなマイクロサービス
ssuser6b3f181
More Related Content
What's hot
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
増田 亨
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
DockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
Kenjiro Kubota
リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計
増田 亨
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
Fumihiko Kinoshita
What's hot
(20)
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
DockerコンテナでGitを使う
DockerコンテナでGitを使う
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Redisの特徴と活用方法について
Redisの特徴と活用方法について
テストコードの DRY と DAMP
テストコードの DRY と DAMP
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
Similar to 緊急Ques - コードのメトリクスに基づくリファクタリング戦略
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
IMJ Corporation
くま(Kuma)でメッシュなマイクロサービス
くま(Kuma)でメッシュなマイクロサービス
ssuser6b3f181
Cloud Native市場動向およびRancher Labsが提供するKubernetes Everywhere戦略について
Cloud Native市場動向およびRancher Labsが提供するKubernetes Everywhere戦略について
Junji Nishihara
Tech Dojo 02/09 IBM Japan CSM
Tech Dojo 02/09 IBM Japan CSM
勇 黒沢
祝GA、 Service Fabric 概要
祝GA、 Service Fabric 概要
Takekazu Omi
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
Yusuke Suzuki
リクルートのビッグデータ活用基盤とデータ活用に向けた取組み
リクルートのビッグデータ活用基盤とデータ活用に向けた取組み
Recruit Technologies
ハイブリットクラウド環境におけるモダンアプリケーション開発
ハイブリットクラウド環境におけるモダンアプリケーション開発
政雄 金森
JCBの Payment as a Service 実現にむけたゼロベースの組織変革とテクニカル・イネーブラー(NTTデータ テクノロジーカンファレンス ...
JCBの Payment as a Service 実現にむけたゼロベースの組織変革とテクニカル・イネーブラー(NTTデータ テクノロジーカンファレンス ...
NTT DATA Technology & Innovation
New IP へのステップ その1) Fabric – すべての基本はファブリックにあり
New IP へのステップ その1) Fabric – すべての基本はファブリックにあり
Brocade
[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight
[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight
Amazon Web Services Japan
Servcie Fabric and Cloud Design Pattern
Servcie Fabric and Cloud Design Pattern
Takekazu Omi
JTF2018 FIWARE x robot x IoT
JTF2018 FIWARE x robot x IoT
Nobuyuki Matsui
クラウド鎖国からクラウド維新へ
クラウド鎖国からクラウド維新へ
Cybozucommunity
クラウド時代にこそ求められるIt部門の役割
クラウド時代にこそ求められるIt部門の役割
Yusuke Oi
今更ながらの「マイクロサービス」
今更ながらの「マイクロサービス」
Hideaki Tokida
サーバーレスやマイクロサービスへの"チャレンジ"を後押ししてくれるセッションを紹介
サーバーレスやマイクロサービスへの"チャレンジ"を後押ししてくれるセッションを紹介
Yuta Matsumura
2018/9/11 SAP on AWS お客様事例セミナー@東京(BeeX資料1/2)
2018/9/11 SAP on AWS お客様事例セミナー@東京(BeeX資料1/2)
BeeX.inc
クラウド化後のITサービス向上とは
クラウド化後のITサービス向上とは
UNIRITA Incorporated
「明日の認証会議 3」講演用スライド 20141002(配布用)
「明日の認証会議 3」講演用スライド 20141002(配布用)
マジセミ by (株)オープンソース活用研究所
Similar to 緊急Ques - コードのメトリクスに基づくリファクタリング戦略
(20)
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
くま(Kuma)でメッシュなマイクロサービス
くま(Kuma)でメッシュなマイクロサービス
Cloud Native市場動向およびRancher Labsが提供するKubernetes Everywhere戦略について
Cloud Native市場動向およびRancher Labsが提供するKubernetes Everywhere戦略について
Tech Dojo 02/09 IBM Japan CSM
Tech Dojo 02/09 IBM Japan CSM
祝GA、 Service Fabric 概要
祝GA、 Service Fabric 概要
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
リクルートのビッグデータ活用基盤とデータ活用に向けた取組み
リクルートのビッグデータ活用基盤とデータ活用に向けた取組み
ハイブリットクラウド環境におけるモダンアプリケーション開発
ハイブリットクラウド環境におけるモダンアプリケーション開発
JCBの Payment as a Service 実現にむけたゼロベースの組織変革とテクニカル・イネーブラー(NTTデータ テクノロジーカンファレンス ...
JCBの Payment as a Service 実現にむけたゼロベースの組織変革とテクニカル・イネーブラー(NTTデータ テクノロジーカンファレンス ...
New IP へのステップ その1) Fabric – すべての基本はファブリックにあり
New IP へのステップ その1) Fabric – すべての基本はファブリックにあり
[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight
[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight
Servcie Fabric and Cloud Design Pattern
Servcie Fabric and Cloud Design Pattern
JTF2018 FIWARE x robot x IoT
JTF2018 FIWARE x robot x IoT
クラウド鎖国からクラウド維新へ
クラウド鎖国からクラウド維新へ
クラウド時代にこそ求められるIt部門の役割
クラウド時代にこそ求められるIt部門の役割
今更ながらの「マイクロサービス」
今更ながらの「マイクロサービス」
サーバーレスやマイクロサービスへの"チャレンジ"を後押ししてくれるセッションを紹介
サーバーレスやマイクロサービスへの"チャレンジ"を後押ししてくれるセッションを紹介
2018/9/11 SAP on AWS お客様事例セミナー@東京(BeeX資料1/2)
2018/9/11 SAP on AWS お客様事例セミナー@東京(BeeX資料1/2)
クラウド化後のITサービス向上とは
クラウド化後のITサービス向上とは
「明日の認証会議 3」講演用スライド 20141002(配布用)
「明日の認証会議 3」講演用スライド 20141002(配布用)
緊急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
株式会社カカクコムの栗山です。 本日の発表タイトルは「コードのメトリクスに基づくリファクタリング戦略」です。 よろしくお願いします。
サクッと私の自己紹介です。 Qiita などソーシャルメディアでは id: weakboson として活動してます。 2019年からマイクロサービス化チームでやってます。 最近のお仕事は一部Qiitaで公開しています。
本日のお品書きでございます。
最初に食べログの紹介をさせてください。 食べログは日本最大級のレストラン検索・予約サイトで、レストランの口コミや予約の他に、現在は飲食店DX、モバイルオーダーや食材の仕入、 それにお取り寄せECの食べログモールもやっておりまして、外食産業のインフラ、エコシステムのようなサービスになってきています。
それともう一つ課題を挙げると、食べログはマイクロサービス化の文脈で「分散されたモノリス」という状態にあります。 これは食べログ本体のリポジトリの一部のスクショで、黄色く囲んだフォルダ1つ1つがRailsアプリで社内ではサブシステムと呼んでいるのですが、緑で囲んだ共有コードに依存していて、独立したデプロイが実現できてません。 例えばここでrestaurantというアプリのためにtabelog_modelsに手を加えると、smartphoneというアプリに影響することがあるんですね。
ということでこの発表は、ISO 9162-1における……
内部品質をスコープにしてお話します!
お掃除の優先順位を考えるにあたりいくつかの先行事例を参考にしました。 1つ目の論文は「一般的に重複コードはソフトウェアの修正作業量を増大させるおそれがあると考えられている」という経験則のようなものをOSSのプロダクトで定量したものですが、 その経験則と真逆の結果が出ていて興味深いです。
鷲崎先生のアジャイル品質パターンでソースコードのメトリクスは重要なアジャイル品質メトリクスと紹介されいて、 考えうるメトリクスが網羅的に紹介されていました。 ちなみにこれは最近になって弊社の荻野さんに教えてもらって知ったもので、先に知っていればよかったですね。 私達がこの度計測したメトリクスはこの表の「コード変更」と「コード有効性」に相当するものだと解釈しました。
お掃除で得られるメリットが開発速度の向上と不具合の低減であると定義しますと、 「ビジネス的重要性」、「コードの見通し改善効果」そして「難易度」でスコアリングできると仮定しました。
ただこの3つのメトリクスは抽象度が高く、直接計測できません。
そこで、具体性が高く、計測が容易な下位のメトリクスを仮定しました。 ビジネス的に重要なコードは開発案件が多く、コードの更新回数が多いと仮定しました。 更新回数はコードをCMS管理していればかんたんに計測できます。 お掃除による見通し改善効果と難易度は共に実行されないコードの量と相関すると仮定しました。 実行されないコードはこのあとデッドコードと呼びます。 デッドコード量は多いほど見通し改善効果が大きいと仮定しましたが、多いほど難易度も高くなるトレードオフの関係にもあると仮定しました。
スコアリングに使いたいメトリクスと、計測できるメトリクスの関係はこのようになります。 先が太い矢印がスコアリングしたいメトリクスで、青い矢印が計測できるメトリクスです。
メトリクスが決まったのでいよいよ計測します。
このCoverageライブラリのoneshot_linesカバレッジモードは
それとスコアリングのためのコードのグループを定義します。 課題の説明で触れた「サブシステム」という単位をグループの単位としました。 共有コードは優先順位をつけづらいので除外しました。
デッドコード行数を縦軸、更新回数を横軸、コード総数を大きさでプロットするとこうなりました。 (※ の補足を説明)
なんかもう一目瞭然なんですが、更新回数とデッドコード行数には強い相関がありました。 大きくハズレているのは「飲食店向け管理機能」と「スマホアプリAPI」ですね。
これに前述のメトリクスの関係性を重ねるとこうなります。
(補記をそのまま説明)
というわけでこの4つのサブシステムをスコアリングして優先順位を決めます。 こういう取り掛かるべき対象が多いときはICEスコアリングの考えが使えると思います。 ICEスコアのICEは影響力、信頼度、容易性の英単語の頭文字です。
メトリクスがICEのどれに該当するか考えます。 コードの更新回数はシンプルに影響力 だと考えられますが、デッドコード量は影響力と難易度の両方でトレードオフになると考えられます。 信頼性は今の段階では差異なしと考えました。
4サブシステムと計測メトリクスを表にして、影響力、容易性を決めます。
ICEスコアリングでは明確な基準はなくてもよいそうで、ここまでかっちりメトリクス計測してきてなんですが、ヒアリングや組織体制も考慮してざっくりと付けてみます。 「影響力」は更新回数とデッドコード量共に最大の「SP版」に思い切って10を付けます。 「容易性」は数値上は「スマホアプリAPI」と「飲食店向け管理機能」が同程度ですが、 「スマホアプリAPI」の担当部署にはこのお掃除と近いミッションを持った「システム改善チーム」があるので高めに付けました。
Download now