리팩토링

1차 프로젝트 리팩토링

• 예정일 : 2022/8/2(화)

리팩토링 목록

• 리팩토링 - 내일(8/2) 피처 개발 완료하고 밤중으로 생각해오기
• Giver, Service
• TeamService의 findById, TeamGiverService findById 중복
• TeamMemberService TeamMemberGiverService의 exists 중복
• 네이밍 (DTO, Update**, **Update, 체크 로직, entity에 로직넣는 것)
• 테스트 네이밍 testXXXX, XXXXTest , XXXXX
• 테스트 코드 private
• 클래스 private 함수는 맨 밑으로 내리는가?
• 혜빈 : 공통 함수는 맨 밑으로 내리고 ~ 하나의 메서드에서만 사용하는건 그 메서드 바로 밑 !
• 클린 코드에 나왔었다고.. 사용되는 메서드의 바로 밑에 사용하는 것이 가독성이 좋다. (추천)
• 진형 : 혜빈님 말씀 처럼 여러 함수에서 사용되는 함수는 맨밑으로 내리고 하나의 메서드에서만 사용되면 바로 밑에 두는것도 좋은 방법인 것 같습니다.
• 곽씌 : 부속품 같은 메서드는 사용 메서드 밑에, 공용 함수는 밑으로
• 컨벤션도 확인해주세요 ~

Giver 의존성 문제

• Giver, Service
• TeamService의 findById, TeamGiverService findById 중복
• TeamMemberService TeamMemberGiverService의 exists 중복
형욱
• Facade 해야겠따.
진형
• Facade를 해도되고 Giver를 해도된다.

DTO 네이밍

• 생성에 쓰는 경우 Create, Update, 등의 키워드를 넣을 건지
• 엘리하이해 : 무슨 말인지 잘 모르겠어용..

• @Schema (Swagger) 어노테이션은 클라이언트에게 나가는 경우에만 명세
• 혜빈
• 동운

• inner class인 경우에 response 이름을 제외해도 되지 않은지?



• 동운
• Response 제외 찬성
• 혜빈
• 중복이니 제외 해도 무방
• 진형
• Response 제외 찬성
• 형욱
• Response 제외 찬성
• 병연
• 찬성

• dto 변수명 어떻게 할것인지 ??

패키지 관련

• Team 도메인 관련은 모두 Team으로 묶어야 되지 않을런지?



• 혜빈 : 동운님이 복수 괜찮으시면 저는 좋습니당

Test 코드 관련 ⇒ test 안 쓰기로

• 테스트 코드 변수 - private 명시 할건지?



• 곽씌
• 써야 되는 이유가 없다면, 굳이 필요 없다고 생각함
• 진형님
• private 필요없슴다, 테스트코드끼리 서로 사용하는 구조가 아니기 때문에 존재 이유가 없음
• 형욱
• 저도 필요 없을 것 같습니다.

• 테스트 네이밍 testXXXX, XXXXTest , XXXXX
• 혜빈
• 저는 test ~ 했는디 다 test 아니였나??? 나 따라 쓴건뎅
• 동운
• 저도 test prefix 없애는 것에 찬성 합니다.
• 진형
• testXXXX 같이, 굳이 test prefix를 붙일 필요는 없을 것 같다.
• @Test 어노테이션도있어서 굳이?..
• 형욱
• 저도 다른분들 구조 따라간거였는데 굳이 필요 없다구 생각해요 ㅎㅎ

• 예외 케이스에 대한 @Nested 사용 건
 
 

코드 컨벤션

• 컨버터가 듬성듬성 쓰이는 것 같음. [팀원의 협의가 필요해 보임] - 엘리하이해

• Service 클래스 메서드 의존성 순서



• 혜빈 : repo → service → giver → converter

리팩토링 대상 문서화

2차 프로젝트 리팩토링

• 참가자 : 형욱, 진형, 동운

Flat한 DTO 관리

• Prefix는 행위: Create, Update, Delete, Query(QueryDSL용)
일반 Select는 Prefix 없음 (ex: UserResponse) 그 외는 상황에 맞는 다양한 동사(ex: SignUp, SignIn …)

• 기존에 nested로 관리되었던 DTO 전체를 Flat하게 관리



• 클래스 내부에서 DTO 리스트를 보나, 패키지에서 리스트를 보나 잘 찾아지고, 오히려 하나의 클래스에 집중할 수 있으므로 혼란이 적다. (가독성 향상)
• 도메인마다 DTO 수 자체가 그렇게 많지 않았음 → 관리가 어렵지 않을것이라 예상됨

논의해야 될 사항 (의문 사항)

• 조회 시, 전체적인 UserResponse를 사용하고 해당 화면에 맡게 컨트롤러 DTO용으로, View[화면명]Response 로 변환해서 사용하는 방법은?
ex) UserResponse → ViewProfileResponse

• QueryDsl도 특정 view를 위한 조회를 종종 사용하는데 여기에도 XXViewResponse 써야되는거 아닌가?
→ 우리의 규칙을 정해서 QueryDsl은 DB Query를 활용하는 특성이 강하므로 Query라는 prefix를 붙이는 것으로 우리끼리 규약을 정하는게 좋을 것 같다.