こんにちは。プロダクトエンジニアリング部の船曵です。
この記事はユニファAdvent Calendar 2022の8日目の記事で、
Railsのプロダクションコードを約１万行削除しました
の続編的な内容となります。
バージョンアップに向けて不要なコードを削除し終え、私達の挑戦はこれからだ、となってから約２ヶ月、何度かのプロダクトリリースを重ね、プロジェクトはゴールを迎えつつあります。
前回のダイジェスト
- 弊社における最も古いプロダクトは、約9年くらい前に作られ、現役で稼働している
- プロダクトをサポート対象となっているバージョン（Rubyは2.7系、Railsは6.1系）までアップデートする予定
- 作業を行うチームメンバーの内2名は今年に入社（のうちの1名は私）
- プロダクションコードを約１万２千行以上削除に成功
- テストカバレッジも約５０％から約９０％に向上
今回のはなし
続編的な記事を書くにあたり、アップデート編としてまとめるのが難しいくらいトピックスが多かったので、本記事ではプロジェクトのゴールが見えつつあるということで、チーム内で毎週開催してきたKPTでRailsアップデートプロジェクトを振り返ってみたいと思います。
KPT振り返り
プロジェクト立ち上がり初期
- Keep
- Ruby/Rails アップグレードのチケットが作成され、対応が近づいてきた感がでてきた。大変そうだけど楽しみ
- Problem
- テストに結構時間がかかりそう
- 本当にできるか不安ではあるが、１つずつ着実にやっていくしかないと思う
- 不要コード削除が思っていたより大変
- タスクのアサインはなかなか難しい
- Try
- 各自アサインされたチケットを見積もって全員でレビューする
Tryにあった見積りも難しかったですし、プロジェクトの始まりは全体的に先が見えない不安と期待が入り混じっておりました。
コード削除期
- Keep
- コードがどんどん少なくなっていくのが嬉しい
- コード削除も勉強になる
- バージョンアップが動き始め出した
- レビュー大変助かる
- Problem
- 調査と実装でチケット分けてもよかったかも
- PR が増えるのでレビューが大変になるかも
- コード削除のレビューは難しい
- Try
- PRの承認を一旦見直す・最低2人で確認が必要にする
ロジックを削除することの難しさと、コードがどんどんすっきりしていく嬉しさが語られました。 プルリクエストの渋滞が予想されたので、承認体制の見直しを行ったことで効率的にプルリクエストがマージされるようになりました。
テスト実装前半戦
Keep
- コードの削除の終わりが近づいてきた
- 今のところ大きな遅れや問題なく進んでいる
- テスト対象のコードがすごく減った
- テストを作っていて、仕様がすごく勉強になっている
- レビューを通してspecの書き方が勉強になる
Problem
- 削除が終わりそうで終わらない
- テストカバレッジは１００％にすることを目指しはするが、本来のテストとして妥当であるものでないと意味がないと思った
- 仕様の理解に時間がかかるため、テストを書くのに時間がかかる
- カバレッジの高さに反してテストが少ないケースがあって思ったより時間がかかることがある
- テスト作成の優先度が合っているか不安
Try
- 重たいチケットは分割して対応する
- 複雑かつ要不要の判断が難しい場合は後回しにして量をこなすほうがいいかも
- 共通の認識で適切なテストを作っていく
テストの実装にはテスト実装の難しさがあり、カバレッジを優先するか、意味のあるテストを書くかで悩んでいた様子が伺えます。 限られた時間の中で、自分の実装ではないコードにテストを書くことを通し、改めて意味のあるテストとは、について考えるきっかけになりました。
テスト実装後半戦
- Keep
- テストのカバレッジ80％超えた
- 仕様の把握ができて知識が増えている気がする
- テストだいぶ書き方に慣れた
- QAついに！祝！
- Problem
- アップグレードとプロダクトの開発は並行してできるのか
- Try
- スケジュールやアサインはスプリント毎に確認しながら調整していく
不要コードの削除とテストの実装を終え、ついにQAが始まった喜びと、ソースコードへの理解が深まってきた話題が多かったです。 そして、開発のプロジェクトはずっと同時進行していたのですが、ここまでのタスクはチーム全員が対応していました。 ここからはPhase毎に交代制でメイン作業はチームメンバーの一人が担当、ソースコードレビューは全員で、という体勢に変わるため、どう進めていくか、という議論も多かったと記憶しています。
バージョンアップ
Keep
- 詰まったところや進め方の相談にのっていただき、ありがたい
- バージョンアップの流れを学べて嬉しい
- バージョンアップ作業はハマると楽しい。着実に進められている
- アップグレードが着々とすすんでいるし、同時に開発も進んでいる
- 引き継いだらさくっと対応していただいて助かった
- 事前の動作確認で問題点を発見することができた
Problem
- 実装に思ったより時間がかかる
- 開発中の画面で結構エラーがでる
- 非推奨の警告がでてきた。直す作業を永遠と機械的にしていて疲れた。
- PR分けてもよかったかもしれない
- 不具合に不具合が入れ子になっているケースがある
- 発生したエラーは調査が難しそう
Try
- 再度見積もりをやっても良いかも
- いい感じに置換できる方法があれば良いのだが・対応方法は内容によりけり
- 開発メンバーでリリース前に実際の動作を確認してみる
- QA仕様書のブラッシュアップしていく
- 発生したエラーの対応を入れてみるのが良さそう。検証環境でまずは確認してみたい
どうバトンタッチしていくか、という進め方から、アップグレードに伴って発生したエラーをどう解決していくかという話題へと変遷していきます。 プロジェクトの最初のKeepにもあった通り、レビューが本当にありがたく、プルリクエストも詳細に記録が残っていることで、バトンを受け取って次の作業をするときに本当に助かりました。
以上、KPTの記録から振り返るRailsRubyバージョンアッププロジェクトの話でした。 どんな風にバージョンアップしていったのか？をチームの様子とともに感じていただけたら幸いです。 ゴールが近いとはいえ、プロジェクトは続いています。 プロジェクトが終わったらまた様子をお伝えしたいと思います！
--
ユニファでは新たな仲間を積極採用中です。
詳細についてはこちらからご確認ください。
