フリマアプリのクローンサイト作成

OVERVIEW

TECH::EXPERTのカリキュラムの最終課題として、 フリマアプリ「メルカリ」のクローンサイトをチームで開発しました。 実際のサイトの様子や開発環境などは以下に記載しております。

YEAR 2020

アプリケーション概要

http://46.51.232.119/

  • basic認証

    • ID: teamb

    • Pass: bbbb

  • テスト用アカウント等

    • 購入者用

      • メールアドレス: buy@gmail.com

      • パスワード: 1234567

    • 購入用カード情報

      • 番号:4242424242424242

      • 期限:01/25

      • セキュリティコード:123

    • 出品者用

      • メールアドレス名:sell@gmail.com

      • パスワード: 1234567

開発状況

  • 開発使用言語、環境等
    • Ruby / Ruby on Rails / Haml / Sass / jQuery / MySQL / Git / Github / AWS / Visual Studio Code
  • 開発期間と平均作業時間
    • 開発期間:20日

    • 1日あたりの平均作業時間:10時間

  • 開発体制
    • 人数:3人

    • アジャイル型開発(スクラム)

    • 毎日3回(朝、昼、夜)のデイリースクラムミーティング

    • Trelloによるタスク管理

開発担当箇所

  • DB設計
  • ○概要  ■必要なテーブル、カラムの選定
         ■ER図の作成
         ■設計を元にREADMEへDB構想を記載
          (モデル間のアソシエーション、各カラムの型やオプション、etc)

  • 商品詳細ページ(フロントエンド)
  • ○概要

         ■商品と紐づいた写真を最大4枚までピックアップ表示させる。

         ■商品へのコメント機能の実装、及びコメント一覧の実装。

  • 商品出品機能(バックエンド)
  • ○概要

         ■Ruby on Railsの”ancestry”というgemを使用し、カテゴリーの階層構造を実装

         ■親モデル(商品モデル)に所属している子モデル(画像モデル)を同時に保存できる機能            

                   の実装

         ■画像を複数枚投稿できるよう、jsを使用し画像投稿用フォームを追加できる機能を

                        実装 

         ■アクティブハッシュ機能の実装(登録項目の選択肢のような、頻繁に修正の必要がな

                        い既存データをdbへ保存せず管理)

         ■記載必須項目が抜け落ちている場合、保存されないようにバリデーション機能を実

                        装

         ■jsを使用し、親カテゴリーが選択された時、紐づいた子カテゴリーの選択フォーム

                        が追加される機能を実装

  • 本番環境へのデプロイ作業
  • ○概要

         ■AWSのAMI(AmazonMachineImage)を利用して本アプリをデプロイするEC2インスタンスをコピー作成

         ■basic認証を実装

         ■画像保存先をS3へ設定

開発を通して

----工夫した点----

1.チームとして工夫を行った点

 まず初めに、アプリ機能の全体像を把握した上で個々の担当した開発に移りました。全体像が掴めたことで、重複したマークアップの実装を引用しあうなど、無駄な工数を削減することができました。また、メンバー間での実装へのアドバイスなども多く見られ、必然としてアウトプットの機会も増えたことで、より良い知識の定着に繋がったと思います。


2.個人として工夫を行った点

 商品出品機能での写真投稿フォームにプレビュー表示を採用することで、視覚的に扱いやすい写真の投稿ができるようにしました。また、プレビュー表示の下部に削除機能を実装しましたが、一枚以下では機能しないように制限を設けることで、誤入力による保存できない現象を避けられるようにしました。利用者の視点に立っての機能実装を意識して取り組めました。


----苦労した点----

①github

 変更点によるコンフリクトへの対処に苦労しました。開発当初は「作業用ブランチ作成からマージまでを順番に行う」というルールでコンフリクトの回避が容易でした。しかし、バックエンドの開発に移るにつれ、前任者のコーディングを確認・修正しながらの作業が増え、以降はコンフリクトを解除する力が必要になっていきました。試行錯誤の中でコンフリクトの煩わしさと解除する力を蓄えたことは大きな経験となりました。


②DB設計

 某フリマサイトを参考にして設計に着手したものの、必要な機能に関連してどのようなテーブルやアソシエーションを組めば良いのかイメージが掴めずにいました。その結果、開発が進むにつれて実装に必要なテーブルやカラムなどを都度追加していく形となり、大きく時間を費やしてしまいました。DB設計の難しさを痛感したと同時に、多くのDB設計を経験することが力を身に着ける近道になると感じております。