[우아한 테크코스] 2주차 회고

💭 서론

2주차가 끝났다. 어렵지 않을 것 이라고 예상했지만 크나큰 오산이었다. 전체적인 설계부터 테스트, 컨벤션, OOP 등 기본적인 기능 구현이 20% 라면 나머지가 80%를 차지할 만큼 시간이 들었다. 비록 테스트를 전부 통과하지는 못했지만 이번 주차에서 내가 뭘 느끼고 뭘 배웠는지 공유하려고 한다.

📩 2주차 미션

게임 설명

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

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

추가된 요구사항

• indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.
  • 예를 들어 while문 안에 if문이 있으면 들여쓰기는 2이다.
  • 힌트: indent(인덴트, 들여쓰기) depth를 줄이는 좋은 방법은 함수(또는 메서드)를 분리하면 된다.
• 3항 연산자를 쓰지 않는다.
• 함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라.
• JUnit 5와 AssertJ를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다.
• 테스트 도구 사용법이 익숙하지 않다면 test/java/study를 참고하여 학습한 후 테스트를 구현한다.

기능목록 작성

위의 사진처럼 기본적으로 4가지 정도의 큰 기능을 작성했습니다.

해당 기능에서의 예외처리를 하는 케이스도 생각하면서 작성했습니다. 더불어 한번 작성하고 끝나는게 아니라 코드를 작성하면서도 계속 수정될 수 있어야 한다는 것을 느낄 수 있었습니다.

전체적인 흐름 설계

패키지, 클래스 분리

게임의 실제 로직들을 담당하는 클래스들을 모아놓은 service와 user의 입력, 출력을 담당하는 클래스들의 집합 view, 그리고 service와 view 사이에 게임의 흐름을 담당하는 controller 패키지 이렇게 많이 사용하게 되는 MVC 패턴을 처음 사용했습니다.

세세하게 신경쓰려고 하기보다 처음 사용해보는 패턴이니 관심사의 분리를 하려고 초점을 맞추었습니다.

🧠 느낀 점

• 요청을 보내는 객체는 해당 객체의 내부에는 신경을 쓸 필요 없다. 원하는 결과만 받아오도록 하면 된다.
• 상수와 문자는 static final로 감싸서 사용하는 것이 가독성 면에서 좋다는걸 느꼈다.
• 단위테스트 given, when, then 패턴에 대해서 알게되었다.
• AssertJ를 알게되었고 테스트 코드 작성 시 가독성이 올라가고 편리성을 느꼈다.
• Stream을 처음 사용 했는데 확실히 가독성 면에서 좋다. 하지만 좀 더 다양한 케이스에서 사용해보고 싶다.
• 클래스의 책임이 한가지 이상이 된다면 클래스가 비대해지고 리팩토링 시 복잡해지는 것을 경험했다. 단일 책임 원칙의 필요성을 느꼈다.
• 요구사항을 정말 정확히 이해했는지 다시 확인해야 겠다는 생각을 했다. 자세히 봤다고 생각했는데 오류가 나서 보니 내가 제대로 보지 못해서 틀린 것 이었다.