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

3주차는 숫자야구게임이 미션이었다. 혹시 내가 작성한 코드를 보고 싶다면 아래 링크로 들어가서 Maker-H 브랜치를 확인하면 된다. (MVC 패턴이 뭔지, 객체지향이 뭔지도 모를 때라서 완전 절차지향적으로 짠 코드ㅎ)

 

Maker-H/java-baseball: 숫자 야구 게임 미션을 진행하는 저장소 (github.com)

 

3주차 회고는 2주차때 너무 우울하다 소리를 많이 한 것 같아서 '나 이것도 공부했고, 저것도 공부했다? 그러니까 좋게 봐주라~ㅎㅎ'의 요지로 회고를 작성했었다. 이때 '내가 생각하는 리팩토링은 어떤 것이다'를 작성했었는데 지금 다시 보니까 음 말도 안되는 소리를 적어놨네 싶다ㅋㅋㅋㅋㅋ

 

모든 배움은 고등어를 이건 포유류인가? -> 오 포유류 중에 개과인거 같은데 -> 헐 이거 아니네 완전 독수리네 -> 다시보니.. 물고기인듯; 의 과정을 거친다고 생각하기에 좋게 봐줬으면ㅠㅠ

 

 

긴 글 읽기 싫은 분을 위한 세 줄 요약

1. enum, stream, 테스트 케이스 문법 공부했다

2. 리팩토링도 했었다.

3. 좋은 코드 짜려고 노력하고 있다. 좋게 봐달라.

-끝-

 

 

💡 2주차 과제를 하며 테스트 케이스 작성을 잘하고 싶다는 욕심이 생긴 와중 좋은 학습 자료를 올려주셔서 JUnit 학습하기에 있는 링크들을 꼼꼼히 살펴보았습니다.  그 중 JUnit Parameter 문서의 @enum source 부분을 읽고 enum 클래스에 흥미를 느꼈습니다. 자바 교재에서는 짧게 언급되고 지나가길래 enum이라는 기능이 왜 존재하는지 모르고 막연하게 학습하고 지나갔는데 @enum source 부분을 읽으며 2주차 피드백에서 하드코딩을 지양하라는 것을 enum으로 구현할 수 있겠다는 생각이 들어 자료를 좀 더 찾아보았습니다.

하지만 enum 사용에 대한 글들을 읽으니 제가 모르는 stream이라는 문법이 적용되어 있었기에 stream을 공부하여야 겠다는 생각이 들었습니다. 뿐만 아니라 조금더 살펴보니 JUnit 문서에서 @method source 부분부터도 stream 문법이 적용되어 있었기에 stream 문법을 필수적으로 알아야 한다는 생각이 들어 ‘스트림 문법 공부 -> 테스트 문법 정리 -> enum 사용법 정리-> 과제 시작’의 계획을 세웠습니다.

생각보다 분량이 많아 수요일부터 토요일까지 stream 공부, 테스트 케이스 문법 정리와 enum 조사를 했고 기능구현은 일요일에, 리팩토링은 월요일에 완료할 수 있었습니다. 밥 먹는 시간을 제외하고 일요일 하루를 온종일 기능구현에만 매달렸기에 기능구현을 마친다면 단번에 테스트 케이스를 통과할 것이라고 생각했는데 이번에도 시간 초과로 통과하지 못하는 예외가 발생하였습니다. 완성을 했는데도 통과하지 못해 제가 프로그래밍이라는 분야에 재능이 없는건가 하고 좌절할뻔 했지만 다른 분들의 회고를 찾아 읽으며 리팩토링이 필수적인 과정이라는 것, 제가 단번에 테스트 케이스를 통과하려고 한 것이 저의 욕심이라는 것을 알게 되었습니다.

저는 이번주에 처음으로 리팩토링을 해본 것 같습니다. 이제까진 리팩토링이 ‘코드를 유지보수 하는 과정’이라고만 막연히 생각하고 있었고 커밋 컨벤션에 refactor이라는 칸이 따로 있길래 이건 내가 사용할 일은 없는 단어겠네 하고 넘어갔었습니다. 하지만 월요일 하루를 온종일 리팩토링에 매달려보니 리팩토링은 ‘덜어내는 과정’이라는 나름의 생각을 정립할 수 있게 되었습니다. 무거운 메소드들을 가볍게 세분화 시키고 반복되는 코드들을 모아 하나의 코드로 모아 ‘코드의 로직을 직관적으로 만들고 중복되는 코드들을 덜어내는 과정’ 즉 리팩토링을 경험함으로써 이제야 리팩토링이 무엇인지 그리고 왜 필요한지 알게 되었습니다.

이번주는 정신적인 성장에 집중하는 한 주 였습니다. 항상 데드라인이 있다면 ‘만약’을 해결할 수 있는 충분한 시간을 놓고 그 전에 일을 마치려고 합니다. 우아한 테크코스를 하며 부족함을 많이 느꼈기에 저 스스로 여유시간을 하루로 정했었습니다. 그래서 수,목,금요일을 자료를 찾고 공부할 수 있는 준비 기간으로 놓고 토,일요일에 기능구현을 하여 월요일에 완성, 변수가 생겨도 화요일에는 제출을 할 수 있도록 계획했습니다. 그런데 그럼에도 불구하고 저는 항상 시간이 쫓기는 기분이 들었습니다. 햇볕을 본게 언제인지 기억이 잘 나지 않고, 잠을 자도 불안해서 제대로 잘 수가 없었습니다. 합격에 연연하진 않았지만 뒤쳐진다는 느낌에 4주차 과제라는 목표를 정해놓고 그때까지만 고생하자며 끊임없이 스스로를 몰아붙였던 것 같습니다.

하지만 3주차에 접어들며 지난 시간을 되돌아보니 내 실력이 어떻든 간에 지난 2주를 정말 후회 없이, 열심히 달렸다는 기분이 들었습니다. 만약 불합격한다 해도 정말 최선을 다했기에 한 점의 후회없이 좋은 승부였다!고 얘기할 수 있을 것 같았습니다. 그래서 앞서나가고 뒤쳐지는 것이 더이상 문제가 되지 않았습니다. 포비의 말처럼 나는 나만의 길을 간다는 것이 뭔지 어렴풋이 알게 되었습니다.

그리고 스스로에 대한 믿음이 부족하다는 것을 깨달았습니다. 1주차, 2주차 문제를 보고 솔직히 다 해볼만 하다는 생각이 들었습니다. 문제 풀이 기간을 이틀로 잡은 것도, 문제를 풀기 전 문제와 상관없을 수도 없는 문서들이나 문법을 먼저 익힌 것도 문제를 읽으니 대략적으로 어떻게 구현하면 되겠다는 전개도가 그려졌기에 충분히 해결할 수 있겠다는 자신감이 들어서였습니다. 그렇게 생각하니 스스로를 그만 재촉하자는 생각이 들었습니다. 우테코를 하며 처음 알게 된 테스트 주도 개발, 클린코드 지향 등 새로운 개념들을 얻어갈 수 있음에 감사하며 조금 더 과제를 즐겨보자는 생각이 들었습니다. 어떠한 상황이라도 시간 내에 해결할 수 있다는 믿음이 있다면 불안할 이유가 없다는 것을 깨달았고 실제로 이번 주는 저에 대한 믿음이 강해졌기에 과제에 쫓기기 보다 과제를 잡으러 가는 1주일일 수 있었습니다.

또 구현에 자신감이 생김에 따라 이제는 구현 자체보다는 ‘무엇이 좋은 코드인가’에 대한 생각을 해보게 되었습니다. 이번 과제를 진행하며 클래스들을 많이 만들었는데 무작정 클래스를 만들다가도 클래스 안의 필드들은 어떻게 선언해야 하는지, 왜 메소드 안 지역변수가 아니고 필드로 선언을 해야 하는지, private으로 선언하고 getter와 setter을 만드는 이유가 뭔지 등 어떤 코드가 좋은 코드인지에 대한 의문이 생겼습니다. 또한 리팩토링을 하며 어떤식으로 설계를 해야 최고의 효율을 낼 수 있는지가 궁금해져 자바라는 언어 자체에 대한 궁금증이 많이 생겼습니다. 그래서 우선 무엇이 좋은 코드인가에 대한 의문을 해소해보기 위해 지난 유튜브 라이브에서 추천해주셨던 객체지향의 사실과 오해라는 책을 읽어보고 있습니다. 다음주차에서는 객체라는 개념을 제대로 사용해보고 싶다는 생각이 듭니다.