![[우테코] 3주차 프리코스 후기](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2Fco3XdF%2FbtrRDUf0Eix%2FwpxuIyMQqTAGPnzd5E7eG1%2Fimg.png)
2주 차 추가 피드백
2주 차에서는 많은 피드백을 받았습니다. 전부 눈 여겨볼 만한 피드백이었고, 그중 중복되는 것이 있었습니다.
- 조건절에도 의미있는 변수 사용 : 사실 코수타에서 들었는데 생각을 못했는지 적용을 못했네요
- while문의 조건절에 true보다 의미 있게 사용
- for문의 i대신 의미있는 네이밍을 따로 붙여 사용
- 예외처리에 사용되는 args도 상수 화하여 네이밍 : 가독성이 증가할 것이다.
- startGame처럼 명확한 기능을 하는 메서드면 주석 사용 X
이 외에도 제가 피어 리뷰 요청을 할 때 코드를 짜면서 생각했던 궁금증 등이 있었습니다.
프리코스 3주 차
이번 주차의 목적은 기존 목적에 클래스를 분리하는 연습과 도메인 로직에 대한 단위 테스트 작성하는 것이었습니다.
제가 프리코스를 진행하면서 느꼈던 우테코가 우리에게 진행하면서 느꼈으면 했던 것은 문제에 대한 분석과 사용자의 입력에 대한 예외 처리를 어떻게 하는 것이 좋은가도 있었던 거 같습니다.
문제 자체가 이전 주차에 비해 다양한 입력이 들어올 수 있었고, 문제 자체에 출력 규격도 꼼꼼히 봐야 했습니다.
요구 사항
1. Java Enum을 사용한다.
등수에 따른 가격 등을 enum으로 볼 수 있었습니다.
2. else 자체를 사용하면 안 된다.
if절에서 사용하는 else문을 사용하지 않았어야 한다. 또한 switch/case문으로 대체하면 안 됐다.
따라서 함수를 사용하여 해결하라고 명시되어 있습니다.
3. 도메인 로직에 단위 테스트를 구현해야 한다.
핵심 로직을 구현하는 코드와 UI를 담당하는 로직을 분리하여 구현한다.
4. 라이브러리
Randoms에 대해서는 pickUniqueNumbersInRange()를 활용하여 사용하고
Console은 이전과 같이 readLine()을 활용한다.
5. Lotto 클래스 제한사항
- 매개변수 없는 생성자 추가 불가
- number 멤버 변수 접근 제어자 private 변경 불가
- Lotto 필드에 인스턴스 변수 추가 불가
- 패캐지는 변경 가능
로또 게임
[PrintGameInfo] : 출력 관련 클래스
출력에 대해서 규격이 존재하며, 예외 문구에 대해서도 상수화 하여 네이밍을 붙이라는 조언을 받아서 따로 크래스로 분리하여 관리하였습니다.
[InputException] : 사용자 입력에 대한 예외처리 클래스
사용작 입력한 것에 대한 예외는 main클래스에서 전부 처리하기에는 양도 많고 연관이 없는 거 같아서 따로 분리하였습니다.
다만, 다른 예외의 경우 따로 같은 패키지 내의 클래스로 분리한 것이 아니라 하나의 클래스 내부에서 메서드로 뽑아서 예외처리를 하였습니다. 이렇게 한 이유는 클래스 내에서 메서드를 분리하여 진행한 이유는 해당 클래스가 들어온 값에 대한 예외를 처리하는 것이 맞다 생각했습니다.
하지만 지금 생각해보면 메서드만 분리하면 결국 메인 함수가 어떻게 동작하는지 보기 힘들어졌습니다. 따라서 예외 클래스를 따로 만들어 처리하는 게 더 낫지 않나 라는 생각을 하고 있습니다.
(다른 분들의 의견에 관한 좋은 글이 있어서 공유합니다. 여기서도 같은 고민을 한 분들의 의견이 있었습니다.)
[ENUM : LottoPoint, WinningStatus] : Lotto관련 상수 값
LottoPoint에서는 로또에서 당첨 개수와 보너스 번호에 따른 값을 나타내기 위해 사용했고
WinningStatus에서는 우승에 대한 금액, 출력 내용, 포인트에 따른 결과를 담았습니다.
이렇게 Enum을 2개로 나눴던 이유는 두 개가 필요한 특성이 달라서 분류했습니다.
[LottoList] : 한 사람이 로또를 여러 개 산 것을 관리하는 리스트입니다.
여기에 사실 구매 금액까지 넣었는데, 다시 생각해보면 user에 대한 클래스를 만들어서 해당 클래스를 참조 변수로 할당받아 사용하는 것이 좋을 거 같다 생각합니다.
진행 도중 발생했던 에러
이번 프로젝트에서 테스트 코드를 돌리던 도중 끝가지 고생했던 에러가 있어서 가져왔습니다.
1. printStackTrace() vs getMessage() : 예외 처리 관련 메서드
이전 포스트에서 이미 작성해서 넘기겠습니다.
2. ImmutableCollections sort문제
입력된 리스트에 대해 정렬을 하여 출력해야 하는 기능이 있었습니다.
생성자를 통해 값을 전달받고 sort를 하는 도중에 java.lang.UnsupportedOperationException 에러가 발생했습니다.
예외 내용을 보니 ImmutableCollection의 sort에서 예외가 발생했습니다.
처음에는 List.of에 대해서 Immutable list로 만들어 주는지 몰랐기 때문에 책과 구글링으로 해결했고, Java mutable 리스트와 deepCopy를 하는 방법에 대해 공부하는 계기가 되었습니다.
후기
지난 주차 리뷰
1주 차 피어 리뷰에서는 많은 리뷰를 받지 못했었습니다. 하지만 2주차 피어리뷰에서 생각 이상의 리뷰를 받게 되면서 많이 설레었습니다. 전자공학과를 전공하면서 코드 리뷰의 경험이 없었지만, 이번 기회에 리뷰를 받으면서 내가 코드를 짜면서 느꼈던 답답함이나 궁금증 등을 풀 수 있을 거란 기대감이 컸던 거 같습니다.
받은 리뷰가 많다보니 정리가 필요했고, 컴퓨터 스티커 어플을 통해 리뷰에 대해 정리하고 코드 짤때 참고하면서 작성하였습니다. 이렇게 하다보니 코드를 짜면서 저번 피드백 받은 부분을 많이 고려할 수 있었고, 기존에 가지고 있던 문제를 해결해 나갔습니다.
함수 길이의 제한과 분리
함수 길이 자체를 제한하고 if문만을 사용하여 작성하는 것은 새롭고 재밌었던 요구사항 이었습니다. 확실히 함수 분리를 통해 else문을 피하며 작성할 수 있었고, 어떻게 처리하면 좋을 까 라는 생각도 들었습니다.
Enum 클래스 사용
지난 주차에 Enum클래스에 대해 일시적을 사용했고, 이번 주차에 많은 기능을 담아서 사용했습니다. Enum을 사용하면서 확실히 상수를 치환하며 사용했을 때 해당 값이 어떤 내용을 담고 있는지 보기 쉬웠고 하나의 값이 아닌 여러 값으로 묶어 사용하면서 사용성이 편리했습니다.
아쉬웠던 점
이번 주차의 주요 목표인 클래스 분리와 도메인 로직에 대한 로직 테스트에 대해서는 제대로 하지 못한 점이 아쉽습니다. 클래스 분리에 목표를 두려 했지만 다 짜고 난 후 User에 대한 클래스를 추가하여 LottoList의 기능을 분리할 수 있었다는 생각도 들었고, 예외 처리도 클래스 내부에서 책임지고 진행해야 하더라도 예외 클래스를 따로 두어서 작성했으면 더 좋았겠다와 다른 분들의 클래스를 보며 클래스 분리 뿐 아니라 패캐지까지 분리하고 MVC 패턴까지 적용한 모습을 보니 많이 부족했다는 생각이 들었습니다.
추가 필요 학습 사항
- 테스트 코드 : 아직 테스트 코드를 잘 작성하지 못하는 것이 눈에 보였다.
- MVC패턴 및 클래스 분리 : 패캐지를 분리하여 MVC패턴을 적용하기 위해 공부하며 다른 분들의 코드를 많이 참고해 봐야겠다.
- 문법적 에러 : 잘 이해하지 못하여 Immutable 에러가 발생했던 것을 생각하면 Collections 부분과 제네릭 부분을 더 학습해야 할꺼 같습니다.
개인적인 감정, 제출 비하인드 스토리
마지막 날에 프로젝트에 대한 테스트 코드를 돌려보았습니다. 직접 테스트 케이스를 만들면서 진행하였는데 잘 동작 되는 줄 알았습니다 이 후 제출하여 테스트 코드를 실행하는데 하나가 통과가 안되는 거에요. 그래서 '어디서 잘못된 건가?' 라고 생각하며 테스트 코드 다시 돌려보고 중요 메서드에 대해 돌려보면서 제대로 동작 되는지 확인했는데 결과 값이 제대로 나오니까 '아 망했다 어디서 잘못된 거지' 생각하면서 계속 찾는데 오류 부분은 안보이고 시간만 흐르니까 마음이 조급해 지더라고요. 그래서 에러는 못찾고 시간만 지나갔습니다.
결국 해결을 못해서 포기한 상태로 저녁에 밥먹으로 나가려하는데 혹시 모르니까 노트북 들고 가볼자 하면서 주섬주섬 챙기고 갔습니다. 이때 솔직히 이것도 해결 못하는 제가 싫었고, 아쉬움도 많이 남은 상태였습니다. 그래서 많이 기분이 안좋은 상태였고 안되겠다 싶은 심정으로 친구들 불러서 소주를 마시러 갔습니다.
그렇게 친구들이랑 마시다가 제가 이런거 하는거 아직 오늘 제출인데 해결 못해서 그냥 왔다고 하니 친구들이 장난스럽게 '지금 가서 좀 하다 오던지' 라고 하더라고요.
저는 근데 거기에 뭔가 억울함이 쌓인게 터졌는지 '그럼 마시고 있어 나 갔다올께' 하고 자리에서 나가서 근처 카페는 문을 닫을꺼 같아서 24시 만화카페를 가서 진행했습니다. 그렇게 키보드에 울분을 토하면서 하나하나 나가다가 테스트 에러 문구와 결과값 그리고 예외처리 catch한 부분의 방식이 머리속에 스쳐지나갔고 두 방식에 대한 차이를 빠르게 구글링해서 대략적으로 파악한 후 변경하여 제출 마감 40분 전에 운좋게 통과를 하였습니다.
사실 너무 극적으로 통과되었고 해결했던 과정 역시 짜릿해서 좋았지만, 사실 원인은 촉박했던 시간과 조급함으로 시야가 많이 좁아졌고, 당연히 문제 없을 거 같던 사소한 것도 그냥 지나쳐서 해결을 못한거 같습니다. 좀 더 침착하게 대응을 하고 하나하나 다시 봐야 겠다는 교훈을 얻었습니다.