Vue3導入とフロントエンド設計の大改革【開発録 Vol.2】
こんにちは！re:shineの中の声です！
先日（2021年7月21日）、re:shineは新UIをリリースしました！
これまでre:shineは、PCをターゲットとし、スマホなどのモバイルには非対応なUIだったのですが、レスポンシブデザインに対応したモバイルファーストなUIに一新しました。
フロントエンド設計の大幅改善
UIの一新だけでも大きな変更なのですが、実は、単なるUI一新や機能追加だけではなく、フロントエンドの設計を大幅に変更した、大規模リニューアルでした。
というのも、re:shineのフロントエンドは、今まで大きな技術負債を抱えておりました。
UIのちょっとした修正にもかなりの時間を要してしまうほど、フロントエンドのコード変更・追加が難解であり、スムーズに開発ができないという大きな課題がありました。
そのため、ちょっとした機能追加でも、フロントエンドの開発工数が大幅に膨らみ、スピード感のあるサービス改善ができない状況でした。
このような状況になったのは、フロントエンドの設計思想を、開発チームがきちんと把握していなかったことが原因でした。
re:shineでは、リリース当初、フロントエンドの開発を業務委託の方に行っていただいていました。しかし、その方がre:shineを離れるタイミングで、re:shineチームできちんと設計思想の引き継ぎを行なっていませんでした。
そのため、開発初期の設計思想に沿わず、ルールのない状態でコード追加を行い、どんどんと設計が崩れていって、色々なものが色々なところに分散していきました。
そのため、どこに何が書いてあるか把握することが難しく、コード変更時の影響範囲も明確にわからないため、容易にコードの変更や追加ができない状態になっていました。
このままでは、re:shineというサービスは、スピーディーかつアグレッシブに改善していけない。。
そこで、2020年10月、re:shineは、フロントエンドの大幅なリニューアル・プロジェクトを開始しました。
このリニューアルでは、大きく分けて2つの挑戦を行いました。
その2つが
・Vue3の導入
・フロントエンドの設計思想の再構築
です。
Vue3の導入
フロントエンドのリニューアルは、昨年の夏頃から検討を始めたのですが、ちょうどその頃、Vue3のRC版がリリースされ、正式リリースが見えている状況でした。
re:shineは元々Vue2で開発していたのですが、せっかくリニューアルするなら、Vue3を採用するのはどうか？
ということで、Vue3の導入検討を行いました。
その際に、調査したVue3の改善点を、re:shineの開発メンバーの@Ayumu_UsuさんがQiitaにまとめています。
議論の結果、せっかくなら新しいものでやっていこう、ということになり、Vue3を採用することになりました。
Vue3では、TypeScriptが標準となったため、フロントエンドにTypeScriptを全面的に導入できる、といった点も、Vue3導入の大きな理由となりました。
そして、re:shineのリニューアル・プロジェクトは2020年10月に開始しました。
ちょうどその直前の2020年9月にVue3が正式リリースされたのも何かの縁だったと思います。
また、リリース直後に開発着手したため、re:shineは、Vue3を導入したサービスとしては、かなり早い方ではないかと思います。
フロントエンドの設計思想の再構築
今回のリニューアルの最も大きな挑戦は、何と言っても設計思想の再構築でした。
「せっかく再構築するなら」ということで、ディレクトリ構成やクラス設計などのアーキテクチャを、がっつり設計し直しました。
なお、re:shineでは、フロントエンドとバックエンドを完全に分離した構成にしているため、今回の再設計の範囲はフロントエンドに限定したものでした。
また、チームメンバーも10名以上で、プログラムの規模もそれなりに大きな規模になってきていたため、中規模以上のプログラムでも開発しやすい設計を心がけました。
そして、特に下記のポイントを抑えた設計を行いました。
・ディレクトリの数は必要最低限に絞る
・ディレクトリ名は使いやすいものにする
・バックエンド開発者がHTML/CSSを触る可能性を配慮する
・API接続とロジック部分は一箇所に集約する
・ユーザー画面と管理画面はドメインを分けつつも、コンポーネントを共有可能な構成にする
具体的なアーキテクチャは、設計を担当してくださった@tsuyoshi_fukuzawaさんがQiitaにまとめてくださっています。
この記事を読んでいただくとわかるのですが、チームメンバーの特性や可読性、メンテナンス性などを配慮して、入念にアーキテクチャを設計しました。
設計思想の浸透
設計思想の再構築と合わせて行なったのが、設計思想をチームメンバーに浸透させることです。
技術負債を溜めてしまった大きな原因は、設計思想がチームメンバーに浸透しておらず、設計が崩れてしまったことです。
re:shineのフロントエンドは、主に数名が触っているのですが、レビューをしっかりと行い、ルール通りに実装されているかチェックを行うことで、設計思想の浸透をはかりました。
そして、数回のレビューで設計思想の共通認識がほぼ取れるようになりました。
このように、設計思想をチームメンバーにインストールするにあたって、レビューが上手く機能しました。
また、チームメンバーが理解しやすいような設計にしたことも、共通認識がすぐに取れたことの要因だと思います。
再構築の成果
設計思想を再構築し、チームメンバーにもきちんと浸透させてことで、コードの可読性が圧倒的に上がり、どこに何が書いてあるか、すぐにわかるようになりました。
おかげさまで、
・コード変更・追加がかなり早くなった
・フロントエンドへの新規のアサインが容易になった
・フロントエンドを触れる人が増えた
といった恩恵を既に得られています。
例えば、バグ修正では、今まで数日かかっていたようなものが、数時間で直せるようになるなど、圧倒的に修正や新規開発のスピードが上がりました。
また、ジュニアクラスのエンジニアが、ほぼレクチャーなしでコードを触って、プルリクまで自力でできるようなるくらい、新しい人を開発にアサインする際の負担も圧倒的に少なくなりました。
さらに、設計思想の再構築を社内のエンジニアも含めて行なったことで、設計のトレーニングにもなり、社内にもフロントのコードを触れる人が増えました。
このように、単にフロントエンドの開発がスムーズになっただけでなく、「コードを触れる人が増えた」、「新規アサインが容易になった」という点で、属人性が解消され、チームの拡張性も高まりました。
改めて感じた設計思想の重要性
何事にも共通しますが、ルールが一つあると、意思決定を一つなくすことができます。
今回、設計思想がきちんと定まり、フロントエンドに様々なルールを設けることができました。
そのおかげで、これまで開発の度に無駄に発生してしまっていたディレクトリ設計やクラス設計などの意思決定を排除できるようになりました。
このような意思決定は、開発において大きな負担になるとともに、変なルールを作り出してしまう原因にもなります。
適切なルールのもとに、重要なロジック設計に集中できる環境づくりといった点でも、設計思想を定めることは重要だと感じました。
最後に
今回、フロントエンドの設計思想を再構築し、チームに浸透させたことで、re:shineの開発スピードを大幅にアップすることができました。
機能としては、実現したいことのほとんどができていない状態ですが、これから様々な機能をスピード感持って追加していくための準備が整いました。
re:shineの目指す世界を実現するために、これからどんどんとサービスを加速させていきたいと思います！
この記事が気に入ったらサポートをしてみませんか？