[우테코 프리코스] 2, 3주차 통합 회고

회고를 시작하기 전에 2주차 미션과 3주차 미션에 대한 간단한 설명과 해당 미션에 대한 목표에 대해서 약간 설명하고 넘어가겠습니다.

 

2주차 미션 - 숫자 야구 게임

간단한 설명

기본적으로 1부터 9까지 서로 다른 수로 이루어진 3자리의 수를 맞추는 게임으로, 같은 수가 같은 자리에 있으면 스트라이크, 다른 자리에 있으면 볼, 같은 수가 전혀 없으면 낫싱이란 힌트를 얻고, 그 힌트를 이용해서 먼저 상대방(컴퓨터)의 수를 맞추면 승리한다.
예) 상대방(컴퓨터)의 수가 425일 때

• 123을 제시한 경우 : 1스트라이크
• 456을 제시한 경우 : 1볼 1스트라이크
• 789를 제시한 경우 : 낫싱

구현 목표

• 함수 분리 연습
• 각 함수별로 테스트를 작성 연습

3주차 미션 - 로또 게임

간단한 설명

로또 구입 금액을 입력하면 구입 금액에 해당하는 만큼 로또를 발행하고(로또 1장의 가격은 1,000원), 당첨 번호와 보너스 번호를 받아서 사용자가 구매한 로또 번호와 당첨 번호를 비교하여 당첨 내역 및 수익률을 출력하고 로또 게임을 종료하는 게임입니다.
비교하는 기준은 아래를 참고하면 됩니다.

- 로또 번호의 숫자 범위는 1~45까지이다.
- 1개의 로또를 발행할 때 중복되지 않는 6개의 숫자를 뽑는다.
- 당첨 번호 추첨 시 중복되지 않는 숫자 6개와 보너스 번호 1개를 뽑는다.
- 당첨은 1등부터 5등까지 있다. 당첨 기준과 금액은 아래와 같다.
    - 1등: 6개 번호 일치 / 2,000,000,000원
    - 2등: 5개 번호 + 보너스 번호 일치 / 30,000,000원
    - 3등: 5개 번호 일치 / 1,500,000원
    - 4등: 4개 번호 일치 / 50,000원
    - 5등: 3개 번호 일치 / 5,000원

구현 목표

• 클래스(객체)를 분리하는 연습
• 도메인 로직에 대한 단위 테스트를 작성하는 연습

2, 3주차 통합 회고

클래스 분리 고민

2, 3주차 미션을 진행하면서 가장 많이 고민했던 점은 미션의 요구사항을 분석하여 역할 및 클래스를 어떻게 분리할지입니다.

객체지향을 공부해오면서 알게 된 점 중에 하나가 역할을 먼저 분리하고 역할을 수행할 수 있는 실제 구현체는 언제든지 바꿀 수 있는 상태로 해두면 조금 더 확장성 있는 프로그램을 짤 수 있다는 것이었습니다.

즉, 역할을 먼저 찾아야 한다는 것입니다.

 

그래서 2주차 미션인 숫자 야구 게임에서 게임을 할 때 맞춰야할 숫자를 출제하는 'ProblemMaker', 출제한 문제를 맞추는 'Gamer'라는 역할을 나누어서 인터페이스를 만들었습니다.

그리고 실제 'Gamer' 역할에는 'User'라는 구현체가 실제로 동작을 맡고, 'ProblemMaker'라는 역할에는 'Computer'라는 구현체가 실제 동작을 맡았습니다. 이렇게 함으로써 나중에 'Gamer',나 'ProblemMaker'라는 역할에는 다른 구현체가 와도 동작이 될 수 있도록 즉, 확장성이 있는 코드가 되도록 하였습니다.

3주차 미션은 로또 게임도 마찬가지로 역할을 나누었는데 로또를 구매하는 '구매자'와 로또를 판매하고 로또 당첨 번호를 추첨하는 '판매자'라는 역할로 나누어서 진행하였습니다.

실제 구현체는 각각 'User', "LottoMachine'이 담당하였고 위에서 말했다시피 이 구현체는 언제든지 바꿀 수 있도록 하였습니다.

 

 

TDD

먼저 TDD의 개념이 헷갈리시다면 아래 링크의 제가 정리한 글을 보고 오시면 좋을 것 같습니다.

https://haneulss.tistory.com/41

[Java] TDD란?

 

이전에도 테스트 코드를 작성해보긴 했었지만 기능을 먼저 만들고 제가 만든 기능을 테스트하는 용도로 테스트 코드를 작성했었습니다.

그래서 이번에는 TDD 방식을 한 번 적용해보고 싶어서 TDD로 적용해보았고, 이를 적용해보기 전에는 솔직히 '기능을 먼저 만들고 테스트 코드를 작성하는 거랑 비슷한거 아닌가?'라는 생각을 했었는데 실제로 TDD에 대해서 알아보고 적용해보니 몇 가지 장점을 알 수 있었습니다.

 

첫 번째로는 많은 생각을 하고 코드를 짜게 되기 때문에 조금 더 좋은 퀄리티의 코드를 짤 수 있게 됩니다.(물론 이 부분은 저의 착각일수도 있습니다.)

기능을 먼저 짜게 되면 일단 코드를 작성하려고 손이 먼저 나가게 되는데 테스트 코드를 먼저 작성하게 되면 많은 생각을 하게 됩니다. 그래서 바둑을 둘 때 몇 수 앞을 보고 바둑을 두듯이 코드를 짤 때도 뒤에 다른 부분들도 고려하게 되어서 처음에 코드를 짤 때 조금 더 완성도 있는 코드를 작성할 수 있게 되는 것 같습니다.

 

두 번째로는 다양한 예외 상황을 먼저 고려하게 된다는 것입니다.
원래는 기능을 작성하고 나중에 어떤 예외 상황이 발생할지 고려했었는데, 테스트 코드를 먼저 작성하다보니 다양한 예외 상황을 먼저 고려하게 되고 이에 대한 테스트 코드를 작성하게 되어서 실제 기능 코드에 크게 영향이 가지 않게 되었습니다.
이게 무슨 말이나면 TDD를 적용하기 전에는 예외 상황을 나중에 고려했어서 예외 상황에 대한 코드를 작성하면서 부가적으로 실제 기능에 대한 코드에 손을 대야 할 경우가 생기는데, 예외 상황에 대한 테스트 코드를 먼저 고려하다 보니까 실제 기능에 대한 코드에 손을 댈 이유가 사라지게 되고 갑자기 이상한 에러가 발생할 경우의 수가 약간 준다는 느낌을 받았습니다.

 

물론 TDD를 적용하면서 장점만 있다고 느끼지는 않았습니다.
이를 처음 적용해보는 것이다보니 원래보다 시간이 더 많이 걸리고, 잘 모르다보니까 내가 하고 있는게 맞나?라는 의문이 들기도 하지만 이 부분들은 많이 연습하다보면 개선될 부분이라는 생각이 들어서 크게 단점이라고 생각이 들진 않습니다.
그래서 나중에 우테코 프리코스가 아니더라도 다른 프로젝트를 할 때 TDD를 적용해보면 좋겠다는 생각이 들었습니다.

 

etc...

우테코에서는 다른 교육기관들과 다르게 미션을 주면서 그냥 기능을 구현하는 것 뿐만 아니라 다양한 제약 조건을 주는데 이 부분을 해결해나가는 것이 재밌었습니다.

예를 들면 '메서드의 길이를 15줄 이하로 해라!'라는 제약 조건이 있었는데, 이를 생각하면서 코드를 작성하니까 최대한 메서드를 잘게 잘게 분리하게 되고 다른 사람들이 내 코드를 읽었을 때 호출된 메서드의 실제 코드를 보지 않아도 어떤 기능을 담당하는 메서드구나라는 것을 명확히 알 수 있게 되는 것 같았습니다. (이 부분을 우테코에서 습득하길 원했던 것일지는 저도 잘 모르겠네요..)

 

또한 해당 주차 미션이 완료되고 배우는 마음으로 다른 사람들의 코드를 조금 읽어봤습니다.

코드를 보면서 '역시 잘하는 사람들이 많구나'라는 생각을 했고, 제가 코드를 읽고 감탄한 부분들은 나중에 참고하면 좋겠다는 생각이 들어서 여러 번 보기도 하였습니다. 
(누군가에게 제 코드도 도움이 되었으면 좋겠네요.)

 

그리고 지금까지는 우테코 커뮤니티에서 다른 사람들의 코드를 보기만 했지 따로 피어 리뷰에 참여하지는 않았습니다.

리뷰를 달고 싶었지만 키보드를 타이핑하다가도 멈칫하면서 '내 실력으로 해도되나?'라는 생각이 들어서 멈췄었는데, 지금부터는 이런 생각을 갖지 않고 일단 달고, 이상한 것 같으면 다른 사람들이 제가 리뷰한 부분을 반박해줄거라고 믿겠습니다!