![9
フレームワーク移行におけるコードの修正例
● Query Builderの置き換え
○ where('col', 'in', $b) => whereIn($a, $b)
○ where('col', '=', $subQuery) => whereSub('col', $subQuery)
○ DB::select_array(['id', 'name']) => DB::select('id', 'name')
● Controllerの置き換え
○ Input, Request, Responseなどを対応するメソッドに置き換え
○ Controllerをpsr-4準拠にrename
○ psr-4のnamespaceに合わせたディレクトリへ移動](https://image.slidesharecdn.com/greetc2021session2-211115051126/75/-9-2048.jpg?cb=1666170980)
![12
Rectorの処理（抽象構文木の編集）
public function getNodeTypes(): array
{
return [String_::class];
}
public function refactor($node): ?Node
{
if ($node->value === "Hello World!") {
$node->value = "Hello GREE Tech Conf!";
return $node;
}
return null;
}
Scalar_String
value: Hello GREE Tech Conf!
Stmt_Expression
expr
Expression_Assign
var, expr
Expression_Variable
name: var
expr
var
Scalar_String
value: Hello World!
Scalar_String
value: Hello World!](https://image.slidesharecdn.com/greetc2021session2-211115051126/75/-12-2048.jpg?cb=1666170980)
![14
実際のコード自動修正の例
FuelPHP
¥DB::select_array(['id', 'name'])->from('user');
Laravel
¥DB::table('user')->select('id', 'name')](https://image.slidesharecdn.com/greetc2021session2-211115051126/75/-14-2048.jpg?cb=1666170980)
![15
実際のRectorルール: select fromをtable select
¥DB::select_array(['id', 'name'])->from('user');
¥DB::table('user')->select_array(['id', 'name']);
select fromをtable selectに変更](https://image.slidesharecdn.com/greetc2021session2-211115051126/75/-15-2048.jpg?cb=1666170980)
![16
実際のRectorルール: select_arrayをselect
¥DB::table('user')->select('id', 'name');
¥DB::select_array(['id', 'name'])->from('user');
¥DB::table('user')->select_array(['id', 'name']);
select fromをtable selectに変更
select_arrayの引数を展開](https://image.slidesharecdn.com/greetc2021session2-211115051126/75/-16-2048.jpg?cb=1666170980)
コードの自動修正によって実現する、機能開発を止めないフレームワーク移行
•0 likes•2,868 views
Report
Share
Download to read offline
GREE Tech Conference 2021 で発表された資料です。 https://techcon.gree.jp/2021/session/Session-2
More Related Content
What's hot
What's hot(20)
Similar to コードの自動修正によって実現する、機能開発を止めないフレームワーク移行
Similar to コードの自動修正によって実現する、機能開発を止めないフレームワーク移行(20)
More from gree_tech
More from gree_tech(20)
Recently uploaded
Recently uploaded(10)
コードの自動修正によって実現する、機能開発を止めないフレームワーク移行
- 2. 木村洋太 ● 所属 ○ グリーライフスタイル株式会社 / プロダクト開発部 / メディア開発グ ループ / エンジニアリングチーム ● 経歴 ○ 2020年 グリーライフスタイル株式会社 入社 ○ 主に「LIMIA」のサーバー・インフラ開発 自己紹介 2 2
- 3. LIMIAを知っていますか？ ⓘ Start presenting to display the poll results on this slide.
- 5. ● 移行前 ○ フレームワーク ■ FuelPHP ○ 言語 ■ PHP7.0 ○ インフラ ■ EC2 ● 移行後 ○ フレームワーク ■ Laravel ○ 言語 ■ PHP7.4 ○ インフラ ■ ECS Fargate 5 フレームワーク移行プロジェクト https://aws.amazon.com/jp/architecture/icons/
- 6. 6 移行プロジェクトのスケジュール ● 機能開発を止めずに移行して欲しいという要望 ● 移行にかけられる工数は限られていた ○ 並行開発期間が長そうな見込みだった 方針 検討 コード自動修正ルールの作成 QA・バグ修正 インフラ検証 1月 2月 7月 9月 11月 実際の移行スケジュール 社内管理ツール リリース カナリヤ リリース開始 0.5人 1人 2人
- 7. 7 なぜ自動修正に踏み切ったか？ ● 軽量なFuelPHP => 機能の多いLaravelへの移行 ○ DB (Query Builder), Controllerあたりを置き換えれば良さそう ○ View周りはテンプレートエンジンを置き換えるだけで良さそう ● 手動修正の厳しさ ○ 50万行超えのコードベース ○ 人や時間が足りない ○ 機能開発を並行で行いたいが…… ■ 移行元と移行後のコードの両方を変更する必要がある ■ 移行後のコードに変更を加えるとconflictが起こり得る ■ 機能開発を止めるしかないが、止めた場合は半年近く機能開発が進まないこと が見込まれた
- 8. 8 Rector (rectorphp/rector) ● 自動リファクタリング・マイグレーションツール ○ DeadCode, EarlyReturn... などのリファクタリングルール ○ PHPバージョンのupgrade, downgrade ● 特徴 ○ nikic/php-ast をベースに抽象構文木（AST）を編集 ○ 型情報をPHPStanから取得できる ○ テストが書きやすい ○ 開発が活発
- 9. 9 フレームワーク移行におけるコードの修正例 ● Query Builderの置き換え ○ where('col', 'in', $b) => whereIn($a, $b) ○ where('col', '=', $subQuery) => whereSub('col', $subQuery) ○ DB::select_array(['id', 'name']) => DB::select('id', 'name') ● Controllerの置き換え ○ Input, Request, Responseなどを対応するメソッドに置き換え ○ Controllerをpsr-4準拠にrename ○ psr-4のnamespaceに合わせたディレクトリへ移動
- 10. 10 Rectorの変換例: EarlyReturn ChangeNestedIfsToEarlyReturnRector public function hoge($value) { if ($value % 2 === 0) { if ($value % 3 === 0) { return 'yes'; } } return 'no'; } public function hoge($value) if ($value % 2 !== 0) { return 'no'; } if ($value % 3 === 0) { return yes; } return 'no'; }
- 11. 11 抽象構文木 (Abstract Syntax Tree: AST) https://github.com/nikic/PHP-Parser <?php $var = "Hello World!"; Stmt_Expression expr Expression_Assign var, expr Expression_Variable name: var Scalar_String value: Hello World! expr var expr
- 12. 12 Rectorの処理（抽象構文木の編集） public function getNodeTypes(): array { return [String_::class]; } public function refactor($node): ?Node { if ($node->value === "Hello World!") { $node->value = "Hello GREE Tech Conf!"; return $node; } return null; } Scalar_String value: Hello GREE Tech Conf! Stmt_Expression expr Expression_Assign var, expr Expression_Variable name: var expr var Scalar_String value: Hello World! Scalar_String value: Hello World!
- 13. 13 Rectorの処理（抽象構文木からコードの構築） Scalar_String value: Hello GREE Tech Conf! <?php $var = "Hello GREE Tech Conf!"; Stmt_Expression expr Expression_Assign var, expr Expression_Variable name: var expr var
- 15. 15 実際のRectorルール: select fromをtable select ¥DB::select_array(['id', 'name'])->from('user'); ¥DB::table('user')->select_array(['id', 'name']); select fromをtable selectに変更
- 16. 16 実際のRectorルール: select_arrayをselect ¥DB::table('user')->select('id', 'name'); ¥DB::select_array(['id', 'name'])->from('user'); ¥DB::table('user')->select_array(['id', 'name']); select fromをtable selectに変更 select_arrayの引数を展開
- 17. 作成したRectorのルール数 ⓘ Start presenting to display the poll results on this slide.
- 18. 18 答え
- 19. 19 なぜ自動修正に踏み切ったか？（再掲） ● 軽量なFuelPHP => 機能の多いLaravelへの移行 ○ DB (Query Builder), Controllerあたりを置き換えれば良さそう ○ View周りはテンプレートエンジンを置き換えるだけで良さそう ● 手動修正の厳しさ ○ 50万行超えのコードベース ○ 人や時間が足りない ○ 機能開発を並行で行いたいが…… ■ 移行元と移行後のコードの両方を変更する必要がある ■ 移行後のコードに変更を加えるとconflictが起こり得る ■ 機能開発を止めるしかないが、止めた場合は半年近く機能開発が進まないこと が見込まれた
- 20. 20 コードの自動修正による機能開発と移行の並行開発 開発ブランチ ○ 機能開発、バグ修正 ○ PHP7.0 => 7.4に伴うコード修正 移行用ブランチ ○ Rectorのルールの作成 ○ Laravel関連ファイルの追加 今まで通りのフローで QA・リリース CIによる 自動修正 移行環境でのテスト アプリケーションのコードは 移行用ブランチでは編集しない
- 21. 21 どれくらい自動修正で移行できたか ● PHPファイルは2000ファイルくらい ● 変更量 ● 手動で移行したファイル（〜10ファイル） ○ 認証周り ○ ルーティング ○ Formatter, AgentなどFuelPHPにしかない機能
- 22. 22 コードの自動修正をやる上で…… ● テスト ○ あるととても良い ○ LIMIAではテストはあまり動いていなかった ● Rectorルールのテスト ○ ルールによる変換をある程度保証できる ○ Rectorはbreaking changeが多いので結構役に立った ● 静的解析ツール ○ PHPStanの導入 ■ 一番役にたった ■ 機能開発の方のバグも検出してくれた
- 23. 23 自動修正で苦労したこと ● どうしても自動修正が難しそうなコード ○ めちゃくちゃ複雑なQuery Builder ○ 仕様からよくわからないコード 元のコード側をRectorで変換できるリファクタリングした そもそもいらないコードが多かったので消しまくった（約10万行） ● ツール側のバグ ○ 正しそうなのに動かないと思ったらバージョンを変えると動いたり ○ RectorのCacheが壊れている OSSなんだから自分で直す！！
- 24. 24 自動修正による移行まとめ ● 良かったこと ○ 物量に対抗できる ○ ヒューマンエラーを減らせる ○ 新規追加されたファイルも自動で移行される ○ 機能開発とconflictすることがない ● 悪かったこと ○ Laravelの機能をフルに使えない ○ 抽象構文木の深い知識などが必要で属人化しやすい
- 25. 25 移行プロジェクトを終えて ● 自動修正を決断して良かった ● Rectorというツールに出会えて良かった ○ PHP7.4 => PHP8.0でも活躍しそう！ ○ リファクタリングツールとしてCIに入れたい ● インフラの移行も楽しかった ○ VPC Traffic Mirroringによる負荷テスト ○ EC2とFargateでのカナリヤリリースを行うための工夫 ○ CI/CDも大幅に改善 ○ エンジニアブログ書きたいと思っています……
- 26. 26