2주차 문제
기능 요구사항
1부터 9까지 서로 다른 수로 3자리 수를 맞추는 게임
-힌트를 주는데
같은 수가
1.같은 자리에 있으면 스트라이크
2.다른 자리에 있으면 볼
3.같은 수가 전혀 없으면 낫싱
-1. 그 힌트를 이용하여 상대방의 수를 맞추면 승리한다. (틀리면 패배)
컴퓨터가 생각한 숫자 3개를 모두 맞추면 게임이 종료
2. 게임 종료 후 게임을 다시 시작하거나 완전히 종료할 수 있다.
-1.상대방의 역할은 컴퓨터가 1~9까지의 서로 다른 임의의 수 3개를 선택하고
2.플레이어는 컴퓨터가 선택한 숫자에 대해 맞추기 위해 3개를 입력
3. 컴퓨터는 입력한 숫자에 대한 결과를 출력
-사용자가 잘못된 값을 입력할 경우 IllegalArgumentException을 발생시킨 후 애플리케이션은 종료되어야 한다.
입출력 요구 사항
입력
-서로 다른 3자리의 수
-게임이 끝난 경우 재시작/종료를 구분하는 1과 2 중 하나의 수
출력
-입력한 수에 대한 결과를 볼, 스트라이크 개수로 표시
=1볼 1스트라이크
-하나도 없는 경우
=낫싱
-3개의 숫자를 모두 맞힐 경우
= 3스트라이크
3개의 숫자를 모두 맞히셨습니다! 게임 종료
-게임 시작 문구 출력
=숫자 야구 게임을 시작합니다.
과제 진행 요구사항
Git의 커밋 단위는 앞 단계에서 docs/README.md에 정리한 기능 목록 단위로 추가한다.
-커밋 메시지 컨벤션 가이드를 참고해 커밋 메시지를 작성한다.
README.md 작성법
양식은 없고 프로젝트에 대한 설명과 링크 실행환경, 사용라이브러리, 가이드라인 작성하면된다
벨로그와 같은 마크다운 문법 사용./ 간단명료하게!
커밋 메세지 규칙
1. 제목과 본문을 한 줄 띄워 분리하기
2. 제목은 영문 기준 50자 이내로
3. 제목 첫글자를 대문자로
4. 제목 끝에 . 금지
5. 제목은 명령문으로 사용하며 과거형을 사용하지 않는다
6. 본문은 영문 기준 72자마다 줄 바꾸기
7. 본문은 어떻게보다 무엇을, 왜에 맞춰 작성하기
####-커밋 메시지 구조
<type>(<scope>): <subject> -- 헤더
<BLANK LINE>
<body> -- 본문
<BLANK LINE>
<footer> -- 바닥글은 해당 커밋의 성격을 나타내며 아래 중 하나여야 합니다
feat : 새로운 기능에 대한 커밋
fix : 버그 수정에 대한 커밋
build : 빌드 관련 파일 수정에 대한 커밋
chore : 그 외 자잘한 수정에 대한 커밋
ci : CI관련 설정 수정에 대한 커밋
docs : 문서 수정에 대한 커밋
style : 코드 스타일 혹은 포맷 등에 관한 커밋
refactor : 코드 리팩토링에 대한 커밋
test : 테스트 코드 수정에 대한 커밋참고 블로그들
https://beomseok95.tistory.com/328 ->작성 규칙과 메세지 구조
https://meetup.toast.com/posts/106 -> 작성규칙에 세세한 설명
https://gist.github.com/stephenparish/9941e89d80e2bc58a153#allowed-type ->우테코에서 참고하라한 문서
https://blog.ull.im/engineering/2019/03/10/logs-on-git.html ->깃 메세지 영어이름 쉽게 짓는 법
https://github.com/RomuloOliveira/commit-messages-guide/blob/master/README_ko-KR.md ->한국어로 깃메세지
https://github.com/koo9b9h/java-baseball
README.md
###구현 기능 목록(22.11.06)
####게임 시작 후 동작
1. 게임 시작문구 출력
2. 랜덤 숫자 3자리 설정
3. 사용자 입력값 받기
####결과를 비교 출력
1. 값 비교
2. 입력한 수에 대해 볼 스트라이크에 대한 개수로 출력
-맞힌 값이 없을 경우 = 낫싱
-다 맞힐 경우 = 3스트라이크 (게임 종료 메시지 출력)
####게임 종료 후 동작
1. 다시 시작
2. 게임 종료
깃으로 진행되는 과정에서 어떤 기준으로 소통해야 하는지 많이 생각하고 고민하는 시간이었습니다. 커밋 메시지에 대해서 이해를 위해 어떻게 해야하나 많이 고민해보는 시간이었고 코드를 작성할 때 전체적인 구성을 소통의 측면에서도 고려해서 작성하고 순서화 시켜야겠다라고 생각하게 되었습니다.
(구체적으로 얘기하자면 너무 생각 없이 구조를 짜고 막연하게 쉽겠다고 생각하고 코딩을 시작했는데 막상 커밋할 때가 되니까 '이렇게 하면 다른 사람이 이해 할 수 있을까?' 라는 의문이 들었고 처음에 생각 없이 진행했던 구조가 끝에 가니까 무분별하고 더러운 커밋메시지들과 함께 혼란이 오자 그 고민이 코딩을 하는데까지 지속적으로 영향을 미쳤습니다.)
+ 피드백 내용
README.md를 상세히 작성한다
해당 프로젝트가 어떠한 프로젝트이며, 어떤 기능을 담고 있는지 기술 프로젝트를 소개
기능 목록을 재검토
기능 목록을 클래스 설계와 구현, 함수(메서드) 설계와 구현과 같이 너무 상세하게 작성하지 않는다. 클래스 이름, 함수(메서드) 시그니처와 반환값은 언제든지 변경될 수 있기 때문이다. 너무 세세한 부분까지 정리하기보다 구현해야 할 기능 목록을 정리하는 데 집중한다. 정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리
기능 목록을 업데이트한다
완벽한 정리를 해야하는 부담보다는 살아있는 문서를 만들기 위해 노력
값을 하드 코딩하지 않는다
내가 신경을 하나도 쓰지도 않고 간과한 부분! 상수(static final)를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러내라
한 함수가 한 가지 기능만 담당하게 한다
함수 길이가 길어진다면 한 함수에서 여러 일을 하려고 하는 경우일 가능성이 높다.
함수의 길이를 15라인을 넘어가지 않도록 구현하며 함수를 분리하는 의식적인 연습
예시 코드 (내가 딱 이런식으로함..ㅋㅋ;; 생각하고 해야겠다..)
private List<Integer> userInput() {
System.out.println("숫자를 입력해 주세요: ");
String userInput = Console.readLine().trim();
List<Integer> user = new ArrayList<>();
for (char c : userInput.toCharArray()) {
user.add(Character.getNumericValue(c));
}
if (user.size() != 3) {
throw new IllegalArgumentException("[ERROR] 숫자가 잘못된 형식입니다.");
}
return user;
}
1개의 댓글
- 간과한 점: boolean에 대한 변수명 메소드명을 올바르게 주지 못함. /리팩토링 제대로 안함