到達可能性チェッカーを 品質改善に活⽤する 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.

No content