이번에도 문제를 받는 순간은 엄청 설렜다. 문제를 읽었을 때는 생각보다 난이도가 낮은 문제라고 생각해서 문제를 잘 풀 수 있을 것 같고 금방 끝낼 수 있을 것 같았다. 하지만, 요구사항을 만족하며 코딩을 하다보니 생각보다 일주일이라는 시간이 길지 않았던 것 같다. 일주일 동안 이 과제에 대해 몰입해서 공부하면서 성취감도 같이 느꼈던 것 같다. 어쩌면 우테코에서 원하는 '스스로 성장하는 모습'이라는 것이 이런 모습 아닐까?라는 생각도 하게되었다.
드디어 3주차..! 이번 3주차는 '로또' 였다. 3주차에서는 2가지 목표가 추가되었는데, 클래스를 분리하는 연습과, 도메인 로직에 대한 단위 테스트를 작성하는 연습이 추가되었다. 추가로, 프리코스를 하는 내내 했던 고민이지만, 적절한 네이밍과 함수 분리에 대해서도 고민을 많이 했던 것 같다. "개발자는 코드로 말한다"라는 말이 있듯이, 코드를 통해 내 의도를 깔끔하게 보여주는 것이 개발자의 중요한 역량이라고 생각한다. 이번 프리코스를 하면서 깔끔하고, 객체지향적인 코드를 작성하는 것은 꾸준한 노력이 필요하고 스스로 계속 공부해야됨을 느꼈다.
이번 과제에서는 MVC 패턴을 적용했는데, 내가 이런 패턴을 적용해야겠다고 마음먹은 이유는, 2주차 숫자야구 게임에서는 정확한 분류가 없다고 생각이 들었기 때문에, 적용하지 않았었다. 하지만, 이번 과제를 읽으면서 "아! 이번에는 MVC 패턴을 적용해보자!" 라는 생각이 바로 들었다. 과제를 다 풀고난 지금, 다시 생각해보면, 클래스의 분리에 있어서 MVC 패턴이 효과적으로 사용되었다고 생각한다. 덕분에 각각의 역할에 따라 클래스를 나누고 진행할 수 있었기 때문이다.
사실 이번주에 저번주부터 공부하기 시작한 TDD를 좀 더 해볼까,,? 싶었지만, 포비님이 코수타 때 "TDD, ODD, 클린 코드 잘하면 우테코 뭐 하러 들어오는가. 그냥 취업하면 되지.그런 거에 너무 휩쓸리지 말고, 현재 상태를 잘 인식해서 요구사항에서 부족한 게 있으면, 부족한 점을 보완하자."라는 말씀을 해주셨다. 다시 생각해보니까 맞는말이다. 아직 나는 객체를 객체스럽게 짜는 것도 어려워하면서 TDD를 공부하고 적용해보는 것은 너무 이르다는 생각이 들었다. 때문에, 이번에는 주어진 요구사항만 잘 지켜보자!라는 마음가짐으로 임했던 것 같다.
또 저번 주 과제에는 상수 부분을 enum 타입으로 뺄지 말지에 대한 고민을 되게 많이 했었는데, 마침 요구사항에 있는 것을 보고, 오류 메세지나, input, output 메세지를 enum 타입으로 작성해보았다. enum 타입을 알고만 있었지 실제로 내가 작성해보는 것은 처음이라, 초반에는 혼란스러웠지만, 지금은 어느정도 감을 잡은 것 같다.
저번 주차까지는 기능 단위 커밋을 너무 쪼개서 커밋을 한다는 느낌이 들어서, 이번에는 요구사항 목록을 기준으로 기능 단위 커밋을 하려고 노력했다.
1. Readme 작성
## 기능 목록
1. [x] 금액 입력받기
1.[x] 예외 : 숫자가 아닌 경우 에러메세지 출력
2.[x] 예외 : 0을 입력한 경우 에러메세지 출력
3.[x] 예외 : 1000원 단위가 아닌 경우 에러메세지 출력
4.[x] 예외 : 금액을 입력하지 않았을 경우 에러메세지 출력
2.[x] 로또 구매 수량 구하기
3.[x] 수량만큼 로또 번호 생성
4.[x] 로또 수량 출력
5.[x] 오름차순으로 정렬한 로또번호 출력
6.[x] 당첨번호 입력 받기
1. [x] 예외 : 1 ~ 45 범위를 벗어난 경우 에러메세지 출력
2. [x] 예외 : 6개의 수가 아닌 경우 에러메세지 출력
3. [x] 예외 : 중복된 숫자가 존재하는 경우 에러메세지 출력
7.[x] 보너스 번호 입력 받기
1.[x] 예외 : 1 ~ 45 범위를 벗어난 경우 에러메세지 출력
2.[x] 예외 : 중복된 숫자가 존재하는 경우 에러메세지 출력
8.[x] 로또 당첨 개수 구하기
1. [x] 로또 당첨 개수 출력
9. [x] 로또 당첨 금액 구하기
10.[x] 수익률 계산
1.[x] 수익률 출력
2. 코드 작성
https://github.com/myeongju00/java-lotto
아쉬웠던 점
이번에도, 마찬가지로 처음부터 완성된 코드를 작성하고 싶어서인지, 욕심이 너무 많아 생각만 하다가 시작을 조금 늦게했던 것 같다. 그 고민이 의미가 없는 시간은 아니었지만, 너무 고민을 오래해서 마지막쯤엔 구현하는데에 시간이 부족하다고 느꼈다. 어느정도 구체적으로 결론이 섰으면, 바로 시작을 하는 방법을 조금 더 노력해봐야겠다.
도메인 로직에 대한 단위 테스트를 작성하는 연습을 하면서 이게 맞나,,? 이렇게 하는게 맞을까,,?라는 고민을 많이 했던 것 같다. 아직 어느정도의 단위까지 테스트를 해야할지 확실하게 감을 못잡을 것 같다는 느낌이 들었다. 그래도, 나름대로 최선을 다해 작성했으니, 후회는 없지만, 테스트코드에 대해 더 많은 공부가 필요할 것 같다는 생각이 들었던 일주일이었다.
느낀점
이번 주부터 요구사항이 많아져서 코드 한줄 한줄 작성하는데 시간도 걸리고, 더 열심히 작성했던 것 같다. 이번주는 개인적으로 많은 일이 있어서 내가 원하는 만큼의 퀄리티가 나오지 않은 것 같아서 그게 제일 아쉽다. 최근에 이렇게 까지 잠을 줄여가면서 공부를 하는데도, 중간에 어려운 문제를 마주쳤을 때는 정말 힘들었지만, 푸는 내내 흥미를 느꼈던 것 같다. 이번주에 이 과제를 하면서 "아 내가 코딩하면서 느끼는 이 감정 때문에 개발자가 되려고 했었지"라는 생각이 들면서 처음 코딩 공부를 했을 때의 마음가짐으로 다시 돌아갔던 것 같아서 좋았다. 다음주는 이번주보다 더 어렵고, 힘든 문제가 있겠지만, 약간의 두려움보다 설렘이 더 큰 것 같다. 남은 기간동안 최선을 다해서 과제를 완성 시켜서 이 프리코스에서 얻어갈 수 있는 것을 최대한을 얻어가고 싶다.
3주차 공통 피드백
- 발생할 수 있는 예외 상황에 대해 고민한다
- 비즈니스 로직과 UI 로직을 분리한다
- 연관성이 있는 상수는 static final 대신 enum을 활용한다
- final 키워드를 사용해 값의 변경을 막는다
- 객체의 상태 접근을 제한한다
- 객체는 객체스럽게 사용한다
- 필드(인스턴스 변수)의 수를 줄이기 위해 노력한다
- 성공하는 케이스 뿐만 아니라 예외에 대한 케이스도 테스트한다
- 테스트 코드도 코드다
- 테스트를 위한 코드는 구현 코드에서 분리되어야 한다
- 단위 테스트하기 어려운 코드를 단위 테스트하기
- private 함수를 테스트 하고 싶다면 클래스(객체) 분리를 고려한다