プロジェクト情報

チーム名:鍋いらず(一鍋+マグロ)

参加者:FE 4名(洪都賢、朴経書、李根輝、金正洙)、BE 2名(朴光洙、崔昌煥)

内容:ワン鍋ページクローンコード

期間:3/28~4/8

Github : https://github.com/wecode-bootcamp-korea/31-1st-Dont-SOT-backend

使用技術(バックエンド):Python、Django、Git&Github

計画と記録:Notion、Trlo、Snak

実施範囲(バックエンド):ホームページAPI、商品リストと詳細ページAPI、会員登録API、カートAPI

プロジェクト履歴

1 . Modeling

「モデリングを簡単に思いつき、近づいてきました」「どうして2日から3日投資するの?」
db構造のモデリングは、プロセス中にdb構造を更新、追加、または削除するのは面倒でリスクがあるため、重要です.
発射角が0.1度からずれると、軌道が完全に変わった宇宙船のように、プロジェクトの初期の方向によってどれだけ理想的に設定されているかによって、後期にモデルを修正する際の面倒を減らすことができる.
最終的に私たちのプロジェクトも途中でリニューアルされました.どのような構造で2倍の選択肢を実現するかを正確に決定すべきである.

1次モデリング

二次モデリング

2回目のモデリングを続行できませんでした.オーダー機能(order)は、オプションの簡略化と不要なテーブル削除のため、時間的な理由で実現できません.

最も印象的なモデリング(2つの商品をどのように管理するか)

class Product(models.Model): 
    name             = models.CharField(max_length = 30, null = True)
    price            = models.DecimalField(max_digits = 10, decimal_places = 2)
    description      = models.TextField()
    calory           = models.DecimalField(max_digits = 10, decimal_places = 2, null = True)
    category         = models.ForeignKey("Category", on_delete = models.SET_NULL, null = True)
    relative_product = models.ForeignKey("self", on_delete=models.CASCADE, null=True)
    sales            = models.IntegerField(default = 0)

1鍋メニューには、各商品に2人前追加、海苔追加などのオプションがあります.乗算のみを実施することにした.relative_productcolumnはこれに関連している.例えば、pkが1の製品がフライドチキンmayo(通常)であり、pkが2の製品がフライドチキンmayo(乗算)である場合、2番目のrelative_productcolumnでは1番目を参照する.この場合、1番目のrelative_productcolumnはNullの値を有する.relative_productcolumnがNullであるかどうかによって、普通か2つの商品かを区別し、フロントから2つの商品かどうかを受け取り、結果によってこの製品を識別することができる.

悩みの種

練習用DBと実際のDB:最初はクローンコードだったので、完璧な製品計画ができたら、完全なDBを使ってAPIを作成することができます.実際、少し考えても、このような理想的な状況はあり得ない.これもAgileの考えではありません.もちろん、練習用DBは無理なく記入し、最後に実際のDBを入力してください.事実上、事はそうするしかない.

拡張性への悩み:2倍を選んだときの悩み.実際、フロントと合意したのは2倍減算オプションのみであるが、他のオプション、例えば海苔の追加などを実現するためには、以上の自己参考形式では実現しにくい.より多くのオプションを追加する場合は、明らかに別のオプションテーブルが必要です.既存または継続的なプロジェクトであると仮定した場合は、オプションテーブルを作成する必要があります.後で再開発する場合、データベースの変更を追加する必要がありますか?

2. API

私が担当している部分は会員の入金とCARTロジックです.

会員の入社ロジックを実現すること自体は一度経験したことがあるので、難しくはありません.しかし、いくつかの詳細を考慮する必要があります.

悩みの種

FE、BEは、認証、パスワード、電子メールのフォーマットチェック(検証)をどこで処理しますか.すべてBEで処理すると、不要な通信が多すぎて、検証要求をリアルタイムで送信するのはリソースの無駄になるようです.そこでFE根輝はLANDERINGで1回目の有効性検査を行い、2回目の会員加入要請を受けた時にバックグラウンドで検査を行う.しかしパスワードの有効性チェックはバックグラウンドで行うことにした.(これは安全上の問題かもしれません)

カートがFEと通信するとき、product idとcart idのどちらに基づいてカート数を変更または削除しますか?上記の自己参照で乗数を定義すると、乗数を使用するか否かによって異なるproduct idを持つことになるので、当初は混乱防止のためcart idを基準に通信することにした.

新しく知り合ったもの

get_or_createショッピングカートの作成を容易にします.

cart, created = Cart.objects.get_or_create(user = request.user, product_id = product.id, defaults={'quantity': 1})
            
  if not created:
    cart.quantity += 1
    cart.save()
    return JsonResponse({"message" : "UPDATED"}, status = 200)

annotate仮想カラムの作成および使用に使用できます.

from django.db.models       import Case, When

def get(self, request):
        carts = Cart.objects.filter(user = request.user).annotate(
            has_relative_product = Case(When(product__relative_product__isnull = True, then=False), default=True)
            )

2つのリファレンスバー(上のコードに示す)を使用して、リファレンスキーを使用して他のカラムにアクセスできます.

Path Parameter、Query Parameterを使用して通信します.
ただし、RESTfulに設計されていることに注意してください.

複数の場合の通信は、default値を使用して1つのAPIで1つの論理として処理することができる.(典型的なプロダクトリストフィルタロジック)

反省する

今回のプロジェクトを通じて、反省と改善すべき考えをお話ししたいと思います.

trello使用未成熟:trelloチケットを詳細に特定するのは難しい.プロジェクトは既に1回行われており、次のプロジェクトはより詳細に作成されます.

「YES,ICAN」:FEがリクエストを受けたとき、私は楽観的で、大まかな論理だけで「やる」ことができます.この言葉は優勢を占めている.実際にエンコードを行うと、思わぬインターセプターが出てきて、パニックになる瞬間が一つや二つあります.期限はもう决まっているが、これからは油断しないように気をつけなければならないと思う.

AGILE:思ったより敏捷になるのが難しい.通常、私がAPIの作成を完了しても、フロントでは仕事が完了しないことがよくあります.この場合、私は事前に後のAPIを作成したり、個人のために勉強したり、チームのために記録したり、他の貢献をしたりする必要があります.しかし、他の条件が許されず、私の仕事が停滞していると思ったとき、私は何もできませんでした.私の姿を見て、私もこのような状況でどうすればいいか考え始めました.

projectはハングルで書かれた「コミュニケーション」で、最初のプロジェクトの経験はコミュニケーションの開始からコミュニケーションの終了までの経験です.隣のバックグラウンドのチャンファンと役割を分担してから、フロントとの通信にキー値を設定します.事の順序を相談し、計画を立てる.本当にこまごましたのは一緒に昼食を食べて、隊員たちと絆を結ぶことです.それでも簡単にコミュニケーションが取れるのは、他のチームメンバーの積極的な努力のおかげです.