[우아한테크코스 5기] 프리코스 2주차 숫자 야구 후기

프리코스 2주차 미션 링크

https://github.com/woowacourse-precourse/java-baseball

 

제가 제출한 코드 링크

https://github.com/70825/java-baseball/tree/70825

 

 

이번 주차에는 매년마다 진행되는 숫자 야구 게임을 진행하였습니다.

숫자 야구 미션부터는 본격적으로 클래스 설계부터 해야하기 때문에 간단한 구현 치고는 시간이 오래 걸렸네요.

이번 주는 1주차에 워낙 많은 내용을 공부해서 그런 것도 있고, 너무 바빴어서 새롭게 공부한 내용이 많이 없었습니다.

 

이번 미션 목표

• 객체 지향 생활 체조 원칙 최대한 지키기
• 자바 API 최대한 사용하기
• 클래스, 메소드마다 고유한 역할 부여하기

 

---

 

1. 객체 지향 생활 체조 원칙

---

객체 지향 생활 체조 원칙은 9가지의 원칙이 담겨있습니다.

 

제가 지켰던 내용은 볼드체로 표현했습니다.

 

1. 한 메소드에 오직 한 단계의 들여쓰기만 한다.
   → for문 안에 if문만 써도 두 단계의 들여쓰기라 지키기 매우 어려운 것 같습니다.
   
   
2. else 예약어를 쓰지 않는다.
   → if문 혹은 else if문만 쓰도록 했습니다.
   
   
3. 모든 원시 값과 문자열을 포장한다.
   → 1주차에 숫자를 상수로 표현할까 말까 고민을 하다가 안했는데(특히 369게임에 3, 6, 9 상수 표현..), 이번 미션에는 적용했습니다.
   
   
4. 한 줄에 점을 하나만 찍는다.
   → if문을 비교할 때, 여러 개의 boolean을 조건으로 사용하면 줄바꿈을 적용해야 하는 것 같습니다.
   
   
5. 줄여 쓰지 않는다.
   → 모든 메소드와 변수를 줄여 쓰지 않고, 최대한 이해할 수 있도록 만들었습니다.
   
   
6. 모든 엔티티를 작게 유지한다.
   → 하나의 클래스에는 50줄을 넘기지 않는 것을 권장, 하나의 패키지에는 10개의 파일을 담지 않기를 권장한다고 합니다. 이거는 앞으로 미션하면서도 못지킬 것 같은 내용이네요.
   
   
7. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
   →  로컬 변수는 3개 이상이 되는 메소드가 있는데 인스턴스 변수라 다행히 지킬 수 있었습니다.
   
   
8. 일급 컬렉션을 쓴다.
   → 숫자 야구 게임은 모든 객체가 하나씩 존재하기 때문에 일급 컬렉션을 쓸 이유를 못 찾아 적용하지 않았습니다.
   
   
9. getter/setter/프로퍼티를 쓰지 않는다.
   → getter, setter를 사용해야해서 추가하느라 실패.. 최대한 쓰지 않으려고 했는데, getter/setter 말고는 어떻게 해야할지 모르겠더라구요.

 

 

만약 다음 미션이 자동차 경주 게임이라면 4, 8, 9를 적용할 수 있도록 도전해봐야겠습니다.

---

 

 

 

2. 클래스 구조

---

저는 10개의 클래스를 만들었습니다.

1. 게임 진행 클래스

Application (게임이 전체적으로 돌아갈 수 있도록 하는 클래스)

2. 게임 진행과 관련된 클래스

BaseballGame (Computer와 User를 사용하여 게임의 세부적인 진행을 맡은 클래스)
Computer (랜덤한 정답 값을 정하고, 볼/스트라이크를 계산하는 등 사용자가 건들지 않아도 되는 기능이 있는 클래스)
User (유저가 입력하는 값들에 대한 처리를 맡은 클래스)

3. 게임 결과를 저장하고, 출력하는 클래스 (domain 폴더로 관리)

BaseballResult (볼/스트라이크 수를 저장하여 볼/스트라이크/낫싱을 출력할 수 있도록 하는 클래스)

4. 원시 값과 문자열 포장 (resource 폴더로 관리)

AskRestartValue (게임 재시작을 할 때, 사용자가 입력하는 올바른 값을 모아둔 클래스)
GameMessage (게임을 진행하는 도중에 출력해야하는 문자열을 모아둔 클래스)
GameValue (게임을 진행하는 도중에 필요한 숫자값을 모아둔 클래스)

5. 사용자의 입력값 검증 (validation 폴더로 관리)

AskValidation (게임 재시작을 할 때, 올바른 값이 들어왔는지 검증하는 클래스)
GameValidation (숫자 야구 예상 답을 입력할 때, 올바른 값을 입력했는지 검증하는 클래스)

최대한 큰 역할 별로 클래스를 나누었는데, 이렇게 나누는 것이 적당한 것 같았습니다.

---

 

 

 

3. public class / public final class

---

OSS 활동을 하면서 유틸리티 클래스가 대부분 public final class로 되어 있었습니다.

왜 이것만 final을 적용하는지 검색을 해보니 유틸리티 클래스는 인스턴스화를 할 필요가 없고, 데이터를 처리하는 것이 목적뿐인 클래스이기 때문에 final을 붙일 필요가 있다고 나와있었습니다.

 

여기 미션에서는 Validation 클래스들이 유틸리티 클래스와 비슷한 역할을 하기 때문에 public final class를 적용했습니다.

---

 

 

 

4. Java API 사용하기

---

이번 코드에서는 Java API를 사용할만한 곳이 그렇게 많이는 없던 것 같습니다.

 

새롭게 적용했던 내용은 1주차 피드백에 있었던 String.join()을 사용하여 `1볼 1스트라이크` 처럼 중간에 공백이 들어가야하는 볼과 스트라이크와 섞인 코드를 추가했습니다.

 

String.join(" ", getBall(), getStrike());

 

이번엔 제가 못찾은 것일지는 몰라도 filter, reduce, map, collect를 사용할만한 부분은 없어서 적용하지 못했네요.

---

 

 

 

5. git rebase 사용

---

git rebase를 쓸 일이 없어서 언제 썼던지 기억조차 안나는데, 이번 미션 제출 직전에 처음 커밋 메시지에 docs: 를 안붙인 것을 이제서야 확인해서 이걸 수정하느라 rebase를 사용하였습니다.

 

rebase 사용 순서는 아래와 같습니다.

 

1. 되돌리고 싶은 커밋을 확인할 수 있도록 커밋 목록을 확인한다.

방법 1
git rebase -i HEAD~(확인할 최근 커밋 수)
ex) git rebase -i HEAD~10

방법 2
git rebase -i

 

2. 수정할 커밋을 pick 대신 edit으로 변경한다. 이후 nano 기준 Ctrl + O, Ctrl + X를 하면 된다.

pick 커밋_1
pick 커밋_2
edit 수정할_커밋
pick 커밋_3
pick 커밋_4

 

3. 메시지를 수정한다.

이때 취소를 하고 싶으면 git rebase --abort를 실행한다.

방법 1.
git commit --amend -m "새로운 커밋 메시지 내용"

방법 2.
git commit --amend
이후 코드 수정해서 nano 기준 Ctrl + O, Ctrl + X

 

4. 수정한 내용을 반영한다.

git rebase --continue
git push -f

 

이러면 수정한 커밋부터 가장 최근 커밋까지 커밋 수정 시간이 전부 현재 시각으로 바뀌게 된다는 단점을 가지고 있습니다.

---

 

 

6. 아쉬웠던 점

---

1) TDD 미적용

분명 처음엔 TDD를 적용하자고 생각했는데, 어느샌가 테스트 코드 확인도 없이 계속 코드만 작성해서 TDD를 적용하지 못하게 되어서 다음 미션부터 적용할 예정입니다.

한 달 전에 TDD 연습을 했었는데, 많이 어색했던 것으로 기억하네요

---

2) 정규표현식 미적용

사용자의 입력값이 올바르게 들어왔는지 확인할 때, 정규표현식을 사용할 수 있다는 것을 지금 글을 작성하면서 알아차렸네요.

---

3) 일급 컬렉션 미사용

이번 미션에서는 한 순간에 객체가 1개씩만 존재하기 때문에 일급 컬렉션을 적용할 이유를 찾지 못했습니다.

이번 미션에서 적용은 못했지만, 다음 미션에서 사용할 것 같아요.

---

4) 자바 8에 나온 새로운 기능을 거의 사용하지 않음

이번 미션에서는 적용할 수도 있겠지만, 메소드가 전부 들여쓰기 깊이가 2 이하로 나와서 굳이 억지로 사용할 이유가 있나 싶어 온보딩 미션과는 다르게 사용을 거의 하지 않았습니다.

하지만 다음 미션에서는 들여쓰기 깊이를 최대한 1로 만들어 볼 예정이라 많이 사용할 수 있을 것 같아요

---

5) 코드가 깨끗하지 않음

이 부분은 변수명과 메소드 이름이 길어서 그런 것인지 몰라도 전반적으로 코드가 깨끗하다는 느낌을 받지 못했습니다.

그래서 다른 블로그에 정리된 클린 코드를 보고 적용해보려고 합니다.

학교 산학 프로젝트 지원비로 클린 코드 책을 주문 했는데 언제 올지는 모르겠네요.

---

 

 

앞으로 2주동안이나 미션이 남아있으니 지금까지 했던 것을 보아하면 아주 많이 배울 것 같습니다.

이번 주엔 너무 바빠서 프리코스 공부를 많이 못했는데, 다음 미션에서는 더 좋은 코드를 들고와서 설명할 수 있으면 좋겠네요.