java-convenience-store-precourse

---

🎯 구현 기능 목록

일반

• 법정 공휴일 정보 읽어서 요일 정보 업데이트 하기
• 요일 정보와 순번 정보를 토대로 근무표 작성하기

입출력

• 월과 시작 요일 입력
  • 검증, 재입력
• 평일 순번, 휴일 순번 입력
  • 검증, 휴일 틀려도 평일부터 재입력

---

📚 클래스 구조

MVC Pattern

store

• Application.java
• controller
  • OncallController
• domain
  • Month
• model
  • OncallTable
• util
  • ERROR_MESSAGE
  • FILE_CONSTANT
  • DAY_CONStANT
  • NUMBER_CONSTANT
  • OTHER_CONSTANT
  • OUTPUT_MESSAGE
  • REGEX_PATTERN
• view
  • OutputView.java
  • UserInputView.java
  • FileInputView
• hollydays.md
  • 법정 공휴일 정보

---

🔧 예외 처리 테스트 케이스

1. Application

Application

• [x]
• [x]

2. Domain

CustomerTest

• [x]

3. Service

ConvenienceStoreTest

• [x]

---

💻 사용 방법

1. 시작

• 비상 근무를 배정할 월과 시작 요일 입력 문구가 출력

2. 사용자 입력 - 월, 시작 요일 입력

• 입력한다.

비상 근무를 배정할 월과 시작 요일을 입력하세요> 5,월

2. 사용자 입력 - 평일, 휴일 순번 입력

• 평일 순번 입력한다.

평일 비상 근무 순번대로 사원 닉네임을 입력하세요> 준팍,도밥,고니,수아,루루,글로,솔로스타,우코,슬링키,참새,도리

• 휴일 순번 입력한다.

휴일 비상 근무 순번대로 사원 닉네임을 입력하세요> 수아,루루,글로,솔로스타,우코,슬링키,참새,도리,준팍,도밥,고니

3. 결과 출력

5월 1일 월 준팍
5월 2일 화 도밥
5월 3일 수 고니
5월 4일 목 수아
5월 5일 금(휴일) 루루
5월 6일 토 수아
5월 7일 일 글로
5월 8일 월 루루
5월 9일 화 글로
5월 10일 수 솔로스타
5월 11일 목 우코
5월 12일 금 슬링키
5월 13일 토 솔로스타
5월 14일 일 우코
5월 15일 월 참새
5월 16일 화 도리
5월 17일 수 준팍
5월 18일 목 도밥
5월 19일 금 고니
5월 20일 토 슬링키
5월 21일 일 참새
5월 22일 월 수아
5월 23일 화 루루
5월 24일 수 글로
5월 25일 목 솔로스타
5월 26일 금 우코
5월 27일 토 도리
5월 28일 일 준팍
5월 29일 월 슬링키
5월 30일 화 참새
5월 31일 수 도리

---

✅ 프로젝트 체크 사항

1. 공통 피드백

1, 2, 3주차 공통 피드백

• 요구 사항을 정확하게 준수한다.
• 기본적인 Git 명령어를 숙지한다.
• Git으로 관리할 자원을 고려한다.
• 커밋 메시지를 의미 있게 작성한다.
• 커밋 메시지에 이슈 또는 풀 리퀘스트 번호를 포함하지 않는다.
• 풀 리퀘스트를 만든 후에는 닫지 말고 추가 커밋을 한다.
• 오류를 찾을 때 출력 함수 대신 디버거를 사용한다.
• 이름을 통해 의도를 드러낸다.
• 변수, 클래스, 메서드 이름을 축약하지 않는다.
• 공백을 의미 있게 사용하고, 스페이스와 탭을 혼용하지 않는다.
• 의미 없는 주석을 달지 않는다.
• 코드 포매팅을 사용한다.
• Java에서 제공하는 API를 적극 활용한다.
• 배열 대신 컬렉션을 사용한다.
• README.md를 상세히 작성한다.
• 기능 목록을 재검토하고 업데이트한다.
• 값을 하드 코딩하지 않는다.
• 구현 순서를 상수, 멤버 변수, 생성자, 메서드 순으로 한다.
• 변수 이름에 자료형을 포함하지 않는다.
• 한 메서드가 한 가지 기능만 담당하게 한다.
• 메서드가 한 가지 기능을 하는지 확인하는 기준을 세운다.
• 테스트를 작성하는 이유를 정리한다.
• 처음부터 큰 단위의 테스트를 만들지 않는다.
• 메서드 라인에 대한 기준도 적용한다.
• 예외 상황에 대해 고민한다.
• 비즈니스 로직과 UI 로직을 분리한다.
• 연관성이 있는 상수는 static final 대신 Enum을 활용한다.
• final 키워드를 사용해 값의 변경을 막는다.
• 객체의 상태 접근을 제한한다.
• 객체 데이터를 외부에서 처리하는 것이 아니라, 객체가 자신의 데이터를 스스로 처리하도록 한다.
• 함수화를 통해 객체의 수를 줄이기 위해 노력한다.
• 테스트 코드도 리팩터링한다.
• 테스트를 위해 접근 제어자를 바꾸거나, 테스트만을 위한 메서드를 추가하지 않는다.
• private 함수를 테스트하고 싶다면 클래스 분리를 고려한다.

2. 피어 리뷰 피드백

README.me

• 입력값에 대한 상세한 조건을 추가적으로 기록하였는가?
• 사용방법을 상세하게 명시하였는가?
• 프로젝트의 전체적 구조를 명시하였는가?
• 구체적인 테스트 케이스를 명시하였는가?
• <details>, <summary> 를 통해 토글 형식을 사용하였는가?
• 이모티콘을 사용해 이쁘게 꾸몄는가?

리팩토링(주석)

• given/when/then 주석을 사용하였는가?
• 불필요한 주석없이 함수명으로 기능을 알 수 있는가?

리팩토링(분류)

• 메인 비즈니스 로직이 여러 개일 경우 service 모듈을 도입하였는가?
• View도 Input, Output 구분하였는가?
• 에러 메시지를 enum 또는 클래스로 관리하였는가?
• 테스트 코드를 클래스를 나누어 관리하였는가?
• 테스트 코드를 모듈별로 작성하였는가?

리팩토링(디테일)

• 최대한 세밀하게 함수화 하였는가?
• 안내문(print) 등을 상수로 표현하여 내부 enum으로 관리하였는가?
• 매직넘버를 모두 상수화하였는가?

3. 2024 우아콘 피드백

BE 세션

• 각 변수와 함수들의 스펙을 사전 형식으로 명시하였는가?
• Getter Setter를 지양하였는가?
• 개발 과정에서 패키지를 적절히 분할하였는가?