Feat/#52/요청받은 정산 관련 api 개발 #61

seongjunnoh · 2024-08-03T06:19:58Z

📝 요약

유저가 요청받은 정산 목록을 조회하는 api 개발
->요청받은 정산 중 현재 진행중인 정산과 완료된 정산을 구분하여 조회
유저가 요청받은 정산에 대해 '송금 완료' 버튼을 눌렀을 시, 해당 정산 요청을 완료처리하는 api 개발

이슈 번호 : #52

🔖 변경 사항

[refactor : 요청받은 정산 목록 조회 서비스단 코드 메서드 분리]
-> 이 커밋부터가 현재 pr 의 내용입니다!

✅ 리뷰 요구사항

현재 개발한 api의 플로우는 유저가 요청받은 정산에 대해 송금완료 처리 요청이 들어올 경우,
유저의 송금완료 처리 -> 송금 요청받은 정산의 완료 여부 확인 -> 송금 요청받은 정산의 완료 여부를 response로 전달
이렇게 구성되어 있습니다

아직 화면설계서에는 없으나 추후에 정산 요청을 받은 모든 유저들이 송금 완료 처리 요청을 보낼 경우, 해당 정산에 대한 완료 여부를 프론트단에
알려주기 위해 response를 success 메시지로만 구성할까하다가 정산의 완료여부를 포함하는 것으로 수정했습니다

혹시 response 구성에 대해 다른 의견 있으시면 리뷰 남겨주세요!!

📸 확인 방법 (선택)

이 기능도 또한 아직 테스트 코드를 작성하지는 못했습니다
postman을 통해서 정산 생성, 정산 완료 처리, 정산 목록 조회 api를 섞어가며 db에 들어오는 값을 확인한 결과 문제는 없어 보입니다!!
빠르게 테스트 코드도 작성해보겠습니당

📌 PR 진행 시 이러한 점들을 참고해 주세요

* P1 : 꼭 반영해 주세요 (Request Changes) - 이슈가 발생하거나 취약점이 발견되는 케이스 등
* P2 : 반영을 적극적으로 고려해 주시면 좋을 것 같아요 (Comment)
* P3 : 이런 방법도 있을 것 같아요~ 등의 사소한 의견입니다 (Chore)

…ckEnd into refactor/#53/현재까지-개발한-api-점검

hyunn522

LGTM! 가독성도 좋고 더 깔끔해진 것 같아요
마찬가지로 코멘트 확인 부탁드립니다~!
아 그리고 앞으로 브랜치 생성하실 때 develop을 베이스로 해주시면 더 좋을 것 같아요!
review 후 수정사항이 발생하면 머지할 때 충돌나거나 꼬일 가능성이 있어서, 일단 머지한 후 다시 파는 게 충돌을 줄일 수 있다고 알고 있어요
급하게 머지 필요하신 건 말씀해주시면 바로 보도록 하겠습니다!!

hyunn522 · 2024-08-08T11:21:43Z

src/main/java/space/space_spring/dto/pay/response/PostPayCompleteResponse.java

+
+    private Long payRequestId;
+
+    private boolean isComplete;             // 유저가 돈 낸 정산의 완료 여부


p2: 정산 요청을 받아서 해당 유저한테 송금을 완료했을 때의 response라면,
타겟 유저 개개인이 정산 완료 여부를 사용하는 곳이 있나요?
타겟 유저한테는 송금 자체가 완료되기만 하면 정산 완료라고 뜨는 것 같아서 여쭤봅니다!

앗 여기 response에서의 isComplete 는 정산 생성자가 생성한 정산이 해당 유저가 돈을 냄으로써 완료가 되었는지의 여부를 프론트단에게 알려주기 위해 추가한 필드입니다!!
저도 좀 헷갈리긴 하네요 하하 리펙토링시에 변수명을 변경해보거나 추가적인 조치를 해보겠습니당

drbug2000

통일된 구조로 되어있어서 읽기 쉬웠습니다

drbug2000 · 2024-08-08T10:20:17Z

src/main/java/space/space_spring/controller/PayController.java

+        // TODO 1. 유저가 스페이스에 속하는 지 검증
+        validateIsUserInSpace(userId, spaceId);
+


p1: 해당PayRequestTargetId가 user꺼가 맞는지 확인하는 과정이 있으면 좋을 것 같습니다.

아하 이런 검증 로직이 있어도 좋을거같네요!! 코드 리펙토링 시에 추가해보겠습니다!!

drbug2000 · 2024-08-08T10:24:53Z

src/main/java/space/space_spring/service/PayService.java

+        // TODO 3. PayRequest의 완료 여부 파악
+        PayRequest payRequest = payRequestTargetById.getPayRequest();
+        boolean payRequestCompleteStatus = isPayRequestComplete(payRequest);
+        if (payRequestCompleteStatus) {
+            payRequest.changeCompleteStatus(true);
+        }


p3: "완료 취소"와 같은 기능이 생길 수 있기 때문에, isPayRequestComplete(payRequest)의 return 값이 false여도 동작 가능하게 수정하면 어떠한가 싶습니다.

물론 현재 기획상으로는 취소 기능이 없어 문제는 없어보이네요. 현재 로직 상 한번 completeStatus=true가 되면 false가 되지 않는 다는 것을 인지하고 있으면 될 것 같습니다.

넵 현재 기획상으로 정산 요청에 대해 송금을 한 유저들이 다시 이것을 취소하는 플로우는 없는거같아 일단 이렇게 구현해봤습니다!
그런데 확장성을 고려하여 말씀해주신 플로우도 생각해볼수가 있군요!! 참고하겠습니당~~

drbug2000 · 2024-08-08T11:14:01Z

src/main/java/space/space_spring/controller/PayController.java

        // TODO 4. 정산 생성
        payService.createPay(userId, spaceId, postPayCreateRequest);

        return new BaseResponse<>("정산 생성 성공");


p2: response에 payRequestId를 넣어 주는 건 어떻게 생각하시나요
프론트 측에서 정산 생성 후 바로 정산 상세보기 화면으로 넘어가는 요구사항이 생기면 필요하다고 생각합니다.
다른 기능들에서도 "생성" API에 response로 성공 여부 뿐만 아니라 생성한 자원의 Id를 넘겨주는 걸 고려하면 좋을 것 같아요

앗 post and get 구조를 위해서 id를 넘겨주는거도 좋다고 생각했지만, 프론트 측에서 정산 생성 후 바로 정산 상세보기 화면으로 넘어가는 플로우가 아니라 자신이 생성한 정산목록으로부터 해당 정산 id를 다시 알기 때문에 굳이 response로 넘겨줄필요가 있을까 싶어서 일단 빼봤습니다!
프론트단과 api 연동과정에서 서로 소통후에 생성 관련 api들의 response로 생성된 리소스의 id를 넘겨주는 방식을 고려해보겠습니다!!

drbug2000 · 2024-08-08T11:36:57Z

src/main/java/space/space_spring/dto/pay/response/GetReceivePayViewResponse.java

+    private List<PayReceiveInfoDto> payReceiveInfoDtoListIncomplete = new ArrayList<>();
+
+    private List<PayReceiveInfoDto> payReceiveInfoDtoListComplete = new ArrayList<>();


p2: 이름이 예뻤으면 좋겠어요
response body에 JSON으로 담겨서 프론트에서 읽어야하기 때문에, Dto와는 다르게 이름이 단순해도 괜찮다고 생각합니다.

하하 변수명에 너무많은 의미를 담았나 싶네요 프론트분들이 읽을거니 단순화시키는것도 좋아보이네요! 리펙토링시에 참고하겠습니다!!

drbug2000 · 2024-08-08T11:39:20Z

LGTM! 가독성도 좋고 더 깔끔해진 것 같아요 마찬가지로 코멘트 확인 부탁드립니다~! 아 그리고 앞으로 브랜치 생성하실 때 develop을 베이스로 해주시면 더 좋을 것 같아요! review 후 수정사항이 발생하면 머지할 때 충돌나거나 꼬일 가능성이 있어서, 일단 머지한 후 다시 파는 게 충돌을 줄일 수 있다고 알고 있어요 급하게 머지 필요하신 건 말씀해주시면 바로 보도록 하겠습니다!!

동의합니다.
앞 내용이 필요한 PR이라면 하나의 PR로 묶는 것도 좋다고 생각합니다!

seongjunnoh

리뷰 감사합니다!! 이전에 작업하던 브랜치들의 코드가 필요했어서 이전 pr의 내용들을 merge해서 작업을 진행했었는데, 말씀해주신 부분에 동의합니다!! 머지가 필요한 코드는 따로 얘기드리거나 알람설정을 해두는 방향으로 해보겠습니다!

seongjunnoh · 2024-08-09T06:49:37Z

src/main/java/space/space_spring/dto/pay/response/PostPayCompleteResponse.java

+
+    private Long payRequestId;
+
+    private boolean isComplete;             // 유저가 돈 낸 정산의 완료 여부


앗 여기 response에서의 isComplete 는 정산 생성자가 생성한 정산이 해당 유저가 돈을 냄으로써 완료가 되었는지의 여부를 프론트단에게 알려주기 위해 추가한 필드입니다!!
저도 좀 헷갈리긴 하네요 하하 리펙토링시에 변수명을 변경해보거나 추가적인 조치를 해보겠습니당

seongjunnoh · 2024-08-09T06:54:03Z

src/main/java/space/space_spring/controller/PayController.java

        // TODO 4. 정산 생성
        payService.createPay(userId, spaceId, postPayCreateRequest);

        return new BaseResponse<>("정산 생성 성공");


앗 post and get 구조를 위해서 id를 넘겨주는거도 좋다고 생각했지만, 프론트 측에서 정산 생성 후 바로 정산 상세보기 화면으로 넘어가는 플로우가 아니라 자신이 생성한 정산목록으로부터 해당 정산 id를 다시 알기 때문에 굳이 response로 넘겨줄필요가 있을까 싶어서 일단 빼봤습니다!
프론트단과 api 연동과정에서 서로 소통후에 생성 관련 api들의 response로 생성된 리소스의 id를 넘겨주는 방식을 고려해보겠습니다!!

seongjunnoh · 2024-08-09T06:54:48Z

src/main/java/space/space_spring/controller/PayController.java

+        // TODO 1. 유저가 스페이스에 속하는 지 검증
+        validateIsUserInSpace(userId, spaceId);
+


아하 이런 검증 로직이 있어도 좋을거같네요!! 코드 리펙토링 시에 추가해보겠습니다!!

seongjunnoh · 2024-08-09T06:57:40Z

src/main/java/space/space_spring/service/PayService.java

+        // TODO 3. PayRequest의 완료 여부 파악
+        PayRequest payRequest = payRequestTargetById.getPayRequest();
+        boolean payRequestCompleteStatus = isPayRequestComplete(payRequest);
+        if (payRequestCompleteStatus) {
+            payRequest.changeCompleteStatus(true);
+        }


넵 현재 기획상으로 정산 요청에 대해 송금을 한 유저들이 다시 이것을 취소하는 플로우는 없는거같아 일단 이렇게 구현해봤습니다!
그런데 확장성을 고려하여 말씀해주신 플로우도 생각해볼수가 있군요!! 참고하겠습니당~~

seongjunnoh · 2024-08-09T06:59:58Z

src/main/java/space/space_spring/dto/pay/response/GetReceivePayViewResponse.java

+    private List<PayReceiveInfoDto> payReceiveInfoDtoListIncomplete = new ArrayList<>();
+
+    private List<PayReceiveInfoDto> payReceiveInfoDtoListComplete = new ArrayList<>();


하하 변수명에 너무많은 의미를 담았나 싶네요 프론트분들이 읽을거니 단순화시키는것도 좋아보이네요! 리펙토링시에 참고하겠습니다!!

Feat/#52/요청받은 정산 관련 api 개발

seongjunnoh added 30 commits July 31, 2024 15:22

refactor : 회원가입 생성 request의 이메일 형식 조건 수정

1e0167d

refactor : 로그인 api request dto의 이메일 형식 조건 수정

634c226

refactor : 로컬 로그인 api response dto 삭제

ab73f6c

refactor : 스페이스 생성 api url 수정

fe40baa

Merge branch 'develop' of https://github.com/KUIT-Space/KUIT_Space_Ba…

e7fba83

…ckEnd into refactor/#53/현재까지-개발한-api-점검

refactor : 이미지 파일 validator 관련 코드 수정

8de2715

refactor : 이미지 file validator 삭제

1a394b0

feat : application.yml 파일에 MultipartFile 용량 제한 설정 추가

3edbd31

refactor : 스페이스 생성 api request 이미지파일 nullable로 변경 & 이미지 파일 확장자 검증 로직 추가

e7b1054

refactor : 스페이스 생성 api 이미지 파일 검증 컨트롤러 코드 리펙토링

658e4dd

refactor : 스페이스 생성 api response dto 삭제

ded8b2b

refactor : getSpaceChoiceView 메서드 return dto 구성 변경

93adc8a

refactor : getSpaceChoiceView 메서드 리펙토링(메서드 책임 분리)

089b25d

refactor : dto 내부 static class 외부로 분리

188e30e

refactor : 스페이스 선택 뷰 response 필드 구성 변경

6d1b79b

refactor : user, space, pay dto 계층구조로 분리

57d088f

refactor : 스페이스의 모든 유저 정보 조회 api 의 response 필드 구성 변경

dbb69d5

refactor : 스페이스의 모든 유저 조회 api dao 메서드명 변경 & 리펙토링

70422d8

refactor : 스페이스의 모든 유저 조회 api response key 이름 변경

171367f

refactor : 내가 요청한 정산 데이터 조회 api response에 정산id 추가

613d314

refactor : 주석 변경

5047201

feat : 정산 상세정보 조회 api dto 추가

199568b

refactor : 요청한 정산 정보 얻는 코드 리펙토링(메서드 분리)

d197777

feat : 하나의 정산에 대한 상세정보 조회 api 서비스단 코드 개발

4d38ea1

refactor : 서비스단 코드 리펙토링

509127b

feat : 정산 상세정보 조회 api 컨트롤러 개발

1661a2e

refactor : 요청받은 정산 목록 조회 서비스단 코드 메서드 분리

7c41a47

feat : 내가 요청받은 정산 목록 조회 api 컨트롤러 & response dto 개발

19ac0ea

feat : 정산 완료 처리 api 서비스단 코드 작성

14ddf6b

refactor : 정산 완료 처리 api 서비스단 코드 return 타입 변경

677b91b

seongjunnoh added 3 commits August 3, 2024 14:46

refactor : 서비스단 코드 메서드 분리

f96ba01

feat : 정산완료처리 api 컨트롤러 코드 개발

b4e1f9b

refactor : controller -> service 사용하지 않는 파라미터 제거

373c8fc

seongjunnoh linked an issue Aug 3, 2024 that may be closed by this pull request

feat : 요청받은 정산 관련 api 개발 #52

Closed

4 tasks

refactor : response dto에 success msg 제거

ab80292

hyunn522 approved these changes Aug 8, 2024

View reviewed changes

drbug2000 approved these changes Aug 8, 2024

View reviewed changes

drbug2000 reviewed Aug 8, 2024

View reviewed changes

seongjunnoh commented Aug 9, 2024

View reviewed changes

seongjunnoh merged commit f42e863 into develop Aug 9, 2024
3 checks passed

hyunn522 deleted the feat/#52/요청받은-정산-관련-api-개발 branch August 10, 2024 17:23

seongjunnoh added a commit that referenced this pull request Oct 30, 2024

Merge pull request #61 from KUIT-Space/feat/#52/요청받은-정산-관련-api-개발

a45b529

Feat/#52/요청받은 정산 관련 api 개발

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat/#52/요청받은 정산 관련 api 개발 #61

Feat/#52/요청받은 정산 관련 api 개발 #61

seongjunnoh commented Aug 3, 2024 •

edited

Loading

hyunn522 left a comment •

edited

Loading

hyunn522 Aug 8, 2024

seongjunnoh Aug 9, 2024

drbug2000 left a comment •

edited

Loading

drbug2000 Aug 8, 2024 •

edited

Loading

seongjunnoh Aug 9, 2024

drbug2000 Aug 8, 2024 •

edited

Loading

seongjunnoh Aug 9, 2024

drbug2000 Aug 8, 2024 •

edited

Loading

seongjunnoh Aug 9, 2024

drbug2000 Aug 8, 2024 •

edited

Loading

seongjunnoh Aug 9, 2024

drbug2000 commented Aug 8, 2024

seongjunnoh left a comment

seongjunnoh Aug 9, 2024

seongjunnoh Aug 9, 2024

seongjunnoh Aug 9, 2024

seongjunnoh Aug 9, 2024

seongjunnoh Aug 9, 2024


		private Long payRequestId;

		private boolean isComplete; // 유저가 돈 낸 정산의 완료 여부

		// TODO 1. 유저가 스페이스에 속하는 지 검증
		validateIsUserInSpace(userId, spaceId);

		private List<PayReceiveInfoDto> payReceiveInfoDtoListIncomplete = new ArrayList<>();

		private List<PayReceiveInfoDto> payReceiveInfoDtoListComplete = new ArrayList<>();

Feat/#52/요청받은 정산 관련 api 개발 #61

Feat/#52/요청받은 정산 관련 api 개발 #61

Conversation

seongjunnoh commented Aug 3, 2024 • edited Loading

📝 요약

🔖 변경 사항

✅ 리뷰 요구사항

📸 확인 방법 (선택)

📌 PR 진행 시 이러한 점들을 참고해 주세요

hyunn522 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

drbug2000 left a comment • edited Loading

Choose a reason for hiding this comment

drbug2000 Aug 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

drbug2000 Aug 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

drbug2000 Aug 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

drbug2000 Aug 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

drbug2000 commented Aug 8, 2024

seongjunnoh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seongjunnoh commented Aug 3, 2024 •

edited

Loading

hyunn522 left a comment •

edited

Loading

drbug2000 left a comment •

edited

Loading

drbug2000 Aug 8, 2024 •

edited

Loading

drbug2000 Aug 8, 2024 •

edited

Loading

drbug2000 Aug 8, 2024 •

edited

Loading

drbug2000 Aug 8, 2024 •

edited

Loading