- 이번 미션은 2번으로 나뉩니다.
- 첫 번째 미션은 코테이토 세션이 재시작되는 12월 21일까지입니다.
- 두 번째 미션은 1월 초중순입니다. 두 번째 미션은 첫 번쨰 미션에 대한 코드리뷰, 몇 가지 요구사항 추가 등 입니다.
- 이번 네트워킹 미션은 "좋은 코드"를 목표로 합니다. 여러 유용한 디자인 패턴을 적용하고 객체지향적인 팀원들의 코드를 보고 배우는 것이 최종 목표입니다.
- 1팀과 2팀의 미션은 같습니다.
- build.gradle 에 작성된 버전을 기준으로 합니다. Spring Boot 는 3.2.0, Java 는 17 버전을 활용합니다.
- 현재 Repository를 각자 Fork한 후 Clone한 뒤 작업환경을 만든다.
- 새로운 branch 를 만들어 해당 branch 에서 작업한다. (주의할 점: main이 아닌 브랜치에서 작업할 것)
- 코테이토 부원을 등록하고, 파트별 출력, 개인별 출력, 파트에서 개인별 출력 3가지 기능까지, 총 4개의 API를 개발한다.
- 동아리원은 이름, 들어온 기수, 나이, 파트, 실력 을 가지고 있다.
- 이름은 한글 2글자 이상, 10글자 이하여야 한다.
- 나이는 22살 이상 30살 이하여야 한다.
- 파트는 기획, 디자이너, 프론트엔드, 백엔드 가 있다.
- 실력은 해당 동아리원의 실력을 나타내는 0 이상의 정수값이다.
다음과 같은 Post 요청으로 부원을 등록한다. (간편함을 위해 데이터베이스에 등록하지 않고, ArrayList 와 같은 컬렉션에 저장한다.)
{
"name": "장우석",
"period": "8기",
"age": "26",
"part": "백엔드"
}
동아리원들의 실력 관리를 위해 실력을 계산한다.
다음과 같은 규칙을 가진다.
- 자신의 나이만큼 실력을 가진다.
- 지나간 기수마다 실력이 2씩 증가한다. 예를 들어, 4기에 들어온 사람은 5기에 실력이 2 증가한다.
- 특정 월마다 각기 다른 파트의 실력이 증가하는 것을 발견했다. 하지만, 아쉽게도 27살 이상 동아리원들은 실력이 증가되지 않는다.
1, 5, 9월: 기획 파트 동아리원의 실력 10 증가
2, 6, 10월: 디자이너 파트 동아리원의 실력 10 증가
3, 7, 11월: 프론트엔드 파트 동아리원의 실력 10 증가
4, 8, 12월: 백엔드 파트 동아리원의 실력 10 증가
- 밑의 3개의 API 요청에는 현재 기수가 파라미터로 들어간다. 현재 기수와 오늘 날짜를 기반으로 실력을 계산한다.
- EX) 10기에 들어온 25살 프론트엔드 동아리원의 실력을 계산할 경우
- 현재 기수로 11기를 입력하고 오늘 날짜가 11월 28일이라면 실력은 37이 된다.
- 파트별 동아리원들의 실력 평균이 해당 파트의 실력이다. 평균은 정수값으로 버림한다. (실제 평균이 24.9라면 24로 계산한다.)
- 다음의 기준으로 정렬하여 응답한다.
- 동아리별 실력에 대해 내림차순 정렬하여 응답한다.
- 실력이 같을 경우 인원수에 대해 오름차순으로 정렬한다.
- 인원수가 같을 경우 디자이너, 기획, 백엔드, 프론트엔드 순으로 정렬한다.
- 파트, 실력, 인원수를 출력한다.
- 만약 동아리원이 없는 파트가 있다면, 해당 파트는 응답하지 않는다.
[
{
"part": "기획",
"ability": "27",
"count": "9"
},
{
"part": "디자이너",
"ability": "24",
"count": "8"
},
{
"part": "백엔드",
"ability": "24",
"count": "5"
},
{
"part": "프론트엔드",
"ability": "24",
"count": "5"
}
]
- 다음의 기준으로 정렬하여 응답한다.
- 파트에 상관없이 실력에 대해 내림차순 정렬하여 응답한다.
- 실력이 같을 경우 나이에 대해 내림차순 정렬한다.
- 나이가 같을 경우 들어온 기수에 대해 오름차순 정렬한다.
- 기수가 같을 경우 이름의 사전순으로 정렬한다.
- 이름, 들어온 기수, 나이, 파트, 실력을 출력한다.
[
{
"name": "박윤하",
"period": "6기",
"age": "26",
"part": "백엔드",
"ability": "28"
},
{
"name": "장우석",
"period": "4기",
"age": "20",
"part": "디자이너",
"ability": "28"
},
{
"name": "신유승",
"period": "10기",
"age": "36",
"part": "백엔드",
"ability": "27"
}
]
- 개인별 출력을 하되, 한 파트의 동아리원들에 대해서만 응답한다.
[
{
"name": "박윤하",
"period": "6기",
"age": "26",
"part": "백엔드",
"ability": "28"
},
{
"name": "신유승",
"period": "10기",
"age": "36",
"part": "백엔드",
"ability": "27"
}
]
- API 설계는 직접 자유롭게 한다.
- build.gradle은 마음껏 변경할 수 있으나 JDK 버전은 변경하면 안 된다.
- Java 코드 컨벤션을 따른다.
- 주요 로직은 domain 패키지의 클래스에서만 구현한다. Service 클래스에서 주요 로직을 구현하지 않는다.
- indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.
- 예를 들어 while문 안에 if문이 있으면 들여쓰기는 2이다.
- 힌트: indent(인덴트, 들여쓰기) depth를 줄이는 좋은 방법은 함수(또는 메서드)를 분리하면 된다.
- 메서드의 길이가 15라인을 넘어가지 않도록 구현한다.
- 메서드 한 가지 일만 하도록 최대한 작게 만들어라.
- 값을 하드 코딩하지 않는다.
- 값들은 의미를 드러내기 위해 static final 키워드를 통해 의미를 드러내야 한다. 또한 수정에도 용이하다.
- 연관성이 있는 상수는 enum을 사용한다.
- 무작정 setter, getter 등의 Lombok 어노테이션을 사용하지 않는다.
- setter는 객체의 값을 쉽게 변경하게 해서 가독성을 떨어트린다.
- 객체 자신의 값을 외부에 드러내기만 하면 되는 때만 getter를 사용하고, 그 이외에는 로직을 직접 포함하는 메서드를 작성한다.
- 구현이 완료되었다면 commit 후 push 한다.
- main이 아닌 작업중인 브랜치에서 main에 merge한다.
- 자신의 main 브랜치에서 새로운 pull request 를 만들어 보낸다.
- 주의할 점: main이 아닌 곳에서 pull request하면 안됨. 1차 미션 종료 후 2차 미션 시에도 main이 아닌 브랜치에서 작업하고 main에서 pull request할 것.