最初のアイテム-4.まとめ

1.プロジェクト紹介

概要

勤務時間:2週間(10/5~10/15)

係員:フロントエンド4+バックエンド2

プロジェクト内容:E-コマースサイトクローンコード(外部バインド以外)

リンク

作業内容

ホームページ:優先順位で並べ替え、N個のベストメニュー

を表示する

会員入力/ログイン:bcrypt暗号化パスワードを使用し、JWTを使用してトークンをユーザーブラウザlocalStorageに格納し、特定の要求の下で

を検証する.

カタログ:カテゴリまたは優先度の高い順に並べて、商品を露出します.
->表:商品、カテゴリ(正を参照)、はい(1-N)

商品詳細:商品詳細
->表:商品、カテゴリ、はい、詳細画像/テキスト(1-N)、ラベル(N-N)

商品検索:キーワードによる商品検索
->名前またはハッシュタグに基づいて

を検索

好:商品情報に商品カテゴリの良い数字を表示します.ログイン時に「いいね」を選択/キャンセルし、ユーザーが「いいね」をクリックした商品を表示します.

ショッピングバスケット:商品情報に量を追加し、単独で格納する.登録可能

注文(点差検定):会員情報に格納されている点差を

注文に減らします.

ロール＃ロール＃

完全なERD作成とモデリングの概要

商品モデリング、商品リスト作成/詳細照会と検索機能

2.テクニック

バックエンド
Python(言語)、Django(サーバ)、MySQL(データベース)、Git/GitHub(バージョン管理)、bcrypt/JWT(暗号化)、AWS EC 2/RDS/S 3(クラウドコンピューティング)

フロントエンド
JSX, React(CRA), Sass(React-outer-DOM)

共有したいコード

1つのデータを考慮すると,テーブル間の関係は1:Nである.
表から複数の商品を基に情報を抽出する必要がある場合、
DBへの接続を減らすために、以下のコードが記述されています.

product_queryset= Products.objects.select_related('category').values(*[keyword_dicts[key] for key in keyword_dicts])
product_id_list = [product["id"] for product in product_queryset]
likes           = Like.objects.filter(product_id__in=product_id_list)
likes_list      = Counter([like.product_id for like in likes])



for product in product_queryset[:20] :
    curr = {}

    for keys in keyword_dicts :
        curr[keys]   = product[keyword_dicts[keys]]
        curr["like"] = likes_list[product["id"]]

3.協力経験

錯覚

プロジェクトが終わる前に、私はコミュニケーションが上手だと勘違いしました.私はまずお互いに必要なものを分かち合ってから話をしたと思っていましたが、事実はそうではありません.
私は1日でモデリングを完了し、チームメンバーとデータモデルを共有しました.

翌日、フロントはページごとに必要なデータを提供するように要求し、その後、フロントの要求に従って1時間以内にAPIを作成し、ベースの偽データを入れる.その後、フロントに何か必要なものがあれば、要求通りに変えればいいのですが、私がしなければならないのは再構築だけだと思います.

しかし、現実は私が想像していたのとは違います.これは双方が初めて協力したからだ.

に質問

今回見つけたコミュニケーションの問題は….

私が共有しているERD、Modelingは、チームメンバーがウェブサイトを見る時間がない前に、私が説明していないうちに「捨てる」情報になったと思います.各ページに必要なデータリストを返すことを望んでいますが、最終的には、聴衆の立場を考慮しない情報の入力は時間の無駄です.これはバックエンドとフロントと同じです.

APIに問題が発生した場合、フロントにバックエンドと交差して検証するタイミングがあり、誰の問題なのか分かりません.HTTPIEで確認すると、データは正常に見えます.しかし、BODYが空き状態であれば、エラーが発生することを知らず、時間を無駄にしてしまう.問題を迅速に解決するために、私は先に聞くべきだ.

フロントでは、バックエンドが提供するAPIに時間がかかっても、自分で加工する能力があります.私もナンパしにくい人です(毎日イヤホンをつけています).したがって、バックエンドの変更を直接処理すると、より迅速に適用できるコンテンツは、より長い時間を要する.

開発外の遺憾

偽データ(mock data)でも、もっと誠意があればどうなるのでしょうか.現在の業界では、ページ管理者がアップロードするデータだと考えており、「これは私がしなければならないことだ」とは思わなかった.でも時間のある人がやればいいです.バックエンドは比較的時間があります.

仕事ごとにAが完成しなければBできないことは知っているが、仕事の順番はそうではない.だから私はいわゆるPM、プロジェクトマネージャーが必要だと思います.今度誰もやらないなら私もやる

に感銘を与える

コミュニケーションの時間が長いです.「これも知らないの?」した部分は、私は言わないで、他の人は絶対に知りません.コミュニケーションがうまくいくことが本当に大切だと思います.
1日に2~3時間も話したようです.しかし、驚くべきことに、私たちがやっている仕事はクローンコードなので、計画が立てられています.明確な計画がなかったり、自分の目で見て確認できるサイトがなかったりすると、コミュニケーションに多くの時間がかかります.

4. Good/Bad

メリット

DB接続を最小化するコードが作成されました.

コードを作る時間は長くありません.少なくとも私のスケジュールで他の仕事を遅らせることはありません.

悪いコードを強要するよりも、最初から書き始めたほうがいい.最初はAPIを素早く提供するために書かれたコードで、再包装の過程で時間を無駄にしていましたが、次からはできないことを学びました.

バックエンドはAPIなどを作成する際に,ページではなくデータストリームに基づくことを学んだ.

今になってやっと,オブジェクト向けとは何かを無理に考えることができ,プログラムガイドのコードを書くことができるようになった.次は、対象に着目します.

残念-個人

最初はAWSにサーバをアップロードする時間と機会がありましたが、仮想環境バージョンが使いにくいため延期されました.最終的には、フロントエンドがアドレスを変更し続ける時間の無駄になります.

利用可能なAPIリストを提供できませんでした.GETリクエストだけが必要だと思っていたので、別途APIを作成する必要はないというのは間違いです.JSONビューアを使って、Chromeで見やすい方法を広めたと思いますが、やはり別にあげるべきです.また、POSTリクエストは私が仕事をしなくても、事前にAPIリストを見せてくれるべきだったが、他人のコードであることは気にしないので時間を無駄にした.

協力も仕事の重みも決まっているので、私の仕事を完成して何をするべきか分かりません.他のバックエンドメンバーのボリュームに欲があるので、進捗状況を聞いたり、やるかどうかを聞いたりして、締め切り時間を決めてから待つべきです.理由もなく自分の不安や焦りを他人に伝えるようです.チームメンバーを信じるには、チームメンバーが先に助けを出す前に、感情を傷つける行為を試してみましょう.

より多くの部分(注文、配送、決済...etc)を行うことができ、協力という他のバックエンドチームメンバーの仕事を待つことを口実に、遅延はありません.正直できるはずだったのにしかし、時間が意味を持って書かれているわけではありません.何をするべきか分からず、興奮する時間があったようです.

モデルでは共通点を減らすとは思わなかった.(createdat, updatedat)

ポスト

まずは短時間でたくさんの仕事をしてくれたフロントに感謝です.美しさに乏しい私にとって、いわゆるレイアウトを作るのはとても難しいことで、フロントの大量(バックエンドに対して)のファイル/フォルダとプログラムを見ていて、相対的にコードが少ない私は罪悪感を感じます.
また、最小年齢で組長となり、進捗状況を確認して議事録を作成してくれた組長に感謝します.
上手にやったほうがいいと思うより….遺憾だけを残す.