到達可能性チェッカーを品質改善に活用する/use-ReachableChecker-for-frequent-refactoring

2023-04-16 freee技術の日 https://freee.connpass.com/event/274961/

Transcript

1. 到達可能性チェッカーを 品質改善に活⽤する mario 2023年4⽉16⽇
2. ここに円に切り抜いた画像を入れてく ださい mario 2021.11~ freee ⼈事労務のCI職⼈ 最近社内RuboCop ruleを書いた ⼈事労務開発船 品質ヨット Engineer
3. 　 ⽬次 • 安⼼してリファクタリングしたい • 到達可能性チェッカー(ReachableChecker) • 活⽤例 • workするために必要だったこと • まとめ
4. 安⼼して リファクタリングしたい 到達可能性チェッカーを 品質改善に活用する
5. 　 安⼼してリファクタリングしたい • どうやったら安⼼できるか ◦ ⾼頻度⼩変更で ◦ ⾃動テストとセットで ◦ 監視しながら • それでも怖い時がある ◦ 本番でしか起きないedge case ◦ 未使⽤かどうかが確信を持てないコード
6. 　 なぜ怖いのか • 開発‧本番が完全に⼀致しないから怖い ◦ 成⻑したサービスでは完全⼀致が困難 • 検証環境では問題ないことを担保する & 本番環境を壊さないことを保 証する
7. 到達可能性チェッカー (ReachableChecker) 到達可能性チェッカーを 品質改善に活用する
8. 　 到達可能性チェッカー： 開発ではraiseし、 本番ではreportする
9. 　 到達可能性チェッカー • 開発ではraiseする(RAILS_ENV=development/test) ◦ その⾏に到達したら即raise ◦ 検証環境では未到達なことが担保できる • 本番ではreportする(RAILS_ENV=staging/production) ◦ エラー監視ツールにより開発者に通知する ◦ その⾏以降の処理を継続する • 敢えて環境差分を設けた仕組み
10. 　 到達可能性チェッカー 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
11. 　 何が嬉しいのか • 後⽅互換を保って⾼頻度⼩変更でリリースできる • リリースサイクルの過程で理解が深まる ◦ 「当初は想定しなかったが、この条件で到達する」とわかる ◦ 理解が深まればさらなる品質改善につながる • プロファイル収集やインフラ層ソリューションよりも気軽な武器として 使い始められる
12. 活⽤例 到達可能性チェッカーを 品質改善に活用する
13. 　 活⽤例：シンプルな未使⽤コード検知 def calculate(params) case params[:type] when 'new_pattern' NewModule.calculate when 'old_deprecated_pattern' ReachableChecker.execute(message: '古いパラメータで処理します。') OldDeprecatedModule.calculate else raise '想定しないパラメータです。' end end
14. 　 活⽤例：新規コードの後⽅互換性を本番環境で確認 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
15. workするために必要なこと 到達可能性チェッカーを 品質改善に活用する
16. 　 前提1：エラー監視が健全に⾏えている • 追加した監視ログが来たらすぐに気づける ◦ 普段の監視のノイズが少ない ◦ severity分類(error/warning/info)を活⽤する ◦ 監視状況を整えることも品質ヨットの職掌
17. 　 前提2：必要⼗分な⾃動テストが書かれている • Code Coverage ◦ 到達可能性チェッカーはカバレッジ未通過になる ▪ 到達するとテスト失敗するため ◦ ⾃動テストが担保する典型的かつ重要なケースをクリアしている ◦ そう確信を持てる程に既存のテストスイートが充実している ◦ outdatedなテストは勇気を持って書き直す 
18. 　 前提3：開発環境のエラーが共有されている • 私/あなた が追加した到達可能性チェッカーで、あなた/私 がraiseした ◦ tail logしてgit blameして「rails serverでこういうエラーが出て〜」 ◦ 気楽に共有できている & 機敏に対応できている ◦ 本番環境より前に開発者が気付けてよかった 
19. まとめ 到達可能性チェッカーを 品質改善に活用する
20. 　 まとめ • 成⻑したサービスでは開発‧本番環境は⼀致しない • そんな中でも安⼼してリファクタリングしたい • 「検証ではraiseし、本番ではreportする」仕組みにより、理解を深めながら ⾼速で品質改善ができる • 常⽇頃の監視、⾃動テスト、開発環境への投資によって成⽴する • Release with confidence.