[우아한테크코스] 노베이스 비전공자 우테코 프리코스 1-2주차 회고 (실제로 제출한 회고록 포함)

Maker-H/java-lotto: 로또 미션을 진행하는 저장소 (github.com)

 

1주차때는 뭐라고 적었는지 기억이 나지 않을 정도로 회고를 대충 적었었다. 대충이라고 하기엔 어감에 문제가 있지만 좀 중구난방으로 적었던거 같다. 왜냐하면 과제조차 감이 잡히지 않았기 때문에 회고도 뭘 써야할지 몰라 어떻게든 말을 만들어내서 제출했었다.

 

2주차부터는 1주차 피드백을 받고나니 감이 좀 잡혀서 과정을 상세하게 기록하려고 노력했다. 아예 과제하는 내내 메모장을 켜놓고 내가 하는 모든 일을 상세하게 기록해놨다가 과제를 제출하면서 그 과정을 이어붙이는 형식으로 회고를 작성했다.

 

아래의 회고가 내가 제출한 그대로의 회고인데 다시 읽어보니 너무 징징거렸나 싶기도 하다...ㅎㅎ 

 

 

혹시 읽으실 비전공자분들께

이때 저의 상태는 음 딱 자바 기초문법만 아는 상태였습니다. 반복문 조건문.. 그 정도 아는 상태였고. 자바 컬렉션프레임워크가 뭔지, 람다가 뭔지, 스트림이 뭔지, 제네릭이 뭔지는 과제하면서 공부했고 결국은 올솔했으니까 도전해보셨으면 좋겠습니다!

 

 

긴 글 읽기 싫으신 분을 위한 세 줄 요약.

1. 자바에 컬렉션 프레임워크가 있는지 조차 모르는 자바 문외한이었다.

2. 다른 사람들이 너무 잘해서 우울했고 나도 최대한 열심히 노력했다.

3. 에러나서 고생했지만 결국 잡는데 성공했다.

-끝-

 

 

 

💡 1주차 때는 당장 앞에 놓인 문제들을 처리하기에 급급했습니다. 자바에 컬렉션 프레임워크라는 것이 있다는 것을 알지 못했기에 set, map, list, treemap, treeset 학습에만 3일 이상을 할애했고 급하게 공부를 마친 이후 문제를 풀기 시작했습니다. 하루가 어떻게 지나가는지 모르게 조급한 와중에도 slack을 읽으며 깔끔한 커밋 메세지를 남기려 노력하고, 기능목록을 어떠한 형식으로 작성할지 이리저리 바꿔도 보고, 함수명이나 변수명도 고심하는 등 최선을 다했다고 생각했습니다.

하지만 2주차 시작 메일을 읽으니 나름대로 고민했다고 생각했던 것들이 허무해졌습니다. 1주일이라는 시간내에 이 정도의 아웃풋이면 자랑스러워해도 된다고 생각했지만 2주차 메일을 읽고 나니 저의 최선이 객관적 평균에 미치지 못하는 것 같아 우울해졌고 제가 알지 못하는 것들이 너무 많아 1주일이라는 시간내에 해결해야 한다는 것이 막막했습니다. 하지만 우울하다고 해서 해야 할 것들을 외면할 수는 없었습니다. ‘일단 그냥 해봐’를 외치며 프로그램이 커지고 복잡해보일수록 기능목록을 최대한 잘게 쪼개보라는 코치님의 말씀에 따라 제가 모르는 것들 그리고 해야하는 것들에 대한 목록을 작성해보았습니다.

[.gitignore 사용법 배우기, 공백과 주석에 관련된 코딩 컨벤션/Java 코딩 컨벤션/커밋 메세지 컨벤션 읽고 정리하기, 테스트 코드 작성하는 법 읽고 실습하기, 테스트 케이스 만드는 법 알아보기] 라는 목록을 작성하고 1주차 때의 교훈에 비추어 정답 맞추기에 집중하기 보다 문제를 ‘어떻게’ 풀어나갈 것인가에 초점을 맞추기로 마음먹었습니다.

.class 파일을 깃에 올리지 않게 하는 법은 우테코 레포지토리에 존재하는 gitignore 파일을 참고해서 해결할 수 있었지만 테스트 코드 작성에서 1차적 어려움을 겪었습니다. 생각을 거듭해봐도 다른 디렉토리에 있는 클래스를 테스트하는 것인데 import문이 없는 것이 이해되지 않았습니다. 다행스럽게도 1주차의 ApplicationTest 파일과 2주차의 ApplicationTest파일 그리고 StringTest 파일을 비교해 같은 패키지를 쓴다면 import를 해주지 않아도 된다는 사실을 깨달았습니다.

또 이전의 테스트케이스와 다르게 Nstest와 Assertions 클래스가 사용되었음을 발견했습니다. 처음보는 클래스들이어서 어떤 역할을 하는 클래스인지 알기 위해 해당 클래스에 존재하는 메소드들을 직접 찾아보았습니다. 인터페이스가 많이 사용되었고 람다식이라는 처음보는 문법들로 이루어진 클래스여서 람다식을 공부할 수 밖에 없었습니다. 시간이 많이 걸렸지만 저번 과제에서 테스트 케이스에 List<>가 있어 다행스럽게 자바 자료형을 사용할 수 있었던 것 처럼 2주차에 걸린 조건인 depth를 2까지만 허용한다는 조건이 람다를 사용시키기 위한 조건일 수도 있겠다는 생각이 들어 람다식 공부와 테스트 케이스 공부에 많은 시간을 할애하였습니다. 람다식을 익힌 후 코드들을 프린터로 출력하여 종이로도 봐보고 직접 손으로 적은 뒤 작동 순서를 그려보기도 했는데 그 와중 메소드가 static이 아니어도 테스트를 할 수 있는 Mock 클래스를 알게 되었습니다. Mock을 활용하여 main뿐만 아니라 각 메소드들을 테스트 할 수 있는 테스트 케이스를 작성할 수 있었습니다.

이번 과제를 풀며 저는 기능 목록에 좀 더 집중해보았습니다. 저는 기능목록이 계획의 의미도 있지만 저의 코드를 설명하는 설명서의 역할도 수행해야 한다고 생각합니다. 면대면으로 의사소통이 힘든 상황에서도 기능 목록만을 보고 저의 코드를 쉽게 이해하고 수정할 수 있게 건축도면처럼 기능 목록을 작성해보려고 노력했습니다. 함수를 작성하기 전 최대한 기능 목록을 자세하게 적어보려고 했지만 코드를 작성하며 조금씩 디테일이 추가되거나 원래의 계획과 다르게 변하는 지점들이 있었고 그래서 수정의 수정을 거듭해야 했습니다. 이렇게까지 해야하나 하는 생각도 들었지만 결과적으로 스스로도 작업을 중지하다 다시 시작할 때 기능목록의 도움을 많이 받을 수 있었고 이후 하나의 클래스에 있던 메소드들을 각 클래스로 분리하는 작업을 할 때도 자세히 기술한 기능목록이 많은 도움이 되었습니다.

저는 기능목록도 세세하게 기술했고, 람다도 알게 되고, 테스트 코드도 만들 수 있게되어 완성만 하면 바로 테스트를 통과할거라는 자신감이 있었습니다. 그러나 제출만 하면 되겠다고 생각한 월요일에 이러지도 저러지도 못하는 진퇴양난의 상황에 처했습니다. 분명히 IllegalArgumentException을 잘 발생시켰다고 생각했는데 계속해서 Expecting code to raise a throwable 에러가 발생했고 그러는 와중 execution timed out after 10000이라는 에러도 발생했습니다. 저는 예외에 관련된 에러를 잡으려면 try catch문을 사용해야 한다고 생각했습니다. 그런데 depth를 생각하면 try catch문을 지양해야 했었고 무엇보다 try catch문을 사용할수록 테스트 코드를 돌리는 속도가 느려졌습니다. 저번주와 비슷하게 저 스스로 자랑스러워한 것이 객관적 기준에선 아무것도 아니라는 생각에 나는 프로그래밍 업계에 몸 담으면 안되는 사람인가 자진해서 시험을 포기해야 하나 라는 생각을 했습니다.

하지만 아직 하루가 더 남아 있으니 포기해도 마지막까지 노력하고 포기한다면 후회도 미련도 없을거라는 생각에 코드 실행 속도를 올려야 하는 복잡한 작업보다 그나마 간단해 보이는 예외처리 에러부터 우선적으로 해결했습니다. 다행스럽게도 throws로 main에 예외를 넘겨서 try catch문으로 예외를 처리하는 것이 아니라 예외를 ‘발생’시켜야 한다는 것을 깨달았고 이제까지 제가 예외처리를 기계적으로 해왔다는걸 알게됨과 동시에 예외 발생 에러를 처리할 수 있었습니다.

execution timed out after 10000는 클린 코드의 원칙을 무시하면서까지 최대한 시간을 줄이려고 해봤지만 해결하지 못했습니다. 그러다가 자바의 특징에는 메모리 관리를 대신 해주는 가비지 컬렉터라는게 있다는게 생각났고 가비지 컬렉터를 활용하려면 객체를 많이 생성하는 것이 좋다는 생각이 들었습니다. 한 번의 전체적 수정을 이후에는 테스트 케이스를 통과하지 못해도 제출해야겠지만 만약 테스트 케이스를 통과하지 못한다면 저보다는 다른 사람이 우테코에 더 적합할거라는 생각에 후련하게 포기할 수 있을 것 같아 촉박한 시간이지만 Application 안에 있던 메소드들을 객체화 시키는 작업을 시도했습니다.

우선 코드를 수정하기에 앞서 작성하였던 기능목록을 보며 각 메소드들을 어떤식으로 그룹화 할지 고민했습니다. 무작정 클래스를 많이 만들어 객체를 늘린다면 가비지 컬렉터가 있다하더라도 비효율적으로 작동할것이라는 생각에 ‘첫째, 객체들을 참조하는 구조가 최대한 간단할 것 둘째, 기능이 비슷해도 객체 실행 구조를 우선적으로 고려해 메소드들을 배치할 것’ 이라는 기준을 세우고 각 메소드들을 어떤 클래스로 배치할지 기능 목록을 작성했습니다.  기능목록에 따라 코드를 수정한 결과 이전의 불안이 허무할 정도로 쉽게 테스트 케이스를 통과할 수 있었고 절망적인 순간이라 할지라도 끝까지 노력해보는 자세가 중요하다는 교훈을 얻을 수 있었습니다.