[우아한테크코스 백엔드 5기]프리코스 2주차 야구게임 회고

🎯미션 - 야구게임

🚀 기능 요구 사항

기본적으로 1부터 9까지 서로 다른 수로 이루어진 3자리의 수를 맞추는 게임이다.

• 같은 수가 같은 자리에 있으면 스트라이크, 다른 자리에 있으면 볼, 같은 수가 전혀 없으면 낫싱이란 힌트를 얻고, 그 힌트를 이용해서 먼저 상대방(컴퓨터)의 수를 맞추면 승리한다.
  • 예) 상대방(컴퓨터)의 수가 425일 때
    • 123을 제시한 경우 : 1스트라이크
    • 456을 제시한 경우 : 1볼 1스트라이크
    • 789를 제시한 경우 : 낫싱
• 위 숫자 야구 게임에서 상대방의 역할을 컴퓨터가 한다. 컴퓨터는 1에서 9까지 서로 다른 임의의 수 3개를 선택한다. 게임 플레이어는 컴퓨터가 생각하고 있는 서로 다른 3개의 숫자를 입력하고, 컴퓨터는 입력한
  숫자에 대한
  결과를 출력한다.
• 이 같은 과정을 반복해 컴퓨터가 선택한 3개의 숫자를 모두 맞히면 게임이 종료된다.
• 게임을 종료한 후 게임을 다시 시작하거나 완전히 종료할 수 있다.
• 사용자가 잘못된 값을 입력할 경우 IllegalArgumentException을 발생시킨 후 애플리케이션은 종료되어야 한다.

✏️입출력 요구 사항

💻입력

• 서로 다른 3자리의 수
• 게임이 끝난 경우 재시작/종료를 구분하는 1과 2 중 하나의 수

🖨출력

• 입력한 수에 대한 결과를 볼, 스트라이크 개수로 표시

1볼 1스트라이크

• 하나도 없는 경우

낫싱

• 3개의 숫자를 모두 맞힐 경우

3스트라이크
3개의 숫자를 모두 맞히셨습니다! 게임 종료

• 게임 시작 문구 출력

숫자 야구 게임을 시작합니다.

실행 결과 예시

숫자 야구 게임을 시작합니다.
숫자를 입력해주세요 : 123
1볼 1스트라이크
숫자를 입력해주세요 : 145
1볼
숫자를 입력해주세요 : 671
2볼
숫자를 입력해주세요 : 216
1스트라이크
숫자를 입력해주세요 : 713
3스트라이크
3개의 숫자를 모두 맞히셨습니다! 게임 종료
게임을 새로 시작하려면 1, 종료하려면 2를 입력하세요.
1
숫자를 입력해주세요 : 123
1볼
...

---

설계 구조

양방향 의존 관계가 없게, MVC 구조에 엇나가지 않는 의존성을 띄도록 설계했습니다.

📑구현 기능 목록

코드 깃허브

🪶후기

📚지키려 노력 했던 원칙

1. IntelliJ IDEA를 사용, java 버전 11으로 세팅하여 사용했습니다.
2. 자바 코드 컨벤션을 지키기 위해 노력했습니다.
   • checkstyle을 통해 꾸준히 확인했습니다.
   • lf를 사용했습니다.
3. 커밋 메세지 컨벤션을 지키려 노력했습니다.
4. 기능 단위로 커밋하려 노력했습니다.
   • 어디까지가 제가 생각한 하나의 기능인지 계속 생각해가며 커밋을 남겼습니다.
5. MVC모델을 공부하고, 적용시켰습니다
   • controller : 사용자의 요청을 받고, 프로그램 실행
   • domain : 기능 구현에 필요한 요소들
   • service : 비즈니스 로직
   • view : 인풋, 아웃풋을 통해 UI와 사용자 응답을 받음
6. SRP(단일 책임 원칙)을 지키려 노력했습니다.
   • 클래스 별로 기능을 나눠, 변경이 있을 때 파급 효과를 적게 하기 위해 노력했습니다.
7. 객체지향 생활체조 원칙을 지키고, 클린코드를 만들기 위해 노력했습니다.
   • indent가 1을 벗어나지 않도록 노력했습니다.
   • else·switch를 쓰지 않았습니다.
   • 모든 원시 값과 문자열을 포장하였습니다.(하드코딩 하지 않았습니다)
   • 메소드 당 기능 하나를 지킬 수 있게 메서드 분리를 했습니다.
   • 메서드·변수명을 축약없이, 이름만 보고도 어떤 기능인지 알 수 있게 적었습니다.
   • 디미터 법칙을 적용시켰습니다.
   • 하나의 클래스가 50줄이 넘지 않도록 했습니다.
   • 주석을 쓰지 않았습니다.
   • 최대한 단위 테스트를 작성할 수 있게 노력했습니다.
   • 3개 이상의 인스턴스 변수를 사용하지 않도록 노력했습니다.
   • getter/setter를 쓰지 않도록 노력했습니다.
     • 객체의 상태를 가져오기 위해 꼭 필요한 부분에서만 getter를 사용했습니다.

소감

1. MVC패턴

MVC패턴을 처음부터 공부하고, 적용시켰습니다. 첫 설계대로 기능이 모두 수행되도록 구현하고 나서, 더 좋은 설계를 하기 위해, 코드에 아무런 손도 대지 않고 이틀 내리 자료를 찾아보고 고민했습니다.

Model, Controller, View 자체도 쉽지 않았지만, Model의 domain, service, dto, dao 등에 대해 고민하니 머리가 복잡했습니다. 사실 Model 부분에서 써놓은 모든 것들은 DB와 관련 있는 것들입니다. 하지만 과제에선 DB가 존재하지 않았습니다.

그렇다면 그냥 단순 Model로 분리하고 기능을 구현해야 하나? 그러긴 싫었습니다. 나중에 할 고민, 지금하자는 생각이었습니다. Model을 이해하기 위해 domain에 대해 계속 검색했습니다. 공책에 미션의 필요한 기능, 좋은 설계 구조(양방향 금지) 등을 고민해보며 제 머릿속에서 Model을 사용했을 때, 제대로 썼는지에 대한 납득이 될 때까지 고민했습니다.

결론적으로 dto, dao를 제외한 domain, service를 사용해 리팩토링하였고, 만족스러운 리팩토링이었습니다. 물론, 분명 더 좋은 구조가 있겠지만 그건 계속 고민해볼 문제입니다.

구조가 명확해지니, 어떤 기능들이 그 안에 있어야 하고, 그 기능을 위해서라면 메소드를 어떻게 분리해야 할지가 더 확실하게 보였습니다. 덕분에 테스트 코드를 작성할 때도 굳이 겹치는 테스트를 작성하지 않을 수 있었습니다.

2. 테스트 코드

AssertJ, Junit5에 대해 공부하여 테스트를 적용시켰습니다. 아직 제대로 적용시킨 것이 많지 않아 다음 주 과제는 더 적극적으로 써볼 생각입니다.

클린 코드에서는 간단한 테스트가 가장 좋다고 했지만, 간단한 테스트'만' 작성할 수 있는 것과 일부러 간단한 테스트'로'작성하는 것엔 차이가 있다고 생각합니다.

우테코와 관련된 것들을 찾아보던 중, 유튜브에 박재성 캡틴의 TDD강의를 보게 되었습니다. 다시 곱씹어보며, TDD도 적용시킬 수 있게 노력할 계획입니다.

3. 스터디

위와 같은 고민을 이래저래 하며, 분명 다른 분들도 수많은 고민을 했을 것 같고, 직접 대화해보고 싶었습니다. 생각만 해서는 아무것도 변하지 않으니, 바로 스터디를 만들자 다짐하여 지원문서를 작성하고, 공고를 올렸습니다.

생각보다 많은 분이 지원하셔서 10명이나 되는 분들과 스터디하게 되었습니다. 사실 모두가 뭉칠 수 있는 시간도 한정적이고, 어떻게 이끌고 가야 할지 아직도 고민이 많습니다.

모두가 많은걸 얻어가는 시간이 됬으면 좋겠네요. 참가해주신 것에 대한 감사의 말씀을 드리고 싶습니다😊😊

4. 공부할 것

• TDD를 적용할 수 있도록 공부
• 객체지향 설계에 대해 더 찾아보기
• 테스트 코드를 더욱 잘 작성하도록 공부
• 더욱 좋은 코드를 짤 수 있도록 고민

5. 마무리

어쨋든 2주차도 많은 성장을 할 수 있었던 한주였습니다! 솔직히 프리코스 시작 전에는 이 정도의 코드도 작성을 깔끔하게 못 했을 것 같은데, 1주차, 2주차가 흐름에 따라 저도 모르게 발전하고 있는 것 같습니다.

특히나 함수의 분리, 테스트 코드 작성과 같은 좋은 목표를 주시니 보답이라도 하듯 통학하면서, 자기 전에도 계속 좋은 고민을 할 수 있는 것 같습니다.