❗ 너무나도 힘들었던 3차 전직 퀘스트
이전 머리말에선 이 정도까지 제목을 쓰지 않고 바로바로 넘어갔었는데 이번 주차부터는 되게 생각할 것과 함께 느끼는 것도 많이 있어서 이렇게 작성하게 되었다. 위 제목처럼 진짜 되게 힘든 미션이었다. 그래도 퀘스트를 클리어해나가면서 전직하였으니 또 얻은 것도 당연히 많았다. 이번에는 그 점을 중점으로 더 자세하게 회고를 해보려고 한다.
🧐그 미션의 정체는?
바로 로또다!
이번 주차 PR주소
미션 주소
✔ 이번 미션 중 중심으로 잡았던 것은?
이번 미션을 하면서 원래는 이전에 스터디도 잠깐 해보고 했었는데 너무나도 대단하신 분들이 많으신 거 같았다. 서로 코드 리뷰를 하는데 MVC패턴이나 여러가지 설계 방식에 대해서 시도하시는 분들이 많으셔서 되게 어떻게 보면 존경스러운 시선으로 바라보고만 있었던 것 같았다.
그치만!
코수타에서 코치님들께서 말씀하셨던 것처럼 남의 신경을 쓸 데가 아니라 이런 좋은 기회를 자신의 성장으로 삼고 자신을 위해서 써야지. 다른 어떤 좋은 기술이든 설계 기술이든 나중엔 쓰겠지만 지금은 자신에게 맞는 기술들을 배우고 연습해나가는 것이 더 중요하다고 하셨다. 그래서 그 말씀처럼 이번 주차의 나에 대한 요구사항은 다음과 같았다.
📌 3주차 목표
- 기능 구현 목록 먼저 작성해놓고 구현 시작
- 기능 구현 마다 커밋 올려보기
- 수정이 일어나도 괜찮으니 계속 구현해나가보기.
- 분류할때 잘 분류해보기 패키지명이라도! (지난주차땐 너무 두서없었음)
- 요구사항 잘 지켜나가기
- 단위 테스트 구현할때 한 곳에 몰아넣어서 하지 않기!(지난 주차 코드 리뷰때 얻은 피드백!)
어떻게 보면 너무나 기본적이긴 하지만 어디서든 공부해도 가장 많이 듣는 게 기반을 잘 쌓아나가야지. 나중에 가서 무너지지 않는다는 말처럼 저번 주차보다 더 기본에 신경을 써보기로 하였다!
📌 피드백 강의
우선 첫 번째로 코드를 작성하기 전에 강의부터 보고 진행하였다. 코치님께서 직접 저번 주차의 미션에 대해서 완전 처음부터 시작하셔서 하나씩 알려주시는 강의였다. 보면서 느낀 것은 말하는 대로 생각한 대로 구현해 나가신다는 것이었다. 그리고 철저하게 그 요구사항에 맞게 하나씩 진행하실 때마다 기능을 체크하시고 그에 따른 커밋 그리고 그 후에 마지막 과정으로 단위 테스트까지! 너무나 정석적으로 제대로 진행이 되어서 살짝 어안이 벙벙해졌었다.
그래도 진행하시면서 가장 기본적인 것에서만 말씀하여주시고 전혀 따라 하지도 못할 것도 아닌 수준으로 설명을 해주셨기에 그 강의를 보며 자신감을 되게 많이 불어넣어 주신 거 같다는 느낌을 많이 받게 되었다. 그렇게 이번 주차에서는 구현을 하는 데에 있어서 나도 하나씩 한 마디씩 말하는 대로 코드를 하나씩 구현하고 설계해 나가는 식으로 미션을 진행하였던 거 같다!
📌 요구사항을 잘 파악하는 부분
이번에 진행하면서 요구사항을 보게 되면 차례차례 하나씩 기능 구현을 넣으면서 확인하고 하다 보니 예외를 처리하는 요구사항의 부분에서 국어적으로 잘 이해가 되지 않는 부분이 있었다! 그래서 그 부분을 고민한다고 초반에 아무 코드를 작성하지 않고 계속 그것만 붙잡고 있었는데 이 문제는 너무 진도가 나가지 않아서 일단 나중에 다른 기능들을 우선 구현하고 나중에 더 고민해보기로 하였었다.???
그래서 그 후에 확인하고 보니 나중에는 메일로까지 날아올 정도로 많은 분이 그 부분에 대해서 문의를 해주신 것 같았다. (나 혼자만 그러고 있었던 건 아니었구나) 그래서 결국 해결하기는 하였는데 이 부분에서 가장 많이 느끼게 된 것은 요구사항에 대해서 잘 읽으려면 독해력을 잘 길러놔야겠다는 생각과 함께 책을 많이 읽긴 해야겠다는 것을 많이 느끼게 되었다. (독해실력이 ㅠㅠ)
📌 생활 속에서 얻게 된 예외
이번 미션을 진행하면서 가장 많이 느끼게 되었다. 결국에는 이번 로또 미션도 그렇고 다른 미션들도 그럴 테지만 결국은 생활 속에서 예외를 얻을 수 있다는 것이었다. 이번 미션에는 아버지의 도움을 받아 여러 예외도 발견하게 되고 오해했던 부분들에 대해서 다시 수정하고 해결할 수 있어서 되게 신기한 경험이었다. 되게 중요한 부분이었는데 너무 간단하게 해답을 얻게 되어서 생활 속의 경험도 나중에 예외를 찾아내는 데에 있어서 중요한 요소가 될 수도 있겠다고 생각하게 되었다.
📌 도대체 에러를 발생시키고 그냥 종료를 어떻게 시키지?
이번 테스트 코드에서 보게 되면 상당히 고민이 되는 것이 있었다. 바로 1000j라는 금액을 입력하였을때이다.
@Test
@DisplayName("사용자 금액입력에 숫자가 아닌 것이 올 경우")
void 입력에숫자가아닌_예외_테스트() {
assertSimpleTest(() -> {
runException("1000j");
assertThat(output()).contains(ERROR_MESSAGE);
});
}이 부분이었는데 요구사항에 있어서는 IllegalArgumentException를 발생시키고 [ERROR]가 포함된 에러 메시지를 출력을 시켜야 한다. 처음에 생각하였을때는 그냥 throw시켜서 종료시키지 라고 생각했었지만 그렇게 진행할 경우 아예 프로그램이 진행되는 과정 속 모든 것을 다 무시한채 비정상적으로 종료가 되어서 다르게 처리를 했어야 했다. 그래서 이번에는 try-catch를 통하여서 예외를 처리하는 과정이 필요하였다. 다른 과정도 그렇고 한번에 묶어서 IllegalArgumentException을 시키는 것이 좋겠다고 생각하였다. 그래서 메인을 담당하던 부분에 try-catch를 사용하여서 처리를 하면 됬다.
try{
BuyLottoTickets buyLottoTickets = new BuyLottoTickets();
OutputView.printButMoney();
int money = InputUserMoney.inputMoney();
inputValues(buyLottoTickets, money);
LottoGame game = new LottoGame();
game.Game();
}
catch (IllegalArgumentException e){
OutputView.printException(e);
}그래서 진행하다가 try부분에서 검증하거나 실행을 할때 throw를 시켜서 바로 오류를 출력하는 부분으로 넘어가게 처리를 하면 다른 검증에서는 에러를 발생시키고 큰 코드의 입장에서는 오류를 발생시키고 오류 메시지를 출력한 후 프로그램을 종료하는 형식으로 가게 되었다. 이렇게 글로 작성하긴 하였지만 처음엔 되게 고민을 많이 하게 된 부분이었다.
자바를 별로 많이 사용해보지 않아서 이전에 try-catch를 보게 되었을때는 이게 굳이 필요했나? 라는 생각을 하였지만 실전을 통해 경험하면서 예외를 나왔을때 로그를 발생시키고 종료를 시키는 작업이 반드시 필요하다는 것을 많이 느끼게 되었다. -> 중간에 갑자기 실행하다가 비정상적으로 종료되면 안되기 때문이었다.
📂 기능에 따라 클래스, 패키지 분류하기
위에서부터 하나씩 1주차, 2주차, 3주차의 파일 목록들이다. 물론! 눈으로만 본다면은 3주차 것이 당연히 많다. 분류도 더 많이 하고 기능에 따라 더 세분화했기 때문이다. 그렇지만 1, 2주차에서의 나의 문제점은 너무 한정된 클래스 안에서 모든 것을 다 하려고 했던 것이라고 생각한다. 그렇기에 당연히 그 하나의 클래스 파일 안에서의 코드의 가독성은 더 떨어질 수밖에 없어지고 나중에 유지, 보수의 측면에서 봤을 때는 이번 주차에서처럼 기능별로 세분화하여 나눠놓는 것이 다 만들고 나서는 훨씬 더 효율적일 수밖에 없다는 것을 많이 느끼게 되었다.
이번 미션에서는 요구사항에 핵심 로직을 구현하는 코드와 UI를 담당하는 로직을 분리해 구현한다. 라는 요구사항을 제시하셨는데 이것을 왜 제시하셨는지에 대하여 이런 깨달음을 주시기 위하여서 제시하신 것이라는 것을 분류하면서 많이 느끼게 되었다.
📕 살아있는 문서를 위한 기능 구현 목록 작성
2,3주차 기능 구현 목록
위 2, 3주차 기능 구현목록만 봐도 알겠지만, 이전까지의 기능 구현목록들은 너무 간단하게 작성했다. 그냥 핵심적인 부분만 적으면 되겠지? 라는 생각이 더 강했던 것인지 하나하나 더 세분화하여 적지 않고 나의 커밋을 그저 그것의 한 묶음으로만 담당하면 되겠지 라는 안일한 생각으로 작성하였었다.
그러나 이번 피드백 강의에서 구현하시는 코치님의 모습을 보면서 그렇게 어려운 과정은 아닌데 구현할 때의 확인해야 할 체크리스트로 생각하면서 기능 구현목록을 작성하게 된다면 결국 커밋도 그에 따라서 할 수밖에 없겠다는 생각이 많이 들었다.
### 가장 중요했던 것은 기능 구현목록 작성은 내가 코드를 작성하는데 좋은 습관을 기르기 위한 과정이었다.
📌 리스트 복사
이번 미션 진행중 가장 멘붕이 왔던 부분이었다. 나의 기본기가 너무나도 부족하고 지식의 깊이가 얕았다는 것을 알 수 있었던 부분이었다. 처음에 이 부분 구현하고 있었을 때는 문제가 없었다. 그러나 이제 테스트로 들어가게 되었을 때 문제가 발생하였었는데 이 한마디가 너무나도 충격에 빠지게 하고 절망에 빠지게 하였다.
소스 코드와 바이트 코드가 일치하지 않습니다. immutableCollections$ListN@3493
다른 문제였으면 솔직히 억지로 찾아서 막 해결해보려고 했을 텐데 이 문제는 보고 너무 원초적인 문제여서 어떻게 파고 들어가야 하지? 물어보면서 진짜 멘붕이었다. 그저 F7버튼을 눌러보며 테스트 코드를 계속 디버깅할 뿐이었다. 그러다가 계속 다른 시도를 하다가 문제점을 찾게 되었는 데 너무 간단한 문제였는데 제대로 처리하지 않아 발생한 문제였다.
private void setLottoNumberTicket(List<List<Integer>> buyLottoTickets) {
List<Integer> LottoTicket = new ArrayList<>(Randoms.pickUniqueNumbersInRange(MIN_NUMBER,MAX_NUMBER,TICKET_SIZE));
Collections.sort(LottoTicket);
buyLottoTickets.add(LottoTicket);
}바로 이 부분이었는데 원래는 List<Integer> LottoTicket = Randoms.pickUniqueNumbersInRange(MIN_NUMBER,MAX_NUMBER,TICKET_SIZE) 이렇게 되어있을 때 sort부분에서 문제가 발생하였었다. 왜 발생하느냐고 하니 테스트 코드를 진행할 때는 random된 것에 대해서 미리 지정해서 넣어주게 되는데 그럴 때 꺼내오는 부분에 있어서 Random으로 막 꺼내오게 되면은 충돌이 되는 사태가 벌어지는 것이었다. 그래서 Random으로 꺼내올 때 리스트 복사를 함으로써 그 리스트에 접근하게 하여주고 처리해야 소스 코드와 바이트 코드가 일치하게 되었다.
처음엔 이 문제 도저히 해결할 수 없었겠다고 생각했고 진짜 좌절했다. 그렇지만 그래도 계속 디버깅하면서 가능한 시도를 다 해보다 보니 해결책을 찾아낼 수 있던 이 경험은 정말 이번 미션 진행하면서 얻을 수 있는 큰 경험치 중 하나였던 거 같다.
😂 끝으로
이번 주차 진행하면서 위와 같은 부분들을 해결해나가는 과정들이 너무 힘들었다. 정말 힘들었고 어찌 보면 최대한 기본을 지키기며 구현하기 위하여서 노력을 하였던 거 같다. 느낀 점이 너무 많지만 다 모아서 요약을 해보면 저번 주차 때 느낀 점이랑 이어지는 거 같다. 진짜 2차 전직할 때보다 3차 전직할 때가 더 힘들고 얻어낼 수 있는 게 더 값지었던 경험이 더 많았다. 솔직히 말하자면 다음 주차가 조금 두렵다. 이제 더 어려운 4차 전직을 하려고 하니 이런 힘든 경험 또 해야 하는 것이 힘들 건 알지만 그래도 4차를 하면 더 얻는 것이 훨씬 많지 않을까? 라는 기대를 하고 꼭 포기하지 않고 다음 주차 견뎌내야겠다는 마음을 먹어야겠다!
잘보고갑니다!
어느덧 3차전직... 4차전직도 화이팅!