初めましてAPP・UXチーム/フロントエンドエンジニアの大谷です。
今回は入社(今年５月)して初めて関わったレッスンルームのリファクタリングのプロジェクトを事例にリファクタリングの進め方・効果・反省点などまとめていきたいと思います。
経緯
弊社ではレッスンルームという英会話の授業をするためのプロダクトを提供しています。 レッスンルームについて詳しくはこちら
現在のレッスンルームは先生側のシステムと生徒側のシステムが別々のプロジェクトで管理されていて、それぞれ異なるフレームワークで作られています。また、一部独自で作成したライブラリも含まれており、機能改善を続けていくにあたって今の構成では属人化してしまう問題があり、対応が難しくなってくることが予想されたためリファクタリングしよう！という運びになりました。
リファクタリングの進め方
方針決め
リファクタリングしていくにあたって、目的や技術的な方針など軸を決めておくことで効率的に作業が進められるようになります。
リファクタリングの目的
リファクタリングは機能追加などと違って見た目の変化がないため、何がゴールなのかわからなくなる怖さもあります。目的をしっかり持つことでスコープが絞られエンドレスな開発にならずにすみます。
今回は以下の目的があげられました。
- 不具合の発生原因を特定しやすい改善をしやすいシステムにする
- テストしやすい環境の整備
- 保守性の向上
技術構成
技術選定は講師側はAnguler JS→Vue.jsに変更し、生徒側と同一のプロジェクトで管理するようにしました。独自で作成したライブラリを廃止し、Ajax通信ライブラリはVue.jsで推奨されているaxiosを使うなどスタンダードに沿ったものを選定するようにしました。
ディレクトリ構成はAtomic Designを採用し不明確だったコンポーネントの単位に基準を設けました。
いよいよ実装
仕様の整理
既存のプログラムからリファクタ後のプロジェクトにコードを書き換える際に、明文化されてない仕様や複雑になってしまっているロジックに出会うことがあります。
そんな時は下記のように整理しました。
フローチャートを書くなどして仕様を整理→チーム内で合意→無駄な部分は廃止してスリム化
既存の仕様だからという理由で残すのではなく、都度仕様を整理してわかりやすくい構成にしていくサイクルをスピード感を持って行えたのがとてもよかったと思います。
コーディング
見通しのいいコードにして行くために行ったTipsはこちらの記事をご参照ください。 また今回、Ajax通信の仕方をXMLHttpRequestからaxiosを使うように変更しました。変更した際にカスタムヘッダーに設定漏れがあり、Ajax通信として判定してくれず少々ハマったので設定方法を残しておきます。
axios.create({ baseURL: baseUrl, headers: { 'X-Requested-With': 'XMLHttpRequest', // この設定が必要 'Content-Type': 'application/json' } timeout: timeout, responseType: 'json' })
新しいライブラリを導入する時などは特にunitテストを作成し、前後で意図しない変更がないことを確認できる仕組みを事前に整えておくことをおすすめします。
検証環境の整備
今回はコードのリファクタリングだけでなく、検証環境の改善も行いました。 レッスンルームの開発中にちょっとした表示確認をフィリピンのスタッフと行いたい場合、今までは修正してから確認対象であるレッスンルームにアクセスするために、STG環境を使用していためスケジュール調整をしたり、レッスン予約をして指定した時間にならないとレッスンルームに入れないなどとても手間がかかっていました。
QAなど本番と同等の条件でのテストの場合は話が変わってきますが、表示や軽微な動作・疎通チェックなどであればレッスンルーム入室前のプロセスはカットし、修正したらすぐデプロイして確認できる環境がほしい。。という思いがありAWS上にフロントの動作確認用の環境を作ることになりました。
コマンドをたたくだけでローカルからデプロイ可能にし、必要なデータはLambdaを使ってモックデータを受け取れるような構成になっています。Lambda/API gatewayについての詳しい内容はまたいつか。
この取り組みで他チームと干渉することなく簡単に動作確認を行えるようになりました。今後の開発を続けていくにあたってとても大きな改善になったと思います。
効果
今回リファクタリングをしてみて、以下のような効果がありました。
- チーム内でのシステムへの理解度が高まった
- 見えていなかった課題が見えてきた
- 日本とフィリピンで保守が協力しあえるようになった(独自のライブラリの廃止・ロジックの共通化などで)
- 適切なログを完備することで不具合調査しやすくなった
- 手軽に日本・フィリピン間での動作確認ができるようになった
リファクタリングは工数もかかりますし、見た目の変化がないわりに手間もかかります。 ですが普段あまり改修が入らない部分のコードをみる機会ができるので表面化していなかったバグの温床に気づくことができたり、なによりシステムへの理解度が高るので改善のアイディアがでてくるなどメリットの方が大きいように思います。
反省点
技術構成や方針など最初に固めていても、進めてみてからやはりこうすればよかったというところもでてきました。
- lintやフォーマッターは最初にしっかり
今回stylelintなど設定していましたが、ゆるめの設定にしていました。ですが後から変更したくなった場合差分が大量に出てしまうため、設定するのであればなるべく最初の方に検討した方がいいです。 - store(Vuex)の構成
storeの定義を機能単位にしていて定義が曖昧でした。pages/organizmsのみでstoreに接続し、それ以外はprop inで情報を受け渡すなど定義を明確化しておくとよかったと思います。
反省点も次のスコープで改善していってさらに見通しの良いプロダクトにしていければと思います。
まとめ
リファクタリングによってコードの見通しがよくなっただけでなく、チーム内でシステムに対しての理解度が深まる→次の改善のアイディアが生まれるなどプラスの連鎖もありました。 今回でてきたアイディアや課題など一つ一つ改善していって、もっと快適なレッスンの場を提供できればと考えています！
