우아한테크코스 5기 우테코 프리코스 4주차 회고

프리코스 마지막 주 회고록입니다. 무척 아쉽네요.

매주 온 열정을 쏟으면서 밤을 새서 그런지 미션이 오는 수요일에는 바짝 긴장을 했다가, 제출하는 그 다음주 화요일 쯤에는 항상 몸살 기운이 있었는데...그것도 끝이네요.

 

특히 마지막 주는 굉장이 어려울 것이라고 생각되었기에 더욱 더 긴장했었습니다.

 

엎친 데 덮친 격으로 퇴사를 앞두고 있다보니 신입이 들어와 인수인계도 같이 하다보니 정신이 하나도 없었습니다.

고통의 크기에는 제한이 없다!!

뭐 별 수 있나요! 부족한 실력을 떼우려면 컴퓨터 앞에 앉아있는 시간이 길어야겠죠!!

 

 

---

 

4주차 미션

대망의 4주차 미션은 다리 건너기(링크) 미션입니다.

오징어 게임에서 징검다리 건너기 게임과 완전 동일한 것을 구현하는 겁니다.

드라마에서도 징검다리 건너기 후 본 게임인 오징어 게임을 했으니....

이것도 본 게임인 우테코 전 마지막임을 의미하는 걸까요??

 

어쨌든... 먼저 피드백을 쭉 훑어보기로 했습니다.

 

프리코스 3주차 공통 피드백의 피드백 (링크)

 

점점 늘어나는 피드백 수만큼 기쁨도 커졌습니다..제가 설마 공부를 하면서 이렇게 느낄줄은 몰랐네요...

혼자 고뇌하는 시간을 가지며 구현하다가, 이렇게 피드백 문서를 보면 이렇게 쉬운 방법이?? 띠용?👀 하며 한줄기 빛을 보는 느낌이라서 그런 것 같습니다.

 

README 작성

여태껏 README 초안 작성은 그렇게 어렵지 않았습니다.

그렇지만 작성이 어렵게 느껴지는 까닭은 JAVA가 어떻게 굴러가는지 모르기 때문에 이걸 고려하는 시간이 상당히 많기 때문이죠.

 

생각하는 바를 우선 쭉 적고, 온 미션에서 초기 클래스가 어떻게 분리되어 있는지 보고, 테스트 코드를 봅니다.

 

테스트 코드를 보면 어떤 클래스를 이용해서 테스트 하는지 알 수 있고, 이것에 맞춰서 클래스를 구현해 가야겠다는 생각이 이 들어요.

만약 테스트코드에서 특별한 규약이 없다고 느껴지면, 그냥 제 입맛대로 구현하면 되겠죠.

 

지난주에는 lotto 객체로 손발을 묶더니, 이번에는 인터페이스가 또 저를 붙잡았습니다.

 

인터페이스

자바의 정석에서는 인터페이스는 껍데기라고 지칭합니다. 

무슨 이야기냐면 implement로 인터페이스를 상속받게 되면 인터페이스가 가진 메소드를 반드시 오버라이딩 해야합니다.

메소드 껍데기를 상속시켜서 반드시 필요한 기능으로 구현 시켜야 하는거죠.

 

이는 마치 추상클래스의 추상메소드와 형태가 비슷합니다.

 

추상메소드란?

 

둘의 차이는 추상클래스와 달리 인터페이스는 생성자가 없다는 것이 특징입니다.

정확한 것은 둘을 더 조금 공부해봐야 알 것 같아요.

 

기능구현

1. 인터페이스를 어떻게 활용할 것인가

파일을 딱 여니 view 클래스가 추가되고, 인터페이스가 있었기 때문에 난감했습니다.

또한 요구사항에 BridgeMaker를 활용하여 구현해야 된다는 내용이 적혀있었기에 이걸 활용해야 했죠.

BridgeMaker를 열어보니 필드에 인터페이스인 bridgeNumberGenerator  타입을 필드로 가지고, 또 생성자에서 매개변수로 인터페이스를 받게끔 되어 있었습니다.

 

어떤 다리를 어떻게 만들지? 에 대한 고민을 한참을 했습니다.

긴 고민 끝에 먼저 한 줄짜리 정답 다리를 만들고, 사용자가 다리를 건널 때 두 개의 다리를 만들어 선택되는 것에 따라 위랑 아래 다리를 출력해주는 방법을 생각했습니다.

 

다리 만들어본다고 새 클래스를 만들어서 인터페이스 상속해보고 난리도 아니었습니다....ㅎ

 

2. 메소드 내 10줄 제한의 고통

10줄의 고통은 상상 이상이었습니다. if 문이라고 치면 벌써 두 줄입니다.

if문 안에 if문은 벌써 3줄입니다. 하고자 하는 로직은 제일 안쪽 if문 안에 한 번 들어갔는데 3줄이나 차지합니다.

이런 방식은 하지 말아야 된다고 생각해서 최대한 메소드를 나누었습니다.

 

아쉬운 것은 객체를 더 분리하지 못하여 view영역에 숫자를 검증하는 메소드가 들어갔다는 것이죠...

공부를 더 해야겠다는 생각이 들었습니다.

 

3. try catch 와 throw의 차이

전 주차에는 단순히 잘못 된 입력값이 들어오면 exception을 던지고 프로그램이 끝났습니다.

하지만 이번에는 에러메시지를 출력하고 다시 입력값을 받아야 하기에 try catch문을 써야 했습니다.

습관처럼 if문에 exception 던지는 것을 했다가, 나중에 리팩토링하면서 이것이 잘못된 것을 알게 되었습니다.

 

던졌으면 받아야하는게 맞겠죠😊

 

4. 공통된 입력값을 ENUM 처리할 수는 없을까?

요구사항을 잘 읽어보면, 다리 추출 입력값은 0과 1만 받을수 있고,

0이 들어오면 아래칸이 정답이 되고, 1이 들어오면 위칸이 정답이 됩니다.

아래칸을 뜻하는 D , 위칸을 뜻하는 U.....

 

공통된 부분은 위칸과 아래칸으로 각각 하나로 묶을 수 있을 것 같았습니다.

 

그래서 direction이라는 ENUM을 만들었습니다.

0과 D를 묶고, 1과 U를 묶었지요.

 

더 뭔가 묶고 싶었지만, 공통으로 필드를 가져야 하는 ENUM 특성상 다른것을 더 엮기가 뭔가 까다로웠습니다.

 

5. 예기치 않은 오류가 발생했습니다. 

로컬에서 테스트 코드가 정확히 돌아가는 것을 확인하고 제출기간인 화요일 오전에 제출을 했습니다.

그리고 테스트를 돌려보는데....

 

 

위와 같은 메시지가 뜹니다...!!!!

 

아마 많은 분들이 겪으셨던 예기치 못한 오류 메시지입니다....서버 오류 절대 아님

몇 번을 돌려봤는데도 동일했습니다. 제 코드 문제였죠.

분명 요구사항을 명확히 읽었거늘....!!

 

원인은 지난 주 수요일쯤 읽었던 요구사항을 까먹고 지키지 못한 까닭이었습니다. 일주일 다 되어가니...🙄

 

뭔가 바꾸지 말라는 말이 있었던 것 같은데...바꿔도 된다는 말을 내가 잘못 기억하고있나....하면서 옮겼다가 나중에 발견하고 원래대로 해놓았습니다.(뭔지는 비밀...뭔가 옮겼다는 게 힌트입니다...)

 

이번에도 약 나흘간 밤을 샜는데 마지막 테스트에 실패메시지를 보고 0점 맞는줄 알고 식겁했습니다.......🤣🤣🤣🤣

다행히 테스트는 통과했기 때문에 감점(?)은 당하지 않기를 바래 봅니다.

---

미션 제출 완료

돌이켜보면 4주간 정말 열심히 달렸고, 코치님들과 같이 참여한 크루들에게서 많은 것을 배울 수 있었습니다.

확실한 것은 처음에 느꼈던 것처럼 '개발은 적성에 맞는 것 같다'는 것이 더 확고해졌다는 것입니다.

 

1차 합격자 발표에 붙어야 최종 코테를 볼 수 있습니다.

그리고 코수타에서 말하길 1차 합격자 발표는 '절대평가'를 기준으로 한다고 합니다.

그래서 우선 저는 최선을 다했으니....기다리기로 합니다. 

 

만일 최종 코테를 보게되어 다섯시간만에 구현하게 된다고 가정하면 지극히 모자란 실력을 늘려 구현 시간을 줄여야겠죠.

 

꼭 코테를 통과하기 위함이 아니더라도, 붙어서 본 과정이 시작되면 페어 프로그래밍을 할텐데 같이 하게 될 동료에게 민폐를 끼치면 안되게 위해서라도 어느정도 마스터하고 가야합니다!!!

 

나름대로 이번 4주차 분석을 해보면... 우선 총 4일 걸린 시간을 줄여야 합니다.

 

인터페이스에 삽질하는데 하루,

구현하는데 약 하루(24시간쯤?),

리팩토링과 테스트 코드를 작성하는데 이틀 정도 걸렸습니다.

 

그래서 나름대로 앞으로의 계획을 만들었습니다.

 

우선 첫번째로 인터페이스를 비롯한 자바 문법에는 완전 숙달되어야 합니다.

이번에 많이 배우긴 했지만...그냥 원하는 문법을 검색없이 쓱쓱 사용할 수 있어야 합니다.

 

두번째로 LIST를 꺼내고 쪼개는 등 다루는 것에 익숙해져야 합니다.

컬렉션 프레임워크를 이용해 빼내고 넣고 변환하고 등등....

숙달해서 가지고 놀 수 있으면 시간 단축이 많이 될 것 같습니다. 

 

세번째로 리팩토링하는 시간을 줄여야 합니다.

리팩토링 하는 시간을 줄이려면 처음부터 괜찮은 코드를 만들어내면 됩니다.(음..?)

그럴려면 READ ME, 즉 처음에 설계를 잘 구성하면 이 시간을 줄일 수 있을 것 같아요.

 

네번째로 테스트 코드에 숙달되어야 합니다.

일반적인 코테에서는 테스트 코드를 만드는 것이 필수는 아니겠지만, 현업에서 개발자라면 테스트 코드를 잘 다뤄야 한다는 것은 매 주차마다 피드백에서 중요하게 강조한 만큼 필요한 역량인 것 같습니다. 그렇다면 테스트코드 역시 잘 사용할 줄 알아야 하고, 또 그러려면 기능분리 또한 잘 되어 있어야 합니다....

 

뭐 한마디로 표현하면 '다 잘해야 한다!'가 되겠지만...나름 항목을 나누어 READ ME 한개씩 구현하듯이 도장깨기 해서 열심히 실력을 쌓아보려고 합니다.

 

만일 1차합이 안되더라도, 우형에는 우테캠이라든지 다른 방법이 있으니까요!!

절대평가라는 기준이 있으니 그 기준을 뛰어넘게 열심히 하면 될 것 같습니다 !!

 

1차합까지 3주간의 휴식 아닌 휴식동안 더 불타 올라야겠습니다.

그동안 정리해서 올리지 못한 개념들도 좀 올리고 해야겠습니다.

이제 본격적인 시작입니다. 😡😡😡😡😡👿👿👿👿👿