インターン生で共同開発をしようという提案が通り、レシピを投稿する簡単なサービスを開発しました。共同開発したサービスの概要、過程、利用したツール等についてまとめていきます。
##メンバー
僕を含めた3人（特に分野を決めていませんでしたが、結果的に僕が開発、他2人が設計中心になりました。「特に苦労したこと」）
サービス概要
Food Frofessor
レシピを投稿し、編集、お気に入り登録、コメントができる基本的なサービスです。
特に苦労したことの経緯や、「共同開発」を経験するといった目的が理由でそこまでハイレベルなサービスにしませんでした。
URL: https://food-professor.herokuapp.com/top （初回のみデータの読み込みに時間がかかります）
GitHub: https://github.com/akira-iguchi/FoodProfessor-Backend / https://github.com/akira-iguchi/FoodProfessor-Frontend
使用技術
- React (React Hooks, React Router)
- TypeScript
- Tailwind CSS
- Ruby 2.6.6
- Rails 6.1.32
- MySQL 8.0.23
- Heroku
- Docker/docker-compose
- Figma
- Notion
- drawio
- VScode
機能一覧
ユーザー機能
- ユーザーの新規登録
- プロフィール画像の追加
- ユーザー情報の編集
レシピ一覧
- 人気のレシピ トップ３
- 早くできるレシピ トップ3
- 最近追加したレシピ
レシピ投稿機能
- 材料、手順を複数追加可能
- 関連するタグ追加可能
お気に入り機能
- レシピのお気に入り登録、解除
- お気に入りしたレシピの一覧
検索機能
- レシピ名をキーワードに検索
- 関連するタグ、材料から検索
コメント機能
- レシピのコメントの投稿、削除
- コメントの一覧
ER図
##Notionでタスク管理、設計
Notionという有名なタスク管理ツールでAPI設計、ミーティングメモ、重要な情報等を保存し、タスクを管理しました。
##FigmaでUI設計
メンバーの方にFigmaというこれまた有名なデザインツールでUI設計していただき、それを元にFigma to Codeというプラグインで実装していきました（個人的に、このプラグインはそれほど使えなかった）。
##環境構築
docker-composeでサービス（rails、react、mysql）をつくろうとしましたが、なんやかんやで1週間以上経過。最終的に1人がdocker-composeファイルをフロントとサーバーサイドで分けて別々で構築したいと提案し（そうじゃないとややこしくてできないと主張）、フロントとサーバーサイドのフォルダに分けて構築しました。
##git管理
Fork→cloneしたリポジトリがFork元を追跡するようにし、オリジナルのリモートリポジトリに変更を及ぼすことなく変更をテストすることができるようにしました。
設定方法
①GitHubから開発したいリポジトリ(オリジナルのプロジェクトのrepo)のページへ飛び、Forkボタンを押します。
②Forkしたリポジトリ(組織じゃなくて自分のアカウントのレポジトリ)からcloneします。
git clone git@github.com:user_name/app_name.git
③ここで git remote -vを打ってローカルにcloneしたレポジトリがどのように関連づけられているか確認します。
ここで、オリジナルの方がoriginになってたらオリジナルのmasterを変更してしまうことになるので、originのURLを変える必要があります(おそらくそうなってたらOriginalの方からcloneしています)。
$ git remote -v
// Forkしたリポジトリのみがoriginとして表示されます
origin git@github.com:user_name/app_name.git (fetch)
origin git@github.com:user_name/app_name.git (push)
// もしOriginalの方をoriginとして登録されていたら
$ git remote set-url origin YOUR_FORK_REPO_URL
④Fork元のリポジトリをローカルのリポジトリに関連づけます(URLを追加する)
$ git remote set-url upstream ORIGINAL_REPO_URL
⑤upstreamとしてURLが追加されているか確認
$ git remote -v
origin git@github.com:user_name/app_name.git (fetch)
origin git@github.com:user_name/app_name.git (push)
upstream git@github.com:team/app_name.git (fetch)
upstream git@github.com:team/app_name.git (push)
⑥(upstreamとしてOriginalのリポジトリをURLに登録した後) git fetch upstream でリモートにあるOriginalの最新の変更状態をローカルに持ってきます。
⑦git merge upstream/master で、自分のいるローカルのブランチにOriginalのローカルリポジトリ(upstream)のmasterブランチの変更分を適用させます。
⑧ローカルで開発を進める。
個人的おすすめは git add 前にOriginalの変更分をfetchしておくこと
git stash → git fetch && merge → git stash apply → git add && commit && push
ローカルのoriginリポジトリ(Fork先の個人用リポ)へpushを続けていれば、組織のOriginalブランチに影響を及ぼさず、個人レポジトリで開発進められます。
特に苦労したこと
設計、環境構築までは空いた時間ながらもメンバーと協力し合い順調に進んだのですが、開発を進めていくうちに就職活動等でメンバーの方々が忙しくなり、まともな開発時間を有するのは僕だけになりました。このとき僕も共同開発後の予定を立てており、1人で悠々と作業を進める時間はありませんでした。このままでは、計画も意味をなくし、共同開発が断念される恐れがありました。
どうやって乗り越えたか
それでも何とかサービスを完成させてデプロイまで終わらせたいと考えた僕は、メンバーと話し合い、機能の削減、メンバーの必要最低限の作業などを提案し、その後の開発は僕が中心となって進めました。そして、実装したい機能を妥協しながらも、許容範囲の期間でデプロイまで終わらせることができました。
まとめ
設計やgit管理など、個人開発とは違った実務に近い良い経験ができました。また、ほぼ無知だった僕にNotionなどのツールや専門知識などをお教えくださり、メンバーには感謝の気持ちでいっぱいです。優秀なメンバーの方々に負けないようこれからも頑張っていこうと思います。
気がかりとしては、まともなissue管理ができなかったので、今後は複数人での開発に向けてissueの扱いを学んでおきます。