チーム開発で学んだこと〜The HACKチーム開発第2回〜
今回参加したチーム開発について
コミュニティThe Hackにて同じお題についてランダムなメンバーでチームを組み、それぞれで開発を行うというイベントが開催された
お題
「Next.js と Ruby on Railsを利用したUGCサービスの開発」
条件
- Next.js でフロントを実装
- Ruby on Rails をAPIとして利用する
- RSpecを用いたテストを書く
- Asanaを利用したプロジェクト管理
- ログインがあり、ログインした人のみが投稿できる（何を投稿するサイトかはチームで考えてください！）
- /my-profile のパスで自分の情報が見れる
期間
2023/1.11-2.18
開発環境
フロントエンド
Next.js： "13.1.1"
Tailwindcss： "^3.2.4"
typescript: "4.9.4"
バックエンド(APIとして)
Ruby: "3.1.2"
Ruby on Rails： "7.0.4.2"
データベース言語
MySQL2： "0.5.5"
サイトの概要
タイトル:『シェアがし』
自分のお気に入りお菓子の口コミを投稿できるサイト
このサイトを作ろうと思った経緯
納期がバレンタイン付近であったため、携帯片手で世の中においしいお菓子をシェアしたいという思いから企画🍫
このサイトでできること
| カテゴリー | # | 機能名 | 説明 | 非ログイン時 利用可否 |
|---|---|---|---|---|
| 認証 | 1 | サインアップ機能 | ・メールアドレス・パスワードで会員登録できる。 | ◯ |
| ・ログイン時のみ利用できる機能が利用できるようになる。 | ◯ | |||
| 2 | ログイン機能 | ・メールアドレス、パスワードでログインできる。 | ◯ | |
| ・ログイン時のみ利用できる機能が利用できるようになる。 | ◯ | |||
| 3 | ログアウト機能 | ・ログインしている状態からログアウト状態にする。 | × | |
| ・ログイン時のみ利用できる機能が利用できなくなる。 | × | |||
| 投稿 | 4 | 投稿一覧表示機能 | ・投稿を一覧表示する。 | ◯ |
| 5 | 投稿詳細表示機能 | ・投稿一覧画面で選択した商品の詳細情報を表示する。 | ◯ | |
| 6 | 投稿編集・削除機能 | ・ 自分の投稿記事の編集、削除ができる。 | × | |
| 7 | 自分の投稿一覧表示 | ・マイページで過去の自分の投稿を一覧表示する。 | × | |
| ユーザー情報 | 8 | 会員情報編集機能 | ・登録しているユーザー情報を編集することができる。 | × |
サイトに使用した技術詳細
GitHubのREADMEをご参照ください
チーム内で気をつけたこと
初回ミーティングで各自のスキルや稼働時間の確認などをおこない、個人のタクスが過重負担とならないよう配慮しつつ開発を進めていけるよう心がけた。
タスク管理の方法
Asanaを使用してカンバン方式でタスクチケットをきり、ToDo、進行中、レビュー中、完了と移動していき、タスクの進捗状況や残っているタスクが一目でわかるよう管理した。
また、タスクが移動をしたことを周知するため、各自が担当するタスクや、プルリクを行った旨などの声かけをSlackでも行うよう心がけた。
学んだこと
Git、Githubの操作
チーム開発ではかかせないGitの操作について不慣れなメンバーもいたため、初歩的なことでも不明点をメンバーに教えてもらいながら徐々に使用に慣れていった。
途中、mergeの際の手順を誤ったり、develop用としてメインで使用していたdevブランチが消えると言うアクシデントなどもあったが、その都度周りのメンバーのフォローのおかげでなんとか開発を続けることができた。
使用したことのない言語にふれる
普段使用していない言語についてもふれることができ、コードの書き方やフレームワークとの相性など、実際の開発で必要な知識に触れることができた。
中にはRubyは全く初めてというメンバーもいたが、チームメンバーやThe HACKのメンバーにサポートしてもらいながらコードを実際に書いてみるという経験ができた。
ドキュメントや参考記事の検索方法
わからない部分について質問すると、メンバーから参考記事つきでアドバイスして教えてもらえることも多く、自分1人では辿り着けなかった検索方法を新たに発見することができた。
フロントとバックの繋ぎ込み
今回の開発の醍醐味はおそらくここ。
バックエンドでAPIとして受け渡すデータをフロントできちんと受け取ることができ、フロントからの情報をバックエンドのデータベースに保管することができるか。
データ型の相違や命名の食い違い、エンドポイントが確実にあっているかなど、細かいすり合わせが必要となるため、初期段階での打ち合わせがとても重要だと感じた。
Serverメモリ使用感について
メモリの使用量が思ったより高く、1GBでは不足する。
1CPUでのメモリ状況は、node 766M/mysql 422M/rails 176Mだ った。Mysqlについてはチューニングすれば抑えられると思うが、node.jsは厳しい。
サーバーのメモリ は、最低2GB...できれば3-4GBは確保したいところ。格安VPSで使用できるメモリは1GB以下であるこ とが一般的なので外部のに公開する場合はメモリには注意が必要である
苦労・工夫した点
-
Railsのdevise 認証Gemについて
deviseとは、Railsで一般に使われている認証Gemである。今回の開発では認証が必要だったので利用した。
このGemではHTTPヘッダーを使ったbearer認証 を行うことができる。そのほかサインアップやメ ールでのパスワード忘れ対応など、認証に必要な機能は一通りそろっている。さらに、クラス派生させ 複雑なカスタマイズをすることが可能。
これだけ機能が多いライブラリで多くの使用実績を持つライブラリだが、適当なWebページの設定を鵜呑みにした設定やカスタマイズするのは危険である。
記述者が持っている情報が古いなど正確な情報で はない場合があるからだ。 参考にした場合信用できるドキュメントを確認し、実際のソースを確認したり動作テストを行う必要がある。
デフォルトでサポートされないのには理由があるものだ。
セキュリティ上の問題が発生する可能 性があるものは仕組みを理解せずに簡単にコピペで実装していいものではない。
チーム開発内部では、これをcookie認証に対応したという報告がslackにありフロントエンド側もそれに準じた開発を行っていた。しかし、いざ接続しようしたところ期待した動作にはならなかった。
調査してみると、担当者はbearer認証の情報をcookieに保存しておき認証の際にはヘッダーにaccess_tokenを登録するbearer認証を使用することを考えていた。
実績が多く信頼におけるGemだという理由で単体でのテストを省略したことで、思った通りに作動しない理由を突止めるのに時間を要した。 -
Railsのpry-byebug デバッグGem
pry-byebugは、従来よく使われてきたpry-railsに変わるデバッグ用のGemである。Webアプリケーションに対してステップ実行をすることができるため、使用方法によって効率的にデバッグすることができる。
インストールはGem登録しソースコードにbinding.pryと記述するだけ。
Railsがbinding.pryに遭遇し、デバッグする手順はつぎのものである。
** 手順1 ブレークポイントをソースに記載する。
class Api::V1::CategoriesController < ApplicationController
def index
binding.pry #止めたいところに記述する。 categories = Category.all.order(id::asc) render json: categories,adapter: :json
end
end
** 手順2 railsを起動する。
rails s
** 手順3 httpでアクセスする 別のコンソールからhttpアクセスを行う。ここではAPIをcurlで呼び出す。
curl localhost:3001/api/v1/categories -X GET -H "content-type:application/json"
** 手順4 railsを起動した画面でブレークされる。
あとは、自由に進められる。
主なコマンド
| コマンド | 動作 |
|---|---|
| next | 次の行を実行(メソッド内に進まない) |
| step | メソッドであればメソッドの中へ |
| @ | ソースの再表示 |
| quit | 終了 |
| 変数名 | 内容表示 |
| ls | 使用できるオブジェクトの表示 |
変数内容を確認する場合、ここではcategoriesと入力する。 取得の際に実行されたSQLも確認することができる。
pri-byebugではGemの中でもステップ実行やブレークポイントを設定できるので、Gemの動作を確認 する場合は非常に役に立つ。
- OGP画像の取得について
Next.jsでOGP画像を取得しようと思ったとき、「data.json」にあらかじめ指定されたドメインからしか取得できないことが発覚。
となると、新規投稿者が投稿した際にその都度ドメインを登録しておかなければならない・・・。
自動でデータを飛ばす方法など何か改善の策があるはずではあるが、開発の終盤に気がついたため今回は応急処置にて対応。Next.jsにて準備されているimageを使用せず、あえてimgタグを使用することで画像の表示を無事行うことができた。
通常であればimageを使用することでデータの軽量化が測ることができるなどの恩恵を受けることができないためあまりおすすめの方法ではないが、今回はそこまでデータ量が多くないアプリケーションのためこの方法を採用とした。
ライブラリの特性をよく理解した上でどのような技術とかけ合わせていくのが良いか、よく検討しながら開発を行うことが必要。
※ちなみに、Next.jsを使用してOG：imgを呼び出す際は「Cloud Storagen」などのストレージサービスを利用して、一度格納されたものをそのドメインから呼び出すような設定が多い
改善が望まれた点
今回の技術については明るくないメンバーも多い中、プルリクの範囲を大きく切り出しすぎていたため、レビュアーの着眼点が多くなってしまい負担をかけてしまった。
結果的になかなかマージできないプルリクが溜まってしまい、なかなかパーツ同士の繋ぎ合わせが進まなかった。
もっと細かいタスクでチケットを切って、サイト全体を徐々に繋ぎ合わせていくためには、全体像をしっかりと把握しておくことに加えて、経験とセンスが必要だと感じた。
また、プルリクやレビューの際のコメントに至っても、内容の不足やわかりにくい部分もあったかと思うが、そんな中でも、相手への思いやりとセンスが感じられるメンバーからのコメントはとても参考になった。
Dockerなどの仮想コンテナを使用していないため、個人の開発環境の構築の影響がしばしば。。。
初回ミーティングでもう少し検討しておく必要があったかもしれない。
とりかかりは早かったが、設計にぬけもれが多かったため、その部分が手戻りとなり時間を要した。
設計をもう少し固めてから実装を始めるほうが結果的に近道となることを学んだ。
まとめ
技術や経験に差があるメンバーでのチーム開発の大変さを感じる1ヶ月間だった。
経験のあるメンバーからすると、基本的操作で足踏みをしている状況がもどかしい場面も多々あったかと思う一方、経験の浅いメンバーからすると自分が迷惑をかけてしまっているかもという申し訳なさも少なからずあったかと思う。
しかし、チーム1全体で見ると、誰かが困っていればSlackで助け舟の帆が上がり、休日や仕事終わり(時には帰宅中や職場から！)gatherで手解きしてもらったり、仕事が忙しい中ミーティングに参加して作業を分担してもらったりと、あまり自信がなくても「これやってみたい」と手を挙げやすい環境だったのではないかと思う。
常にお互いのことを尊敬し、感謝しながら作業を進めていくことで、甘いスイーツのようなサイトが完成していれば良いなと思っている。
Special Thanks
この記事を書くにあたり、自身の知識だけではなくチームメンバーの貴重なご意見も織り交ぜて掲載させていただきました。
約１ヶ月、それぞれ忙しい仕事のすきまをぬって開発をすすめてくださったチームメンバーに大感謝です！！！
あるどん、おさむ、ふじもと、まえけん、猫屋敷、ワタ（敬称略、あいうえお順）本当にありがとうございました😊
最後に
今回のチーム開発は、The Hackというコミュニティで無作為にメンバーをわりふられ、職業もスキルもバラバラのメンバーで3つのチームが結成された。
ほぼ初対面のメンバーも多いなか、1つのチームとして1ヶ月間アプリ開発を進めて行くのだが、オンラインならではの難しさや、オンラインだからこそ味わえる楽しさを存分に経験することができる。
また、スキルの異なるメンバーを取りまとめていく過程でも、チームそれぞれの特性が強く出ていたのではないかと思う。
参考までに、他のチームの記事も掲載させていただいたので、ご興味がある方はぜひご覧いただきたい。
チーム2
チーム3
The Hackでは今後もこのようなイベントが企画される予定とのこと。
チーム開発に興味はあるけど自信がなくてなかなか踏み出せないというプログラミング初学者も、The Hackで最初の1歩を踏み出してみるのも良いかもしれない。
Discussion