Upgrade to Pro — share decks privately, control downloads, hide ads and more …

レガシーなシステムのリファクタリングに取り組んで学んだこと

pbtnhan
September 08, 2022

 レガシーなシステムのリファクタリングに取り組んで学んだこと

レガシーなシステムでは、古いコードの書き方、保守性・可読性が悪い書き方などがよくあると思います。
リファクタリングはこのようなシステムで生産性を向上するための一つの手段です。
私は約15年稼働しているメール配信システムのブリッジエンジニアとして、オフショアチームと一緒にリファクタリングを実施してきました。
リファクタリングの経験で良かったことと苦労したこと、そこから学んだリファクタリングする時に注意することをご紹介します。

・なぜリファクタリングを実施しないといけないのか
・リファクタリングで良かったことと苦労したこと
・リファクタリングする時に注意すること

pbtnhan

September 08, 2022
Tweet

More Decks by pbtnhan

Other Decks in Programming

Transcript

  1. #RAKUSMeetup • なまえ: Pham Bui The Nhan(ファム ブイ テー ニャン) •

    経歴 ◦ 7年開発経験で2014年にラクスベトナムに入社 ◦ 2018年に株式会社ラクスに出向し開発・運用などを経験 ◦ 2020年からブリッジSEを担当 • 趣味 ◦ 旅行、美味しいもの(特に和食)、新しいことの勉強 自己紹介
  2. #RAKUSMeetup ❏ オフショア側のスケジュールに余 裕があったので前倒しでリファク タリングを依頼した ❏ 日本側に受入の余裕がなかった ため一部を次のバージョンに持 ち越した ❏

    そのため次のバージョンのリリー スブランチでコンフリクトが発生 し、コンフリクトの解消と再テスト がまた必要になった 苦労したこと GENZO オフショア開発チーム (リファクタリング実装) Refactoring 1 開発バージョンの リリースブランチ Refactoring 2 次のバージョンの リリースブランチ 翼 国内開発チーム (受入) 開発バージョンで改修を実施 したが、一部次のバージョン へマージする
  3. #RAKUSMeetup ❏ デグレがよく発生した ❏ 修正範囲が多かったため、以下の方針で進めた ❏ ブラックボックステストせず、修正した後ホワイ トボックステストのみ実施 ❏ すべて完了後、全機能のノーマルケースのみテ

    ストを実施(細かいパターンが網羅できない) ❏ オフショアへ依頼する時に認識齟齬が発生して正しく 修正できなかったこともあった ❏ ホワイトボックステストした時、分岐を通すため、無理 やりソースを修正したことがあった 苦労したこと 普段の開発機能ではブラックボック ステストを実施するが、今回のリ ファクタリングはブラックボックステ ストを実施しなかった
  4. #RAKUSMeetup ❏ リファクタリング範囲が広い場合、デグレ・ コンフリクトが発生しやすい ❏ 小さい範囲になるほどデグレを防止しやすくなる ❏ どれくらい小さい範囲が良いかというと、ファイル単位ま でで良さそう ❏

    ブランチ戦略にも注意する ❏ リファクタリングの修正は1つの機能ブランチへマージする のではなく、小さい範囲単位で直接にリリースブランチに マージする ❏ コンフリクトが発生した時はブラックボックステス トを再実施する リファクタリング機能ブラン チ リファクタリング種類 1 リファクタリング種類 2 リファクタリング種類 3 リリースブランチ
  5. #RAKUSMeetup ❏ JavaScriptに修正が入った際の注意点 ❏ JSエラーが発生しやすい ❏ キャッシュの問題がないかも注意 ❏ ブラックボックスも必ずテストする ❏

    小さいソースを修正した場合、ホワイトボックステストだけではなくブラック ボックステストを必ず実施する    ※配配メールがレガシーなサービスなので影響範囲を洗い出しきれず、網羅性を担保するにはホ ワイトボックステストとブラックボックステストをしっかり実施するしかない