[면담] 6~8주차 팀&개인 면담 일지

면담 주제

• 면담 주제

활동 내용

• Bean
• Controller, Service, Repository를 config로 빈 등록을 해주면 생성자가 수정될때 config쪽도 중복으로 작업해줘야 한다.
• 만약 서비스쪽 생성자가 수정되면 config 서비스 빈 생성자도 수정해야하므로!
• config를 통해 빈 등록을 하는 방식을 사용할 경우 서비스가 커지면 따로 관리 해줘야한다는 점이 있지만, 이런 방법이 나중에 유행 할 수도..?

• DTO
• DTO는 실무에서 인터페이스보다는 클래스로 많이 쓴다.
• 각 요청에 대한 모델을 만들어서 사용한다 ex) SaveUserRequest.class, UpdateUserRequest.class
• DTO가 Repository 계층까지 들어와도 괜찮다!
• Controller는 요청에 대한 값만 전달하는 느낌?이 좋다. DTO <-> Entity 변환은 서비스에서 해주는걸 선호한다.
• 오히려 서비스 메소드에서 DTO를 받아서 로직을 구현하는게 더 좋다. 반환할때도 마찬가지.
• 서비스 메소드에서 여러 파라미터를 막 받는거보다는 DTO로 관리하면 DTO 필드가 수정될때 더 관리하고 쉽다.

• REST API
• rest api에서 리소스는 복수형으로 가져가자. ex) /vouchers , users
• 검색 기능의 경우 검색에 대한 분기는 서비스에서 가져가자
• 컨트롤러에서 분기를 갖는거보다 서비스쪽 메소드에서 분기를 가져가서 처리하는 형식이 더 나음 (쿼리 파라미터에서의 null값에 대한 처리)
• Querydsl을 사용하면 where절에서 이러한 분기 처리를 해줄 수 있다. (Repository에서 처리해줄 수 있다)
• API에 버전을 표시하면서 얻는 이점은 레거시 API들을 남겨놓으면서 새로운 API로 리팩토링 하는 방식으로 활용할 수 있기 때문이다.

• DB
• 데이터 조회 시 UUID는 정렬이 제대로 안되지만, autoincrement를 사용하면 id를 통해 자동 정렬이 되서 데이터가 조회된다.

• TEST
• 컨트롤러 테스트는 우선 순위가 낮다. 차라리 통합테스트나 서비스쪽을 더 세세히 짜주는게 좋다
• 컨트롤러 테스트는 실제 api를 호출하면서 검증하는 WebTestClient 를 사용하기도 한다.
• 통합 테스트는 시나리오를 생각하면서 어떤 부분에 오류가 날 것이라고 예상하면서 짜기도 한다.

• CQRS 패턴
• 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하자
• 메소드를 호출했을때 내부에서 변경(사이드 이펙트)이 일어나는 메서드인지, 아니면 내부에서 변경이 전혀 일어나지 않는 메서드인지 명확히 분리하자
• 그렇게 되면 데이터 변경 관련 이슈가 발생했을 때, 변경이 일어나는 메서드만 찾아보면 된다.

면담 주제

• 면담 주제

활동 내용