[バックエンドを無料でロード]8%の企業課題のレビュー👏

✔勘定科目の課題情報

企業名:8%

実施日:2021.11-1.113午前10時

プロジェクトgithub:
https://github.com/Wanted-Preonboarding-Backend-1st-G5/Assignment4

✔️Project Review

######プロジェクトレビュー1-了解

#1取引

)
本課題で実施するアクセスAPIは、アクセス時に要求伝達金額に加えた値で勘定科目の残高値を更新することを要求するが、アクセス時には、勘定科目残高を照会してからのみアクセスできる場合には、要求伝達金額から要求伝達金額を減算した値で更新するデータベース転送処理が必要となる.
実施方法)

既存コード-Transaction外部照会勘定科目

if not account.owner_id == user.id: # 현재 Transaction 밖에서 객체 조회함 
...(생략)
            with transaction.atomic():
                if deal_position_id == DealPositionId.DEPOSIT.value:
                    ...(생략)
                    

質問:コードでは、勘定科目クエリーとトランザクションは直接的なようですが、実際のサービスでは、この2つの間に多くのことが発生する可能性があります.したがって、トランザクションを実行する前に、勘定科目オブジェクトが変更される可能性があります.

改善コード-Transactionで勘定科目クエリーを同時に処理&select for update()を使用して

をロック

with transaction.atomic():
		account = Account.objects.get(id = account_id).select_for_update()	
		# 개선 부분 
    ...(생략)

#2 Enumをオブジェクトとして使用!(クラスとして定義されている場合)

改良コード

class DealPosition(Enum): # Enum 클래스 
    DEPOSIT  = 1
    WITHDRAW = 2

		def is_deposit(self):
				return self == DealPosition.DEPOSIT

		def is_withdraw(self):
				return self == DealPosition.WITHDRAW


deal_position = DealPosition(int(data['deal_position_id'])) # 객체로 선언해서 사용하자! 
...

if deal_position.is_deposit():
...

Deal2021.objects.create(
    account_id       = account_id,
    deal_position_id = deal_position.value, 
    amount           = amount,
    description      = description,
    balance          = account.balance
)

拡張機能:Enumとして定義されている場合は、列挙定数の使用よりもEnumクラス内のオブジェクトの宣言とアクセスが適切です.

#3 Functional Test

)
機能テストE 2 E(End to End)あるいは、ブラウザテストを用いてソフトウェアの内部構造や実施方法を考慮するよりも、実際のユーザが接触したブラウザテストに基づいていると考えられるが、現在のプロジェクトではフロントエンドが実施されていないため、この方向にテストを行うことは困難である
代わりに、ユーザーに一連の機能(会員入力/ログイン/アカウントと取引関連)を構成し、テストしました.
実施方法)
核心機能送金、送金、取引明細照会方案は以下の通りである.

送金案を作成した:ユーザー登録→口座生成→送金→送金取引明細照会のテスト案で、現在の口座残高が最後の送金明細残高と同じであることを確認し、テストに合格した.(テストスキームで行われた送金が最後の取引であると仮定)

入金案:登録→入金→入金取引明細照会の試験案を作成し、現在の口座残高が最後の入金明細残高と同じであることを確認し、試験に合格した.(テストスキームで行われた支払いが最後の取引であると仮定)

取引履歴照会案:登録→アクセス/出帳履歴生成→取引履歴照会のテスト案を作成し、生成した取引履歴(2個)に基づき、「照会時間」は今日、「最近の取引履歴向上」時の応答として、2つの取引履歴データがある.現在の口座残高が最後の取引明細残高と同じであることを確認し、テストに合格した.

しかし、企業が望む内容が正しいかどうかはまだ確認されていません.まず質問を残して、返事を待ってください.直接8%聞いたらどうですか?!

#4 APITestCaseを使用してテストコードの作成時にTokenを検証する方法

)
市場が提供するデフォルトのToken認証方法をプロジェクトの認証方法として使用
実施方法)

 self.client.credentials(HTTP_AUTHORIZATION='token ' + token)  # 토큰 인증을 위한 설정

注意:https://stackoverflow.com/questions/50678609/how-to-add-authentication-token-in-header-of-apiclient-in-django-rest-framewo

#▼▼▼プロジェクトReview 2-感じと改善

#1チームワークのメリット:お客様の疑問を解決し、プロジェクトの方向性を特定
今回の課題で感じたチームワークの最大のメリットは「好奇心のある問題を解決し、方向性をつかむこと」です.課題リクエストには送金/送金API部分があり、最初に私一人で理解したときは「ネットで考えるだけで、送金&送金はペアで構成すべきではないか」ということでした.この問題について質問があり、グループミーティングで「本課題の要求事項ではAPIを預ける/出すしかないので、本人の口座で預ける/出すしかない」と結論づけられた.チームメンバーとのミーティングで、プロジェクトの方向性を一緒に決めることができるのがチームワークのメリットです.
#2 ViewSetはいつも役に立つわけではありません…!
今回の実装では、条件に基づいてaccounts/{account id}/tradelogsという特定のアカウントの取引履歴をクエリするAPIがある.ビューロジックを作成し、アカウント/ルータにマッピングするため、アカウント/{account id}/tradeLogsを使用する他のビューを作成することはできません.実際には、クエリが必要なオブジェクトはAccountではなくTradeLogなので、ページングとフィルタリングをTradeLogオブジェクトに適用するために、一部ではViewSetコードの設定を使用できず、個別に実装する必要があります.現在の考えでは、ビューをViewsetではなくGenericViewや他のビューを作成する方法で実現すれば、各ビューに適切なフィルタやページングなどを容易に適用できる.
If the generic views don't suit the needs of your API, you can drop down to using the regular APIView class, or reuse the mixins and base classes used by the generic views to compose your own set of reusable generic views.
-->DRFのGeneric views公式ドキュメントのセクションを参照してください.関連記事が表示されます.このような状況に応じて適切な実施形態を選ぶことが重要らしい!
#3グループ別の利点:コードを客観的に見る
以前は自分で機能を実現すべきだと思っていましたが、とても意味があって、今回の宿題の時、他の人がコードを書いてくれて、私はそばで一緒に考えて、間違った部分や逃した部分を教えてくれて、コードを書きました.傍らで他人のコードを見るのはとても面白くて、私自身が書いた時と違って、客観的な角度から書いたコードを見て、全体のコード構造を見て、間違ったところを見つけて、とても意義のある経験です.😃

追加

#1異常処理に対して具体的なStatusコードを作成することは,コード作成時にも便利であるようである(同じチームメンバーであるシン・テウのAPI提案学習による)👍)