중간 피드백

회고 리뷰

서버 분리

• 인프라적인 고도화 보다는 개발에 좀더 집중하는것이 좋을것 같다.

• 0점대 버전이기때문에 1차 MVP 개발에 좀더 집중하는것이 좋다. 기간이 짧기때문에 굳이 운영 개발 서버를 나눌 필요는 없을것. 당장 운영하는 것이 아니면 일단 develop 서버만 두어도 될것같다.

• 서버 분리는 현재 프로젝트에서 우선순위가 높지 않다 (실제로 운영하지 않는다는 가정) 수료를 위한 프로젝트이니 개발이 더 중요하다.

문서화

• 문서화는 필수
• 시각적인 자료 (시퀀스 다이어그램)을 활용해야 해당 이슈에 대해 잘 모르는사람이 이해하기 쉽다.
• 기능이 동작하는 흐름을 담아서 문서화를 해놓으면 좋을것

테스트 코드

• 테스트코드 중요하다.
• 실제 api 동작은 확인해봐야한다.
• 코드를 잘못짤 수 있다. 이런 부분을 테스트를 통해 면밀하게 확인해봐야한다.
• 테스트코드는 통과했지만 실제 로직은 다르게 동작할 수도 있다.

• 개발이 끝나고 나면 어떤부분들이 테스트가 필요한지 체크리스트를 만들어서 체크리스트를 토대로 배포할때 테스트 하면 좋다

• 테스트 코드에 의존하기 보다는 테스트 코드 뿐만아니라 실제 서버를 띄워서 테스트를 해보는것이 좋다.

코드 리뷰

컨벤션이 맞지않는다.

• 줄바꿈에 일관성이 없다.

• 코드리뷰시 깃허브에서 변경사항을 적용(빨간줄, 초록줄)하는데 이때 가독성을 생각하고 컨벤션을 맞추는게 좋다. 이것도 다 비용이다.
• 아래부분도 마찬가지로 .orElseThrow 뒤가 제각각이다. 컨벤션 맞추는게 좋을것
• Product.builder가 너무 길다. productCreateRequest를 product의 생성자로 넘겨서 생성하는것도 방법
• 서비스에서 dto를 반환하고 있는데 컨트롤러에서 도메인을 반환한고 dto는 컨트롤러에서 만들어주는게 좋을것 같다. 서비스에서 dto를 만들면 다른곳에서 코드를 사용하지 못한다. 이렇게 하고싶다면 컨버터를 사용하는것도 방법, 현재 방법은 worst라고 생각된다.

• winner == null 이부분부터 절차지향적임

• winner는 product가 갖고있음

• 도메인에서 로직을 실행하는게 깔끔하다.

RequestDto를 받는데 CreateDto가 따로 나온부분에 대해

• 컨트롤러로 들어오는 Request가 변경 가능하다면 서비스로 넘겨주는 DTO도 변경가능하다는걸 생각해야한다.

• accessToken의 수명이 너무 길다. accessToken의 수명을 짧게 하고 리프레시 토큰을 두도록 하자.

• 아직 방식을 몰라서 제대로 알아보고 적용해보겠습니다. 플젝 끝나고

• jwt 강의코드를 더 응용해보자

빌더 노출 관련

Security

API에 대한 권한테스트

중간 피드백 총평

• 배운게 적용이 안돼있다.
• 5개월동안 코드리뷰 받고 아무튼 하시라고요

• 레이어간 dto만드는것, 애매하다.

• 컨벤션 지키자

• 기본개념을 정립하자
• 기본 개념 생각해보시고요

• 도메인 단위로 돌아가라 (코드가 절차지향적이다)

• 코드가 길어지는것 자체가 객체지향적이지 않다.

• 생각을 너무많이함
• 심플 이즈 더 베스트