Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
到達可能性チェッカーを品質改善に活用する/use-ReachableChecker-for-f...
Search
t-mario-y
April 16, 2023
Programming
0
21k
到達可能性チェッカーを品質改善に活用する/use-ReachableChecker-for-frequent-refactoring
2023-04-16 freee技術の日
https://freee.connpass.com/event/274961/
t-mario-y
April 16, 2023
Tweet
Share
More Decks by t-mario-y
See All by t-mario-y
開発者に感謝される品質チームになる
tmyrhystic
0
180
MusicXMLを校正する
tmyrhystic
0
65
Other Decks in Programming
See All in Programming
chibiccをCILに移植した結果 (NGK2025S版)
kekyo
PRO
0
190
令和7年版 あなたが使ってよいフロントエンド機能とは
mugi_uno
12
6.1k
自動で //nolint を挿入する取り組み / Gopher's Gathering
utgwkk
1
170
Compose でデザインと実装の差異を減らすための取り組み
oidy
1
240
Lookerは可視化だけじゃない。UIコンポーネントもあるんだ!
ymd65536
1
140
GitHub CopilotでTypeScriptの コード生成するワザップ
starfish719
28
6.1k
SRE、開発、QAが協業して挑んだリリースプロセス改革@SRE Kaigi 2025
nealle
1
3.4k
2024年のkintone API振り返りと2025年 / kintone API look back in 2024
tasshi
0
180
いりゃあせ、PHPカンファレンス名古屋2025 / Welcome to PHP Conference Nagoya 2025
ttskch
1
240
ErdMap: Thinking about a map for Rails applications
makicamel
1
1.2k
非ブラウザランタイムとWeb標準 / Non-Browser Runtimes and Web Standards
petamoriken
0
450
盆栽転じて家具となる / Bonsai and Furnitures
aereal
0
2.6k
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
182
22k
Being A Developer After 40
akosma
89
590k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Building Applications with DynamoDB
mza
93
6.2k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
28
2.2k
Unsuck your backbone
ammeep
669
57k
How GitHub (no longer) Works
holman
312
140k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Optimising Largest Contentful Paint
csswizardry
33
3k
Docker and Python
trallard
43
3.2k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
Transcript
到達可能性チェッカーを 品質改善に活⽤する mario 2023年4⽉16⽇
ここに円に切り抜いた画像を入れてく ださい mario 2021.11~ freee ⼈事労務のCI職⼈ 最近社内RuboCop ruleを書いた ⼈事労務開発船 品質ヨット
Engineer
⽬次 • 安⼼してリファクタリングしたい • 到達可能性チェッカー(ReachableChecker) • 活⽤例 • workするために必要だったこと
• まとめ
安⼼して リファクタリングしたい 到達可能性チェッカーを 品質改善に活用する
安⼼してリファクタリングしたい • どうやったら安⼼できるか ◦ ⾼頻度⼩変更で ◦ ⾃動テストとセットで ◦ 監視しながら
• それでも怖い時がある ◦ 本番でしか起きないedge case ◦ 未使⽤かどうかが確信を持てないコード
なぜ怖いのか • 開発‧本番が完全に⼀致しないから怖い ◦ 成⻑したサービスでは完全⼀致が困難 • 検証環境では問題ないことを担保する & 本番環境を壊さないことを保
証する
到達可能性チェッカー (ReachableChecker) 到達可能性チェッカーを 品質改善に活用する
到達可能性チェッカー: 開発ではraiseし、 本番ではreportする
到達可能性チェッカー • 開発ではraiseする(RAILS_ENV=development/test) ◦ その⾏に到達したら即raise ◦ 検証環境では未到達なことが担保できる • 本番ではreportする(RAILS_ENV=staging/production)
◦ エラー監視ツールにより開発者に通知する ◦ その⾏以降の処理を継続する • 敢えて環境差分を設けた仕組み
到達可能性チェッカー module ReachableChecker class << self def execute(message: nil)
raise UnexpectedReachedError.new(message) rescue UnexpectedReachedError => error raise if Rails.env.development? || Rails.env.test? ErrorReportService.report(error, :warning) end end class UnexpectedReachedError < StandardError end end
何が嬉しいのか • 後⽅互換を保って⾼頻度⼩変更でリリースできる • リリースサイクルの過程で理解が深まる ◦ 「当初は想定しなかったが、この条件で到達する」とわかる ◦ 理解が深まればさらなる品質改善につながる
• プロファイル収集やインフラ層ソリューションよりも気軽な武器として 使い始められる
活⽤例 到達可能性チェッカーを 品質改善に活用する
活⽤例:シンプルな未使⽤コード検知 def calculate(params) case params[:type] when 'new_pattern' NewModule.calculate when
'old_deprecated_pattern' ReachableChecker.execute(message: '古いパラメータで処理します。') OldDeprecatedModule.calculate else raise '想定しないパラメータです。' end end
活⽤例:新規コードの後⽅互換性を本番環境で確認 def want_to_refactor_logic attendance_records = AttendanceRecord.where(date: dates) old_result =
OldInnerProcess.execute(attendance_records) new_result = NewInnerProcess.execute(attendance_records) old_result .filter { |k, v| v != new_result[k] } .tap do |diff_hash| unless diff_hash.empty? ReachableChecker.execute(message: "#{diff_hash.keys}") end end old_result # 旧ロジックで処理を継続 end
workするために必要なこと 到達可能性チェッカーを 品質改善に活用する
前提1:エラー監視が健全に⾏えている • 追加した監視ログが来たらすぐに気づける ◦ 普段の監視のノイズが少ない ◦ severity分類(error/warning/info)を活⽤する ◦ 監視状況を整えることも品質ヨットの職掌
前提2:必要⼗分な⾃動テストが書かれている • Code Coverage ◦ 到達可能性チェッカーはカバレッジ未通過になる ▪ 到達するとテスト失敗するため ◦
⾃動テストが担保する典型的かつ重要なケースをクリアしている ◦ そう確信を持てる程に既存のテストスイートが充実している ◦ outdatedなテストは勇気を持って書き直す
前提3:開発環境のエラーが共有されている • 私/あなた が追加した到達可能性チェッカーで、あなた/私 がraiseした ◦ tail logしてgit blameして「rails
serverでこういうエラーが出て〜」 ◦ 気楽に共有できている & 機敏に対応できている ◦ 本番環境より前に開発者が気付けてよかった
まとめ 到達可能性チェッカーを 品質改善に活用する
まとめ • 成⻑したサービスでは開発‧本番環境は⼀致しない • そんな中でも安⼼してリファクタリングしたい • 「検証ではraiseし、本番ではreportする」仕組みにより、理解を深めながら ⾼速で品質改善ができる •
常⽇頃の監視、⾃動テスト、開発環境への投資によって成⽴する • Release with confidence.
None