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
23k
到達可能性チェッカーを品質改善に活用する/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
200
MusicXMLを校正する
tmyrhystic
0
68
Other Decks in Programming
See All in Programming
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
24
10k
Streamlitで実現できるようになったこと、実現してくれたこと
ayumu_yamaguchi
2
230
商品比較サービス「マイベスト」における パーソナライズレコメンドの第一歩
ucchiii43
0
210
バイブスあるコーディングで ~PHP~ 便利ツールをつくるプラクティス
uzulla
1
300
The Niche of CDK Grant オブジェクトって何者?/the-niche-of-cdk-what-isgrant-object
hassaku63
1
710
マッチングアプリにおけるフリックUIで苦労したこと
yuheiito
0
240
CDK引数設計道場100本ノック
badmintoncryer
2
580
フロントエンドのパフォーマンスチューニング
koukimiura
6
2.3k
SwiftでMCPサーバーを作ろう!
giginet
PRO
2
210
MySQL9でベクトルカラム登場!PHP×AWSでのAI/類似検索はこう変わる
suguruooki
1
250
階層化自動テストで開発に機動力を
ickx
1
440
Gemini CLI のはじめ方
ttnyt8701
1
110
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1k
GitHub's CSS Performance
jonrohan
1031
460k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Being A Developer After 40
akosma
90
590k
It's Worth the Effort
3n
185
28k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Agile that works and the tools we love
rasmusluckow
329
21k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
What's in a price? How to price your products and services
michaelherold
246
12k
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