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-frequent-refactoring
Search
t-mario-y
April 16, 2023
Programming
0
18k
到達可能性チェッカーを品質改善に活用する/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
140
MusicXMLを校正する
tmyrhystic
0
62
Other Decks in Programming
See All in Programming
Cloudflare Workers x AWS Lambdaの組み合わせユースケース / Cloudflare Workers x AWS Lambda Combination Use Case
seike460
PRO
2
310
Product Management LT会_クアンド新家
shinshin
0
260
The rollercoaster of releasing an Android, iOS, and macOS app with Kotlin Multiplatform | droidcon Berlin
prof18
0
110
Exploring the Gradually Lost Technical Skills in the Cloud Native Era
hwchiu
2
3.9k
CSC307 Lecture 05
javiergs
PRO
0
210
今こそ始める、CDKコンストラクトライブラリ開発 ― 入門から実践まで
tmokmss
1
930
初心者がおさえておきたいAWS CDKのベストプラクティス 2024
konokenj
15
7.3k
feature環境をGitHub ActionsとCloudFormationでいい感じに管理する
nealle
2
310
コード生成を伴うLLMエージェント - 2024.07.18 Tokyo AI
smiyawaki0820
11
4.1k
しくじり先生 Image Matching Challenge 2024 編
goosehaaan
0
810
Folding Cheat Sheet #7
philipschwarz
PRO
0
150
最近追加した型の紹介とその振り返り
aki19035vc
0
180
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
25
6.7k
A Modern Web Designer's Workflow
chriscoyier
689
190k
Atom: Resistance is Futile
akmur
261
25k
Raft: Consensus for Rubyists
vanstee
134
6.5k
A Philosophy of Restraint
colly
200
16k
Designing for humans not robots
tammielis
247
25k
How To Stay Up To Date on Web Technology
chriscoyier
784
250k
Code Review Best Practice
trishagee
58
16k
Build your cross-platform service in a week with App Engine
jlugia
227
17k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
12
3.8k
Embracing the Ebb and Flow
colly
81
4.3k
Imperfection Machines: The Place of Print at Facebook
scottboms
262
13k
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