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