月に一度の大規模リファクタリングでレガシーコードと向き合う取り組み / PHP Conference Fukuoka 2023

PHPカンファレンス福岡2023（2023/06/24）
https://fortee.jp/phpconfukuoka-2023/proposal/c92e8e48-ba20-4a01-9555-b261f20ef493

Transcript

1. 月に一度の大規模リファクタリングで レガシーコードと向き合う取り組み PHPカンファレンス福岡2023
2. meihei / 江間 洋平 株式会社PR TIMES Backend Engineer (PHP/Python/Go) Twitter: @app1e_s GitHub: @meihei3 Bluesky: @meihei.bsky.social 最近はヘブバンにハマり中。 VTuberもハマってます。最近のニュースでは、 ぶいぱいが熱い!!アップランドから6月16日に新 自己紹介 2
3. 毎月一度、 3
4. 毎月一度、 大規模なリファクタリングを 4
5. 毎月一度、 大規模なリファクタリングを 行う日（デー） 5
6. リファクタリングデー 6
7. リファクタリングデー 外から見た挙動を変えずに、コードを変更すること。 7
8. リファクタリングデー 外から見た挙動を変えずに、コードを変更すること。 → 設計や手法については話しません 8
9. 背景 9
10. PR TIMESというサービス 10
11. いくつかの機能があり 11
12. 旧基盤・新基盤がある 12
13. 現在進行系でリプレイスしている 13
14. 旧基盤の方はレガシーコード 14
15. リプレイスだけすれば良いのか？ 15
16. リプレイスだけすれば良いのか？ 全てのリプレイスが完了する前に リファクタリングを行う必要が出てくる 16
17. 旧基盤の方はレガシーコード 17
18. リファクタリングが困難 No Tests Array Array Array Array Amazing Array Let sleeping dogs lie. 18
19. もうウンザリです、何も改善できません 19
20. でも、出来ます。 20
21. リファクタリング 外から見た挙動を変えずに、コードを変更すること。 21
22. 挙動が変わっていない事を保証する 22
23. 挙動が変わっていない事を保証する 23 サービス全体に対して、結合テストや QAを行って、動作を保証する。
24. 非常に荒々しいやり方で 無理矢理にでも前に進める 24
25. 非常に荒々しいやり方で 無理矢理にでも前に進める 25 １日かけてリファクタリング＆確認作業を行うので 名前を付けたものがリファクタリングデーになります。
26. 手順 26
27. 当日までの流れ • チケットの起票 • チケットの精査 • （初参加者向けオンボーディング） 27
28. 当日までの流れ • チケットの起票 • チケットの精査　←もっとも重要 • （初参加者向けオンボーディング） 28
29. チケットの精査では戦略を立てる • 影響範囲の大きいチケットは、リリースブランチの 中で Revert し易いところにマージする • 影響範囲の大きいが優先度の低い場合は、今回は リリースしないという選択も可能 ◦ 毎月行うので次月に回す 29
30. チケットの精査では戦略を立てる • 影響範囲の大きいチケットは、リリースブランチの 中で Revert し易いところにマージする • 影響範囲の大きいが優先度の低い場合は、今回は リリースしないという選択も可能 ◦ 毎月行うので次月に回す 30 →何をやるか、やらないかを決める
32. 当日の流れ • ブランチの作成　　　　　→　~10:00 • わいわい開発・レビュー　→　10:00~ • STG環境で確認　　　 　→　14:00~ • デプロイ　　　　　　　　→　16:00~ • 本番確認　　　　　　　　→　~18:00 32
33. 当日の流れ • ブランチの作成 • わいわい開発・レビュー • STG環境で確認　←重要 • デプロイ • 本番確認　←重要 33
34. 確認作業 • 手動テスト • テスト自動化ツール（Autifyなど） • E2Eテスト 34
35. 確認作業 • 手動テスト • テスト自動化ツール（Autifyなど） • E2Eテスト 35 ←これが理想形だが、 レガシーコードでは厳しい 場合がある。手を動かす。
36. 失敗するときはします。 36
37. でも、出来ます。 37 リファクタリングが困難 と言いました
38. でも、出来ます。 38 リファクタリングが困難 　　　やります。
39. • 失敗を恐れ、リリースできない空気は壊す • 失敗した時にすぐに切り戻しが出来るようにする • 優先度の高いものをリリースして、 リファクタリングデーが意味のあるものにする • QAの負担を減らす自動テスト、自動ツールなどを充 実させる リファクタリングデーを行うために 39
40. • 失敗を恐れ、リリースできない空気は壊す • 失敗した時にすぐに切り戻しが出来るようにする • 優先度の高いものをリリースして、 リファクタリングデーが意味のあるものにする • QAの負担を減らす自動テスト、自動ツールなどを充 実させる リファクタリングデーを行うために 40 →失敗出来る環境（仕組み・組織）は超重要。
41. メリット・デメリット 41
42. • 通常リリースでは出来ないような影響範囲が大きい ものを、まとめてリリース出来る • 月一開催なので、リファクタリングチケットを気軽 に積んで消化出来る ◦ いつかやろうではなく、この日にやろう。 ◦ フィーチャートグルの削除のタイミングなどで便利 • （応用）影響範囲を絞ることで、小チーム単位でも 行うことが可能 メリット 42
43. • 通常のリリースよりもQAコストがかなり高い • 開発担当者、QA担当者にかなりのパワーを求められ る • ご覧の通り荒業なので、失敗のリスクを受け入れる 必要がある デメリット 43
44. それでもレガシーに立ち向かうなら 荒業でもリファクタリングするしか無い 44 俺たちの戦いはここからだ！ 参考ブログ: https://developers.prtimes.jp/2021/12/13/introducing-refactoring-day/