おてつたびのフロントエンド 〜ディレクトリ設計編〜
はじめに
初めまして!
株式会社おてつたびでフルスタックエンジニアをしているぶりぼんと申します。主にフロントエンド領域を開拓しており、ReactやTypeScriptが最も得意です。また、最近ではPdM業やユーザーの問い合わせ対応もやっています。
おてつたびの開発チームは、よりスピーディにPDCAサイクルを回すために、内部品質の改善、つまりリファクタリングのプロジェクトを開始しました。また、リファクタリングするにあたってディレクトリ設計を大きく変更することにも決定しました。
今回は、ディレクトリ設計に至った経緯とディレクトリ設計に関してお話しします。
コーディング規約に関しては、以前記事にまとめましたので、気になる方はご参照いただけると嬉しいです!
ディレクトリ設計に至った経緯
おてつたびは、BtoCのマッチングプラットフォームを運営しており、2022年7月より第5期目を迎えました。そのタイミングで、開発チームは「グロースチーム」と「改善チーム」の2つに分かれることになりました。
簡単に各チームの役割を説明すると、グロースチームは主に新機能の仮説検証を行うこと目的にしており、改善チームは既存の課題や作り込みができていない機能・画面の改善を進めることを目的にしています。
改善チームは私が主導で進めており、こちらの記事で取り組み内容に関してお話ししております。
改善チームは、各ビジネスサイドのチームと連携した上で、高速でPDCAを回すことが求めれられます。しかし、PDCAを回して開発している中で、技術負債の問題にぶつかってしまい、スピードが上がらないという状況に陥りました。
会社としての利益を創出できないこともそうですが、エンジニアのメンタルヘルスも悪化してしまいます……。
そこで、将来におけるスピードを上げることを目的として、リファクタリングプロジェクトを立ち上げ、進めることに決定しました。
おてつたびのディレクトリ設計
変更前
変更前のディレクトリを一部公開すると、以下の通りです。
client
┣ components
┣ images
┣ packs
┣ scss
┣ src
┣ admin
┣ componentA
┣ componentB
┣ pageA
┣ pageB
┣ core(adminと同じ構成)
┣ front(adminと同じ構成)
┣ componentA
┣ componentB
┣ models
┣ @types
┣ build (hidden dir)
┣ node_modules (hidden dir)
┗ 各種設定ファイル(.env, tsconfig.json, etc……)
フロントエンドのソースコードは、レポジトリのルート直下のclient
で管理しています。
経緯の項目でも述べた通り、おてつたびはBtoCのマッチングプラットフォームを運営しているので、Businessの方はsrc
配下のadmin
ディレクトリ、Consumerの方はsrc
配下のfront
ディレクトリでそれぞれ管理しています。また、共通コンポーネントはsrc
配下のcore
というディレクトリで管理しています。
src
ディレクトリが、実際にサービスを形作るソースコードを配置するディレクトリとなります。
上記ディレクトリ構造で違和感はありますか?
まずは、src
ディレクトリ配下に粒度の異なるディレクトリが混在しています。
各サービスのメインディレクトリであるadmin
やfront
ディレクトリと同じレベルで、とあるページ用のコンポーネントが存在します。
さらに、admin
とfront
ディレクトリ配下も、ページレベルのソースコードやコンポーネントレベルのソースコード、定数や共通メソッドなどが混在しており、どれがどれだか判断が難しい状態となっていました。
一部、新ディレクトリ構成を取り始めましたが、これ以上の設計変更は開発者に思わぬ混乱を生み出しうると判断したため、思い切ってディレクトリ構成を一新しました!
変更後
client
┣ src
┣ admin(usersiteもsharedも同じ構成。sharedは一部落とす)
┣ index.tsx(ReactDOM.renderで返す、rootファイル)
┣ constants
┣ components
┣ context
┣ hooks
┣ pages
┣ index.tsx(router)
┗ HogePage or Hoge
┣ images
┣ services
┣ styles
┣ store
┣ translations
┗ utils
┣ usersite
┣ shared
┣ models(shared配下に入れるか検討中)
┣ webpacks
┣ stories
┣ e2e
┣ @types
┣ build (hidden dir)
┣ node_modules (hidden dir)
┗ 各種設定ファイル(.env, tsconfig.json, etc……)
一部まだ未実装のディレクトリもありますが、この構成で今後は進めていこうと考えています。
特質すべきは、各サービス単位のディレクトリ(admin
, usersite
)を一段深くして、責務や関心ごとに分けている点でしょうか。
変更前のディレクトリ設計の大きな課題は、どのコンポーネントが共通コンポーネントなのかページ単位のものなのか、どこに共通関数があるのかなどが、全ソースコードを読まない限り把握できない点にありました。
create-react-app
で作成したレポジトリは、概ねデフォルトでこの構成かと思います。
Reactの基本構成を意識しつつ、おてつたびの開発をする中で必要なものを入れて再構成しました。
また、ディレクトリ構成を一新したというだけあって、usersite
とshared
ディレクトリを作成しました。
これらはそれぞれ、変更前のfront
とcore
ディレクトリにあたるものです。
まだ開発が進んでいないので、変更後のディレクトリ設計の効果は出ていませんが、旧ディレクトリからの移行作業が素晴らしいスピードで進んだという恩恵を受けました笑
今後のリファクタリングプロジェクト
今回お話ししたディレクトリ設計に関しては、リファクタリングプロジェクトの一部分でしかありません。
技術負債という大きな課題に直面したため、その一環としてリファクタリングプロジェクトを開始しました。
リファクタリングプロジェクトを開始ししても、既存のサービスの改善を止めることはありません。
そのため、リファクタリングと機能追加・修正を同時並行で進めていくことになります。
また、一部画面や機能では、リファクタリングだけに留まらず、UI・UXを含めたフルリプレイスを前提に進めている箇所もあります。
詳細に話すと長くなってしまいますので、リファクタリングプロジェクトに関しては、別の記事にて解説させていただこうかと思います。
技術者の方であれば、絶対面白いと思う内容ですので、ぜひ公開まで楽しみにお待ちいただければと思います。
終わりに
どの会社も人が足りないのは常ですが、おてつたびでも人が足りていません。
内部品質の改善もしたいですが、ビジネスサイドの要望を叶えるための改善施策も行いたいと強く思っています。
本記事をご覧になって少しでも興味を持っていただいた方は、Meetyなどもやっているので、お気軽にご連絡ください!
一緒に働きたいという話だけではなく、取り組み内容に関してもお話しできれば嬉しいです。
Discussion