리팩터링 목록1. 매개변수가 4개 이상인 항목 Builder 패턴 적용2. User에 관한 password 체크는 인증을 제외하고는 불필요해보이므로 password 부분의 테스트 코드를 지웠습니당.3. test code given 들이 전역으로 선언되어 있어서 위로 왔다갔다 하기 힘들기도 하면서 스코프가 전역이라 다른곳에 변경이 일어나면 다다다닥 fail 날 우려가 있는데 이것은 지역으로 다 빼려고 합니다. 또한 똑같은 생성자 코드도 리팩터링하여 메소드화하여 간편하게 처리하도록 하려 함.4. 테스트 코드 추가살짝 말하기 애매한 생각들변화 구간
리팩터링 목록
1. 매개변수가 4개 이상인 항목 Builder 패턴 적용
2. User에 관한 password 체크는 인증을 제외하고는 불필요해보이므로 password 부분의 테스트 코드를 지웠습니당.
3. test code given 들이 전역으로 선언되어 있어서 위로 왔다갔다 하기 힘들기도 하면서 스코프가 전역이라 다른곳에 변경이 일어나면 다다다닥 fail 날 우려가 있는데 이것은 지역으로 다 빼려고 합니다. 또한 똑같은 생성자 코드도 리팩터링하여 메소드화하여 간편하게 처리하도록 하려 함.
4. 테스트 코드 추가
- repositoryTest
- validationTest
- controller Test
살짝 말하기 애매한 생각들
- 현재 JPA를 사용함으로써 객체로 매핑(
연관된 객체를 생성해서 같이 save 해 주는 것)하게 되는 상황들이 되게 많은 것 같아요. 그래서 해당 도메인 마다 겹쳐서 사용하기 애매한 부분이 대부분인 것 같습니다. 그래서 이점을 고려해서 연관된 도메인 끼리 Grouping 해서 repository를 참조하게 하는 것도 방법이 될 수 있을 것 같아요
- 짜잔 방법 1
- Crong :
- 짜잔 방법2
- 몇몇 테이블 및 엔티티 연관관계를 DB와 같이 key 전략으로 가져가면 가장 위에 그림 처럼 이상적인 엔티티 스코프를 가질 수 있을 것 같아요.
현재 converter가 쓰이는 곳과 안쓰이는 곳이 들쭉날쭉 함이 보이고 있어 팀원끼리 협의가 필요해 보입니다. 우선 그 부분은 협의 된 후에 리팩터링 하겠습니당 그럼 안녕히계세요 여러분
과반수 동의로 컨버터 사용 ㄲ
변화 구간
팀 생성 api에서 파생된 메소드 , 테스트코드 전면 리팩터링
- 매개변수가 4개 이상인 곳은 builder 패턴 적용
➕ 팀 생성후 반환할 때 password는 필요없어 보였음.
- Team Entity validation Test
- Team Repository Test
- Team Entity 코드에 null 옵션이 되어있지 않아 추가함.(실제로 DB DDL애눈 null 이 적용되어 있음)
V1_0__Init_Setup.sql파일 일부
