レガシーなシステムのリファクタリングに取り組んで学んだこと
by
pbtnhan
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
#RAKUSMeetup ©2022 RAKUS Co., Ltd. レガシーなシステムのリファクタリング に取り組んで学んだこと 株式会社ラクス 開発本部 第三開発部 配配メール開発課 Pham Bui The Nhan #rakus #meetup
Slide 2
Slide 2 text
#RAKUSMeetup ● なまえ: Pham Bui The Nhan(ファム ブイ テー ニャン) ● 経歴 ○ 7年開発経験で2014年にラクスベトナムに入社 ○ 2018年に株式会社ラクスに出向し開発・運用などを経験 ○ 2020年からブリッジSEを担当 ● 趣味 ○ 旅行、美味しいもの(特に和食)、新しいことの勉強 自己紹介
Slide 3
Slide 3 text
#RAKUSMeetup はじめに ● 今日お話すること ○ レガシーなシステムのリファクタリングに取り組んで学んだこと ● お話するプロダクト ○ 配配メール: メールマガ配信・一斉メール配信サービス ■ https://www.hai2mail.jp/ ○ 10年以上のサービスである(2007年にリリース)
Slide 4
Slide 4 text
#RAKUSMeetup Agenda 1. なぜリファクタリングが必要か 2. 配配メールでのリファクタリングの進め方 3. リファクタリングで良かったことや苦労したこと 4. リファクタリングする時に注意すること 5. まとめ
Slide 5
Slide 5 text
#RAKUSMeetup 1.なぜリファクタリングが必要か
Slide 6
Slide 6 text
#RAKUSMeetup ❏ JSがPHP内に文字列で書かれていた ❏ 可読性が悪い ❏ 文字列で書かれていた事でJSのシンタック スエラーなどが認識しにくい ❏ 可読性の悪さにより、調査・実装・ コードレ ビューなどの効率が下がる・不具合を見落 とす可能性が上がる
Slide 7
Slide 7 text
#RAKUSMeetup ❏ デッドコードや利用されていないソースが存在していた ❏ たとえば、廃止となったアクションや関連ソースが残っていた
Slide 8
Slide 8 text
#RAKUSMeetup ❏ 1行で書けるコードを5行で書いていた ❏ 言語や環境によっても異なるが「ソースコードが長い=可読性がよい」とは 一概には言えない ❏ 今回の例では、PHPのバージョンアップによるWarningの発生を回避する ためにif文による存在チェックのコードへ機械的に置き換えたため、1行 ソースが5行に変更された ※ "undefined variable", "undefined array key" の Warningが発生
Slide 9
Slide 9 text
#RAKUSMeetup 2.配配メールでの リファクタリングの進め方
Slide 10
Slide 10 text
#RAKUSMeetup ❏ まず普段からリファクタリングの課題をためておいて、対象を洗い出している ※ 以下のようなイメージで課題をためている
Slide 11
Slide 11 text
#RAKUSMeetup ❏ 3ヶ月ごとに1人月程度の範囲でリファクタリングする方針をビジネスサ イドと合意して進めている ❏ リファクタリングのやりかたをまとめてオフショアへ依頼して対応しても らっている ❏ テストは自動テストが少なく、ほとんど手動でテストをしている
Slide 12
Slide 12 text
#RAKUSMeetup 3.リファクタリングで良かったことや 苦労したこと
Slide 13
Slide 13 text
#RAKUSMeetup ❏ IDEツール(PhpStormなど)の各種ジャンプ機能やシンタックスハイライトの恩恵を 受けことで実装しやすいし、楽になった 良かったこと
Slide 14
Slide 14 text
#RAKUSMeetup ❏ リファクタリング実施と共にソースのルール化ができて、保守性・可 読性が向上された ❏ 新規ソースは既存ソースの書き方を真似して実装する場合がある ❏ リファクタリングする前のコードの書き方を今後は真似しないようにコーディン グ規約を強化 ※イメージを参照 良かったこと
Slide 15
Slide 15 text
#RAKUSMeetup ❏ コードが短くなったり可読性がよくなったりする 例)Null coalescing operatorを適用することでソースを短くすることができる https://www.php.net/manual/en/language.operators.comparison.php#language.ope rators.comparison.coalesce 良かったこと
Slide 16
Slide 16 text
#RAKUSMeetup ❏ デッドコードや未利用ソースの削減により不要な作業も削減 ❏ 不要な調査が削減できている ❏ オフショア先ではデッドコードの判断ができないケースがあるため、不必要 な質問が削減できる 良かったこと
Slide 17
Slide 17 text
#RAKUSMeetup ❏ ボリュームが大きいため、数バー ジョンに分割してリファクタリン グを実施した ❏ 種類が多かったため、コンフリク トがよく発生した ❏ コンフリクトを解消した後、再テ ストに時間がかかった 苦労したこと
Slide 18
Slide 18 text
#RAKUSMeetup ❏ オフショア側のスケジュールに余 裕があったので前倒しでリファク タリングを依頼した ❏ 日本側に受入の余裕がなかった ため一部を次のバージョンに持 ち越した ❏ そのため次のバージョンのリリー スブランチでコンフリクトが発生 し、コンフリクトの解消と再テスト がまた必要になった 苦労したこと GENZO オフショア開発チーム (リファクタリング実装) Refactoring 1 開発バージョンの リリースブランチ Refactoring 2 次のバージョンの リリースブランチ 翼 国内開発チーム (受入) 開発バージョンで改修を実施 したが、一部次のバージョン へマージする
Slide 19
Slide 19 text
#RAKUSMeetup ❏ デグレがよく発生した ❏ 修正範囲が多かったため、以下の方針で進めた ❏ ブラックボックステストせず、修正した後ホワイ トボックステストのみ実施 ❏ すべて完了後、全機能のノーマルケースのみテ ストを実施(細かいパターンが網羅できない) ❏ オフショアへ依頼する時に認識齟齬が発生して正しく 修正できなかったこともあった ❏ ホワイトボックステストした時、分岐を通すため、無理 やりソースを修正したことがあった 苦労したこと 普段の開発機能ではブラックボック ステストを実施するが、今回のリ ファクタリングはブラックボックステ ストを実施しなかった
Slide 20
Slide 20 text
#RAKUSMeetup ❏ リファクタリングの要因でリリース後に不具合が発生 ❏ 特殊なパターンの考慮漏れによるデグレで重要機能に影響を与えてしまっ た ❏ JSのキャッシュの考慮漏れで画面が正常に動かなかった(JSエラーが発生 した) ※画面を開いた際にバージョンアップ前のJSファイルがロードされたためJSエラーが発生した 苦労したこと
Slide 21
Slide 21 text
#RAKUSMeetup ❏ リファクタリングの要因でリリース後に不具合が発生 ❏ JavaScriptのstrictモードに変更することでバグが発生した 苦労したこと JavaScriptのstrict モードがオフ→オンに変更されたことで、 現在時刻が1桁台(00時〜09時)の場合、現在時刻が設定で きなかった。 ※strict モードの変更でJSエラーが発生した
Slide 22
Slide 22 text
#RAKUSMeetup 4.リファクタリングする時に注意すること
Slide 23
Slide 23 text
#RAKUSMeetup ❏ リファクタリング範囲が広い場合、デグレ・ コンフリクトが発生しやすい ❏ 小さい範囲になるほどデグレを防止しやすくなる ❏ どれくらい小さい範囲が良いかというと、ファイル単位ま でで良さそう ❏ ブランチ戦略にも注意する ❏ リファクタリングの修正は1つの機能ブランチへマージする のではなく、小さい範囲単位で直接にリリースブランチに マージする ❏ コンフリクトが発生した時はブラックボックステス トを再実施する リファクタリング機能ブラン チ リファクタリング種類 1 リファクタリング種類 2 リファクタリング種類 3 リリースブランチ
Slide 24
Slide 24 text
#RAKUSMeetup ❏ JavaScriptに修正が入った際の注意点 ❏ JSエラーが発生しやすい ❏ キャッシュの問題がないかも注意 ❏ ブラックボックスも必ずテストする ❏ 小さいソースを修正した場合、ホワイトボックステストだけではなくブラック ボックステストを必ず実施する ※配配メールがレガシーなサービスなので影響範囲を洗い出しきれず、網羅性を担保するにはホ ワイトボックステストとブラックボックステストをしっかり実施するしかない
Slide 25
Slide 25 text
#RAKUSMeetup ❏ ホワイトボックステストは無理やり通すのではなく、工夫して通す ❏ できるだけ多くのパターンのテストデータを準備する ❏ デバッグ機能を活用する ❏ 可能ならテストコードを書く ❏ etc… ※無理やり通す: 通すため直接ソースを修正してテストする
Slide 26
Slide 26 text
#RAKUSMeetup まとめ
Slide 27
Slide 27 text
#RAKUSMeetup ❏ リファクタリングは生産性を向上するための一つの手段である ❏ リファクタリングをすることで保守性・可読性が向上される ❏ リファクタリングを実施する際に以下を注意する ❏ リファクタリング範囲が多かった場合、デグレが発生しやすいのため、小さ い範囲で実施する ❏ コンフリクトも発生しやすいため、ブランチ戦略にも注意する ❏ ブラックボックスは必ずテストする ❏ ホワイトボックステストは無理やり通すのではなく、工夫して通す
Slide 28
Slide 28 text
#RAKUSMeetup ご清聴ありがとうございました