#RAKUSMeetup ©2022 RAKUS Co., Ltd. レガシーなシステムのリファクタリング に取り組んで学んだこと 株式会社ラクス　開発本部　第三開発部　配配メール開発課 Pham Bui The Nhan #rakus #meetup

#RAKUSMeetup ● なまえ：　Pham Bui The Nhan（ファム ブイ テー ニャン） ● 経歴 ○ 7年開発経験で2014年にラクスベトナムに入社 ○ 2018年に株式会社ラクスに出向し開発・運用などを経験 ○ 2020年からブリッジSEを担当 ● 趣味 ○ 旅行、美味しいもの（特に和食）、新しいことの勉強 自己紹介

#RAKUSMeetup はじめに ● 今日お話すること ○ レガシーなシステムのリファクタリングに取り組んで学んだこと ● お話するプロダクト ○ 配配メール：　メールマガ配信・一斉メール配信サービス ■ https://www.hai2mail.jp/ ○ 10年以上のサービスである（2007年にリリース）

#RAKUSMeetup Agenda 1. なぜリファクタリングが必要か 2. 配配メールでのリファクタリングの進め方 3. リファクタリングで良かったことや苦労したこと 4. リファクタリングする時に注意すること 5. まとめ

#RAKUSMeetup １．なぜリファクタリングが必要か

#RAKUSMeetup ❏ JSがPHP内に文字列で書かれていた ❏ 可読性が悪い ❏ 文字列で書かれていた事でJSのシンタック スエラーなどが認識しにくい ❏ 可読性の悪さにより、調査・実装・ コードレ ビューなどの効率が下がる・不具合を見落 とす可能性が上がる

#RAKUSMeetup ❏ デッドコードや利用されていないソースが存在していた ❏ たとえば、廃止となったアクションや関連ソースが残っていた

#RAKUSMeetup ❏ 1行で書けるコードを5行で書いていた ❏ 言語や環境によっても異なるが「ソースコードが長い＝可読性がよい」とは 一概には言えない ❏ 今回の例では、PHPのバージョンアップによるWarningの発生を回避する ためにif文による存在チェックのコードへ機械的に置き換えたため、1行 ソースが5行に変更された 　　　　※ "undefined variable", "undefined array key" の Warningが発生

#RAKUSMeetup ２．配配メールでの リファクタリングの進め方

#RAKUSMeetup ❏ まず普段からリファクタリングの課題をためておいて、対象を洗い出している 　　　※ 以下のようなイメージで課題をためている

#RAKUSMeetup ❏ 3ヶ月ごとに1人月程度の範囲でリファクタリングする方針をビジネスサ イドと合意して進めている ❏ リファクタリングのやりかたをまとめてオフショアへ依頼して対応しても らっている ❏ テストは自動テストが少なく、ほとんど手動でテストをしている

#RAKUSMeetup ３．リファクタリングで良かったことや 苦労したこと

#RAKUSMeetup ❏ IDEツール（PhpStormなど）の各種ジャンプ機能やシンタックスハイライトの恩恵を 受けことで実装しやすいし、楽になった 良かったこと

#RAKUSMeetup ❏ リファクタリング実施と共にソースのルール化ができて、保守性・可 読性が向上された ❏ 新規ソースは既存ソースの書き方を真似して実装する場合がある ❏ リファクタリングする前のコードの書き方を今後は真似しないようにコーディン グ規約を強化　　※イメージを参照 良かったこと

#RAKUSMeetup ❏ コードが短くなったり可読性がよくなったりする 　　例）Null coalescing operatorを適用することでソースを短くすることができる https://www.php.net/manual/en/language.operators.comparison.php#language.ope rators.comparison.coalesce　 　　 良かったこと

#RAKUSMeetup ❏ デッドコードや未利用ソースの削減により不要な作業も削減 ❏ 不要な調査が削減できている ❏ オフショア先ではデッドコードの判断ができないケースがあるため、不必要 な質問が削減できる 良かったこと

#RAKUSMeetup ❏ ボリュームが大きいため、数バー ジョンに分割してリファクタリン グを実施した ❏ 種類が多かったため、コンフリク トがよく発生した ❏ コンフリクトを解消した後、再テ ストに時間がかかった 苦労したこと

#RAKUSMeetup ❏ オフショア側のスケジュールに余 裕があったので前倒しでリファク タリングを依頼した ❏ 日本側に受入の余裕がなかった ため一部を次のバージョンに持 ち越した ❏ そのため次のバージョンのリリー スブランチでコンフリクトが発生 し、コンフリクトの解消と再テスト がまた必要になった 苦労したこと GENZO オフショア開発チーム （リファクタリング実装） Refactoring 1 開発バージョンの リリースブランチ Refactoring 2 次のバージョンの リリースブランチ 翼 国内開発チーム （受入） 開発バージョンで改修を実施 したが、一部次のバージョン へマージする

#RAKUSMeetup ❏ デグレがよく発生した ❏ 修正範囲が多かったため、以下の方針で進めた ❏ ブラックボックステストせず、修正した後ホワイ トボックステストのみ実施 ❏ すべて完了後、全機能のノーマルケースのみテ ストを実施（細かいパターンが網羅できない） ❏ オフショアへ依頼する時に認識齟齬が発生して正しく 修正できなかったこともあった ❏ ホワイトボックステストした時、分岐を通すため、無理 やりソースを修正したことがあった 苦労したこと 普段の開発機能ではブラックボック ステストを実施するが、今回のリ ファクタリングはブラックボックステ ストを実施しなかった

#RAKUSMeetup ❏ リファクタリングの要因でリリース後に不具合が発生 ❏ 特殊なパターンの考慮漏れによるデグレで重要機能に影響を与えてしまっ た ❏ JSのキャッシュの考慮漏れで画面が正常に動かなかった（JSエラーが発生 した） 　　　　　　※画面を開いた際にバージョンアップ前のJSファイルがロードされたためJSエラーが発生した 苦労したこと

#RAKUSMeetup ❏ リファクタリングの要因でリリース後に不具合が発生 ❏ JavaScriptのstrictモードに変更することでバグが発生した 苦労したこと JavaScriptのstrict モードがオフ→オンに変更されたことで、 現在時刻が1桁台(00時〜09時)の場合、現在時刻が設定で きなかった。 ※strict モードの変更でJSエラーが発生した

#RAKUSMeetup ４．リファクタリングする時に注意すること

#RAKUSMeetup ❏ リファクタリング範囲が広い場合、デグレ・ コンフリクトが発生しやすい ❏ 小さい範囲になるほどデグレを防止しやすくなる ❏ どれくらい小さい範囲が良いかというと、ファイル単位ま でで良さそう ❏ ブランチ戦略にも注意する ❏ リファクタリングの修正は１つの機能ブランチへマージする のではなく、小さい範囲単位で直接にリリースブランチに マージする ❏ コンフリクトが発生した時はブラックボックステス トを再実施する リファクタリング機能ブラン チ リファクタリング種類 １ リファクタリング種類 ２ リファクタリング種類 ３ リリースブランチ

#RAKUSMeetup ❏ JavaScriptに修正が入った際の注意点 ❏ JSエラーが発生しやすい ❏ キャッシュの問題がないかも注意 ❏ ブラックボックスも必ずテストする ❏ 小さいソースを修正した場合、ホワイトボックステストだけではなくブラック ボックステストを必ず実施する 　　 ※配配メールがレガシーなサービスなので影響範囲を洗い出しきれず、網羅性を担保するにはホ ワイトボックステストとブラックボックステストをしっかり実施するしかない

#RAKUSMeetup ❏ ホワイトボックステストは無理やり通すのではなく、工夫して通す ❏ できるだけ多くのパターンのテストデータを準備する ❏ デバッグ機能を活用する ❏ 可能ならテストコードを書く ❏ etc… ※無理やり通す： 通すため直接ソースを修正してテストする

#RAKUSMeetup まとめ

#RAKUSMeetup ❏ リファクタリングは生産性を向上するための一つの手段である ❏ リファクタリングをすることで保守性・可読性が向上される ❏ リファクタリングを実施する際に以下を注意する ❏ リファクタリング範囲が多かった場合、デグレが発生しやすいのため、小さ い範囲で実施する ❏ コンフリクトも発生しやすいため、ブランチ戦略にも注意する ❏ ブラックボックスは必ずテストする ❏ ホワイトボックステストは無理やり通すのではなく、工夫して通す

#RAKUSMeetup ご清聴ありがとうございました