👌

おてつたびのフロントエンド 〜ディレクトリ設計編〜

2022/09/28に公開約3,800字

はじめに

初めまして!
株式会社おてつたびでフルスタックエンジニアをしているぶりぼんと申します。主にフロントエンド領域を開拓しており、ReactやTypeScriptが最も得意です。また、最近ではPdM業やユーザーの問い合わせ対応もやっています。

おてつたびの開発チームは、よりスピーディにPDCAサイクルを回すために、内部品質の改善、つまりリファクタリングのプロジェクトを開始しました。また、リファクタリングするにあたってディレクトリ設計を大きく変更することにも決定しました。
今回は、ディレクトリ設計に至った経緯とディレクトリ設計に関してお話しします。

コーディング規約に関しては、以前記事にまとめましたので、気になる方はご参照いただけると嬉しいです!
https://zenn.dev/otetsutabi_tech/articles/20220601_6966628994c49d

ディレクトリ設計に至った経緯

おてつたびは、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ディレクトリ配下に粒度の異なるディレクトリが混在しています。
各サービスのメインディレクトリであるadminfrontディレクトリと同じレベルで、とあるページ用のコンポーネントが存在します。
さらに、adminfrontディレクトリ配下も、ページレベルのソースコードやコンポーネントレベルのソースコード、定数や共通メソッドなどが混在しており、どれがどれだか判断が難しい状態となっていました。

一部、新ディレクトリ構成を取り始めましたが、これ以上の設計変更は開発者に思わぬ混乱を生み出しうると判断したため、思い切ってディレクトリ構成を一新しました!

変更後

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の基本構成を意識しつつ、おてつたびの開発をする中で必要なものを入れて再構成しました。

また、ディレクトリ構成を一新したというだけあって、usersitesharedディレクトリを作成しました。
これらはそれぞれ、変更前のfrontcoreディレクトリにあたるものです。

まだ開発が進んでいないので、変更後のディレクトリ設計の効果は出ていませんが、旧ディレクトリからの移行作業が素晴らしいスピードで進んだという恩恵を受けました笑

今後のリファクタリングプロジェクト

今回お話ししたディレクトリ設計に関しては、リファクタリングプロジェクトの一部分でしかありません。
技術負債という大きな課題に直面したため、その一環としてリファクタリングプロジェクトを開始しました。

リファクタリングプロジェクトを開始ししても、既存のサービスの改善を止めることはありません。
そのため、リファクタリングと機能追加・修正を同時並行で進めていくことになります。
また、一部画面や機能では、リファクタリングだけに留まらず、UI・UXを含めたフルリプレイスを前提に進めている箇所もあります。

詳細に話すと長くなってしまいますので、リファクタリングプロジェクトに関しては、別の記事にて解説させていただこうかと思います。
技術者の方であれば、絶対面白いと思う内容ですので、ぜひ公開まで楽しみにお待ちいただければと思います。

終わりに

どの会社も人が足りないのは常ですが、おてつたびでも人が足りていません。
内部品質の改善もしたいですが、ビジネスサイドの要望を叶えるための改善施策も行いたいと強く思っています。
本記事をご覧になって少しでも興味を持っていただいた方は、Meetyなどもやっているので、お気軽にご連絡ください!

一緒に働きたいという話だけではなく、取り組み内容に関してもお話しできれば嬉しいです。

採用ページ
Wantedly 採用ページ
ぶりぼんのMeety

Discussion

ログインするとコメントできます