## ✅ FeedBack 체크 리스트 -> 구현 후 리펙토링

`## 1️⃣ 가독성

• [x] 작명의 의미 전달력
• [ ] 코드 포맷팅 (IntelliJ IDEA: ⌥⌘L)
• [x] ReadMe를 살아있는 문서로 사용한다.
• [x] 구현 순서를 깔끔하게 하였는가

2️⃣ 코딩 습관

• [x] 필요하다면 싱글톤을 적용하기 -> Config의 관리 밖의 것들을 싱글톤으로 처리
• [ ] 안 쓰는 Importation 삭제
• [x] 변수명에 자료형을 쓰지 않는다
• [x] 변수명에 불용어를 넣지 않는다
• [ ] if 안에 부정문을 줄여보자
• [x] 와일드 카드를 지양한다 -> 필요없는 경우 사용 x
• [x] commit의 가독성을 놓치지 말자

3️⃣ 설계 중점 사항

• [x] Config를 써보자
• [x] 참조로 추적되는 데이터형 getter 지양 → DTO 사용 (record 타입), 방어적 복사 대안, 수정 불가 객체 return. service 바깥으로 나가는 부분에 대해서 신경 썻다.
• [x] DTO는 의미있게 사용한다(+ 필요하다면 Dto 내부에서 생성 처리) -> View에서 도메인에 의존하지 않기 위해사용.
• [x] 구현 방식에 집중해서 과제 자체에 대한 예외들을 빼먹지 말 것
• [x] 상수가 연관성이 있다면 enum 사용
• [ ] 메서드는 한 가지 일만 처리한다 (10 줄 이하 이건 메인 코드도 동일) -> 최대한 노력
• [ ] 마지막 프로그래밍 요구 사항 지켰는지 check (예외를 잘보자)
• [ ] 많이 의존 당한다면 interface의 근거가 충분하다 (+ 인터페이스화 할 근거가 필요 가령, 활용성이 높다)
• [x] 객체는 객체에서의 역할에 충실하고 나머지는 service에 존재한다
• [x] validation은 객체 자체의 정체성, 유효성 검사, 파싱, 그리고 정제를 분리해서 생각한다.
• [x] view의 역할을 침범하지 말자 ex) 포메팅
• [x] getter를 되도록 이면 지양한다 캡슐화에 조금 더 신경 써야 할 것 같다. -> 다만 시간상 Dto로 일일히 처리할 수 없었다. 최대한 지양했음.
• [x] 필드를 줄이기 위해 노력하자

4️⃣ Test (시간이 남았다면 사용할 checkList)

• [x] 테스트 자체에서 메서드를 만들거나 여러 기능을 사용해 중복 테스트 줄이기
• [x] 2주차 feedback 테스트 메서드 참고 자료 활용
• [x] UI(System.out, System.in, Scanner) 로직은 제외한다 (굳이 사용할 필요가 없었다)
• [ ] Interface 적극 사용 → 테스트 대역이라면 따로 분리하자
• [x] 테스트를 하기 용이하게 코드를 작성한다
• [ ] 공백 테스트는 \n \t 같은 것도 하자
• [x] 예외 테스트를 집중적으로 하자
• [x] 테스트 코드도 가독성을 신경써야 한다

5️⃣ 기타

• [x] stackOverflow를 고려한다 -> ErrorCatcher에 최대 재시도 횟수를 설정한다.
• [x] enum Map을 고려한다 -> 사용할 필요가 없었다
• [x] Java 8의 인터페이스 default 기능을 고려한다 (like 상속) ->미사용
• [x] 필요하다면 상속을 사용해보자 -> 미사용
• [x] 대부분 주어진 미리 정해진 값들은 상수화할 필요가 있다.
• [ ] 숫자 구분자 1_000_000 를 사용하면 가독성이 좋다
• [x] 줄 바꿈이 필요하다면 System.lineSeparator() 을 써보자 -> sout을 그냥 쓰는 것과 큰 차이를 느끼지 못함.
• [x] 예외 처리를 흐름 제어용으로 사용하지 말 것`