7/2207/2507/2808/0508/07 (중간 멘토링)도메인 설명 부족도메인테스트엔티티 데이터 삽입 방법을 통일하는게 좋다조회랑 업데이트를 분리해서 생각해라엔티티에 최대한 비지니스로직을 담기예외 메시지중요 엔티티 삭제Reaction 엔드 포인트얘기를 많이 해라Querydsl 알림 처리 → 할 수 있음요청/응답 처리로직 ReadME
7/22
- 프론트와 협업
- API 설계에서 조회는 프론트에 의존적이다. 따라서 필수적인 데이터 예를 들면 식별번호 같은 데이터만 미리 설계하고, 자세한 사항은 프론트에 맞게 개발하는걸 추천한다.
- API 설계에서 CUD는 ERD 설계가 완료된 시점에서는 프론트에 의존적이지 않게 결정할 수 있다.
- 웹에서 익스텐션까지 제공하면 괜찮은 프로젝트가 될 것 같다.
- 프로젝트 설계
- 멀티 모듈을 생각해 봤으면 좋겠다.
- API 래핑
- ResponseEntity는 살작 오버엔지니어링 같다.
- 자세한 점은 프론트와 말해보면 좋을 것 같다.
- 테스트 순서
- 팀간 테스트 작성 순서를 정하는 것도 좋다.
- ex) 성공 테스트 작성 후 실패 테스트
- Why - 테스트 결과를 볼때 한눈에 볼 수 있다.
- final을 필수로 쓰기로 했으면 실수를 방지해주는 tool이 있다. (나중에 공유해 주겠다.)
- 조회 응답 Dto 재활용? → 해보고 무엇이 문제인지 파악해보자!
- 예외
- 사용자 메세지 : 커스텀 exception
- 버그/공격 메세지: 런타임류 exception
- 테스트 관련
도메인 테스트 - 도메인 테스트는 대부분 의존대상이 다른 도메인 객체라서 mockup 할 이유가 없습니다.
리포지토리 테스트 - query를 직접 짠것이 아니라면 굳이 테스트 할 이유는 없습니다. JPA 의존적이라는 생각을 할 수도 있지만, 변화가능성이 0에 수렴할 법한 기술을 갈아끼울수있다고 생각하고 개발하는건 오버엔지니어링 이라고 생각합니다.
서비스 테스트 - 다른 서비스 혹은 너무 복잡한 데이터세팅 (예를들면 통계성 데이터) 같은 경우는 mockup 해도 괜찮습니다.
API 테스트 - api 테스트에서 mockup 해서 슬라이스 테스트를 하는건 사실 통합테스트로 바라보지 않는다는 관점입니다. 해당 관점으로 테스트해도 무방합니다 하지만, 통합테스트는 필요하죠. restTemplate 같은걸로 호출해 테스트하는 방법으로 통합테스트를 해줘야 할 필요성이 있습니다. 보통 이렇게 테스트 해버리게되면 사실 두번 일하는 것으로 느낄 가능성이 크고 실제로도 그렇습니다. 그래서 저는 API 테스트를 통합테스트로 바라보고 슬라이스테스트 하지 않습니다.
외부시스템 - mockup 해야 할 대상입니다. 외부 시스템 우리가 제어할 수 없습니다. end to end 테스트에서 실제로 실행되는것을 테스트해야합니다.
각 계층별 테스트마다 검증해줘야 할 범위와 대상이 분명합니다.한 번씩 생각해보는 시간 가져보시죠
mock check → repository는 글쎼?
transaction 키워드는 service는 필요합니다
repository
@Transcation ?controller
@Transcation ?classic(멘토님께서는 이 방법이 Good) vs mokist(요새 win) TDD
- 이번 프로젝트는 DDD로 했으면 좋겠다.
- DDD 고려 비즈니스 로직이 Domain에 들어가면서 domain에 대한 생각들을 많이 하게 된다.
- 지금 당장 필요한 건 CICD가 아니라 도메인에 대한 제대로 된 이해
- CICD 한다면 Jenkins 추천 github action 후짐;
- 신입으로 큰 회사에 들어가면 CI/CD는 관여하지 못할 확률이 높음.
- CI/CD 환경에서 개발하는 경험은 중요하지만, CI/CD에 보다는 도메인에대한 이해가 더 우선이다.
- 인프라 스트럭쳐 말고는 왠만하면 mocking 하지 않습니다 - 토비님 회사
인텔리제이를 멋지게 쓰는게 중요하다.
테스트 뿐만 아니라 엔티티 에서도 작성 순서를 중요도 대로 하면 좋다.
07/25
우기 멘토님 : 카테고리는 고정이니 엔티티가 아니라 이늄을 으로 관리하는 것이 어떨까?
만약 초기데이터가 필요한 경우다 라면
- 플라이웨이에 넣는다
- 관련 서비스쪽에 포스트컨스크럭트 같은걸로 필요데이터가 있는지 확인 후 없으면 세이브하도록 로직 넣어준다
- 어드민 같은 페이지에서 수동으로 넣는다
- 수동으로 인서트 쿼리를 실행한다
이런 방법들이 있다가장 중요한건 변화 라는 키워드자주 변할만한 곳은 충분히 객체지향적으로 잘 구조화할 필요가 있고, 아닌곳은 절차지향적으로 짜도 된다
07/28
픽스처 만드는데 유용한 프로젝트 소개해주심
08/05
분기 (로직)에 대한 처리는 컨트롤러가 아닌 서비스에서 진행되어야 한다. (→ 리포지토리에서 되도 좋을듯?)
08/07 (중간 멘토링)
도메인 설명 부족
- 모르는 사람이 보면 무슨 코드인지 알 수 없음
- 내가 1년뒤에 봐도 알 수 있는 코드를 쓰자
도메인
- 중요한 필드가 위로
- VO 를 명확히 구분, 내부에서 관리하지 말자
- VO 는 윗 계층에서 접근해도 문제 되지 않음
- enum 대문자로 받거나 추상화를 하거나 해보자
- 상태 관리를 위한 enum 도입 고려
- 동시성 이슈가 생길 수 있는 곳은 @Version 사용하기 (북마크 좋아요 개수)
테스트
- extracting 추잡하다.
- 테스트에서 관심없는 부분은 매직넘버 써도됨
엔티티 데이터 삽입 방법을 통일하는게 좋다
조회랑 업데이트를 분리해서 생각해라
- 서비스 → 업데이트하는 리포지토리 여러개 주입 X
- 북마크 서비스/ 북마크 삽입을 위해 → 북마크 리포, 태그 리포 다 받으면 안됨면 안됨
엔티티에 최대한 비지니스로직을 담기
- 팔로우 엔티티에 팔로우 로직이 들어있으면 좋을 것 같다. (엔티티 상태를 가지는 필드가 있으면 비지니스 로직을 표현하기 수월하다. ex) FollowType.FOLLOW, FollowType.UNFOLLOW)
- @ManyToMany, @ElementCollection (FavoriteCategory is not entity)
예외 메시지
- 정말 사용자에게 보여질 메시지 인가요?
중요 엔티티 삭제
- 상태 변경으로 처리, DB 삭제하면 안됨
Reaction 엔드 포인트
POST 메서드를 사용할거면 바디를 활용해라. url에 데이터를 넣을거면 POST가 POST 인가?
얘기를 많이 해라
- 같은 기술을 사용해서 개발을 하면 적용 방식이 통일 되야한다.
- 그냥 공부 할꺼면 그래도 되는데 그냥 공부는 아니니까
- e.g.) Querydsl 적용 방식 -
Profile,Bookmark달랐음
Querydsl
- 을 쓸꺼면 동적 쿼리 생성을 적극적으로 써라
- if 문 덕지덕지 되도 됨
- DTO Projection 활용 고려하자
- for loop 로 어거지로 서비스에서 말아주는것 보다 나음
- 요 dto 를 웹 계층 까지 전달해도 됨
알림 처리 → 할 수 있음
- 알림 mongoDB 에 머리 좀 박다가 잘 안풀리면 mysql json 타입 사용을 고려
요청/응답 처리
- ArgumentResolver 필요 한지? → ?!?!?!
- JsonSerializer 필요 한지? → ObjectMapper 이런걸로 안되나?
로직
- 리액션 카운트 맵 조회시 group by
- 3항 연산자는 생각보다 더러운 녀석이다 - 복잡함
ReadME
- 용례정리 (ex) cond → condition)