💡 새롭게 알게 된 점 & 느낀 점

1. MVC 패턴

1주차때는, 한 클래스 내에서 해결할 수 있는 간단한 구현을 여러 클래스와 메소드로 쪼개어 해야 하는지 그 정확한 이유를 알지 못했습니다. 그렇기에 이 때는 클래스를 많이 나누지 않고 제가 해오던 방식과 가깝게 구현을 했습니다.

이번 2주차를 시작하면서, 저번주와는 다르게 MVC 패턴에 한 번 도전해보아야겠다는 생각이 들었습니다. 왜냐하면 1주차에서도 클래스와 메소드를 나누는 과정에서, 조금 혼잡하다는 생각이 들었고 만약 더욱 큰 기능을 구현해야할 때는 그 문제점이 더 커질 것 같았기 때문입니다.

디자인 패턴에 대해서는 들어만 보았기 때문에, 기능 목록을 작성하기 전에 많은 글들을 찾아보았습니다. 하지만 모든 글의 내용이 비슷하면서도 약간 달랐고, 특히 정확히 코드로 예시를 들어 정리된 글은 거의 찾지 못했습니다. 요즘 같은 세상에 이렇게 정보가 정리되어 있지 않다니, 의문점을 품으며 이번에는 유튜브에서 영상을 보기로 결정했습니다.

그리고 그 의문점은 우테코 채널에 있는 10분 테코톡의 영상에서 찾을 수 있었습니다. (링크: https://youtu.be/Yzx-z6kCD2A?si=gT0HWgC5SMr9O_uW)

해당 영상에서는 MVC 패턴에 대한 설명은 오래 하지 않고, 듣는 이에게 질문을 건네며 스스로 생각하게끔 만들었습니다. 그리고 그 끝에서 나온 결론은, MVC 패턴에 정답은 없다는 것이었습니다. 물론 디자인 패턴이기에 많은 사람들이 사용하는 형태는 있겠지만, 그런 것들을 쫓기 보다는 그 본질을 쫓는 것이 옳다는 뜻이었습니다.

MVC 패턴의 본질을 간단히 말하면 모델과 뷰를 분리하여, 유지보수를 용이하게 하기 위함이라고 합니다. 데이터를 모델에서 관리하고, 뷰에서는 그 데이터를 컨트롤러로부터 받아 유저의 요청대로 보여주면서, 서로에게 영향을 주지 않으며 비즈니스 로직을 실행할 수 있습니다.

나름 많은 글과 영상을 찾아보며 감을 잡은 저였지만, 실제로 저의 코드에 적용하려니 참 고민이 많아졌습니다. 대표적인 고민은 다음과 같았습니다.

domain과 service 패키지도 만들어야 하는가? => 첫 도입이기에 model, view, controller만으로 구성하기로 결정했습니다.
사용자의 입력을 받는 곳은 view인가 controller인가? => 가장 많이 고민을 한 부분이었습니다. 결론적으로 저는 이번에 뷰에서 입력 받아 컨트롤러를 통해 모델에 데이터를 만들었습니다. 하지만 웹 페이지의 경우에서는 보통 컨트롤러에서 사용자의 입력을 받는다는 글을 여럿 보았기에, 이 부분은 더욱 알아보아야할 것 같습니다.
model에서는 그저 데이터를 관리하고 변경하기만 하는 것인가? => 모델 패키지에는 컨트롤러와 뷰의 코드가 들어가지 않도록 하는 것이 원칙이라고 합니다. 그렇기 때문에 모델은 데이터를 잘 가지고 있는 것이 가장 중요하다고 생각하여 대부분의 로직은 컨트롤러에서 실행했습니다.

2. 객체지향의 사실과 오해

1주차에 많은 분들의 글들을 보던 중, 객체지향의 사실과 오해라는 책이 많이 언급됨을 알게 되었습니다. 처음에는 별 관심이 없었으나, 원래 알던 사실을 많이 깨부수어주는 좋은 책이라는 리뷰를 보고 조금 관심이 생겼습니다.

2주차부터 스터디들이 열리게 되었는데, 마침 해당 책을 읽고 미션에 적용해보고 서로 코드 리뷰를 진행하는 스터디 또한 열려 들어가게 되었습니다.

이번 주차에는 1,2,3 챕터만을 읽었는데, 우선은 정말 흥미로웠습니다. 이러한 책은 보통 지루하기 마련인데, 이해하기 쉬운 이상한 나라의 앨리스 이야기를 예시로 들며 설명해주어 좋았습니다.

가장 와닿았던 부분은 사실 객체지향은 실세계를 모방하는 것이 아니라, 실세계를 참고하여 새로운 세계를 만드는 것이라는 구절이었습니다.

대부분의 도서에서 객체에 대해 설명을 할 때에는 실세계의 사물 혹은 개념을 모방하여 소프트웨어 세계로 가져온다고 말합니다. 하지만 이는 가장 편리하게 설명할 수 있는 방법일뿐이라 자주 사용되는 것이고, 그로 인해 객체지향에 대한 오해가 생겨나는 것입니다.

실제로 실세계를 모방해서 소프트웨어 세계를 만든다면 상당히 불편한 점들이 많이 생겨납니다. 예를 들어 실세계에서 자동차를 움직이게 하기 위해서는, 다음과 같은 과정이 필요합니다.

차 주인이 자동차 키를 갖고 현관문을 나선다.
자동차에 탑승해 키로 시동을 건다.
엑셀을 밟아 차를 움직인다.

하지만 실제 소프트웨어 세계에서 이렇게 구현하지는 않고, 차 car가 움직인다 move 이런식으로 하나의 메소드로 구현하곤 합니다.

즉, 사물을 의인화하여 더욱 직관적이고 효율적으로 코드를 짜는 것입니다.

이와 같이 기존에 알던 저의 생각을 많이 바꾸어주는 책이기에 재미있게 읽었고, 프리코스가 끝나는 기간까지 읽으며 곱씹을 생각입니다.

3. 테스트 코드

이번 2주차에서 가장 큰 수확은 테스트 코드였던 것 같습니다.

1주차에서는 하나의 기능 혹은 메소드를 구현할 때마다, 메인 메소드에서 직접 값을 넣어 실행해보며 나름의 테스트를 진행했었습니다.

하지만 이렇게 하니 보기가 불편했고, 여러 개의 서로 관련이 없는 테스트가 계속해서 동시에 이루어지는 상황이 발생했습니다.

그래서 이번에는 기존에 있던 테스트 코드에 더하여, utils와 validation 패키지에 있는 메소드들을 검증할 수 있는 테스트 코드를 각각 작성했습니다.

기능 구현을 하고 바로 테스트 코드를 작성해 검증을 하니, 방금 제가 짠 코드가 옳게 된 코드인지 바로 확인할 수 있었습니다. 시간은 조금 더 걸리기는 했지만, 후에 메소드가 잘못되어 전체적으로 수정해야하는 일은 거의 발생하지 않았습니다.

하지만 최종 run 테스트에서 오류가 몇 개 발생하여 디버깅을 진행을 했고, 이 과정에서 테스트 코드와 디자인 패턴의 힘을 알 수 있었습니다. 어느 부분에서 오류가 나는 것인지 바로 파악할 수 있었고, 그 파일이 어느 위치에 있는지 알고 있어 빠른 오류 수정이 가능했습니다.

결국 다음과 같이 테스트 코드를 모두 통과하며 제 시간안에 제출할 수 있었습니다.

4. 시간 부족

소제목 그대로 시간이 많이 부족했습니다.

학업과 아르바이트, 프로젝트 등을 병행하면서 하다 보니 제대로 프리코스에 집중할 수 있는 시간이 며칠 되지 않았습니다. 마감이 다 되어서는 거의 잠도 자지 못해서 솔직한 마음으로 포기해야하나 하는 생각도 들었습니다. 하지만 제출이라도 하자는 생각으로 끝까지 진행을 했고, 결국 모든 테스트를 통과했을 때는 정말 큰 뿌듯함을 느꼈습니다.

하나하나 구현한 작은 기능들이 마지막에 모여 하나의 애플리케이션이 되어 동작할 때는 짜릿한 느낌마저 들었습니다.

보완해야 할 부분도 많고, 시간 부족으로 인해 아쉬운 점도 참 많은 이번주차 미션이었지만, 그래도 결국은 잘 제출을 해냈음에 의의를 두려고 합니다.

3,4 주차는 더욱 난이도가 올라갈 것이기에, 제대로 집중하여 끝낼 수 있는 기간을 개인적으로 설정해 잘 완수해야겠다는 생각이 듭니다.

💡 보완해야 할 점

1. MVC 패턴의 이해 및 숙달

위에서 적은 내용과 같이, 이번 미션에서는 MVC 패턴에 대한 많은 고민이 있었습니다. 모델 뷰 컨트롤러로만 패키지를 구성해 개발하는 것에는 조금 한계가 있음을 느꼈습니다. 그렇기에 왜 많은 사람들이 서비스와 도메인 또한 만들어 사용하는지를 어렴풋이나마 알게 되었습니다.

그렇기에 3주차 미션부터는 MVC에 대한 학습을 더욱 진행하며 도메인과 서비스 패키지를 추가한 구조를 사용해볼까 합니다. 미숙할 수도 있지만, 새로운 것에 도전하는 것만큼 빠르게 성장하는 일은 없다고 생각하여 결정하였습니다.

2. 클래스에 대한 이해

자바는 객체지향언어이고, 여기서 클래스란 빠질 수 없는 부분입니다.

그만큼 중요하고, 현재 읽고 있는 책 덕분에 더욱 많은 흥미를 얻을 수 있었습니다. 매주 진행하는 스터디에서 많은 인사이트를 얻고, 저 또한 함께 공유하기 위해서 정해진 챕터를 읽고 정리하려 합니다.

또한 이번 2주차에서 아쉬웠던 부분에 대해서도 다시 한 번 생각해보며, 클래스에 대한 개념을 조금 더 정립해보려 합니다.

3. 테스트 코드 작성에 대한 이해 및 숙달

이번 미션에서는 하나의 기능이 아니라 메소드를 구현할 때마다 테스트 코드를 작성했고, 메소드는 feat으로, 테스트 코드는 test로 하여 커밋을 두 번씩 하였습니다. 하지만 항상 최대한 잘게 쪼개는 것만이 능사는 아니기에, 어느 정도에서 커밋을 해야 하는지 조금 더 생각이 필요할 것 같습니다.

그리고 포비님께서는 각각이 아니라 둘을 묶어 한 번에 커밋한다고 하니.. 이 부분도 좀 더 알아보아야겠습니다!

테스트 코드 작성이 처음이다 보니, 어떤 기능들이 있는지도 정확히 모르고 어떻게 비교를 해야 하는지도 잘 몰랐습니다. 다음에는 조금 더 좋은 테스트 코드를 짤 수 있도록 노력해야겠습니다.

4. 자바 코드 컨벤션 숙지

1주차부터 자바 컨벤션이라는 것을 알게 되면서, 이것을 왜 해야 하고 얼마나 중요한 것인지를 알게 되었습니다. 그리고 이를 적용하여 코드를 짠다면, 더욱 효율적인 의사소통이 가능해지며, 반대로 하지 않는다면 실력자의 눈에는 쉽게 이것이 티가 날 것입니다.

지키려고 노력은 하였지만, 아직 놓친 부분도 많은 것 같습니다. 자바를 주력으로 사용하는 백엔드 개발자로서 이러한 역량은 피와 살이 되기 때문에, 조금은 번거로워도 손에 익히려고 노력하려 합니다.

5. depth를 얕게 만드는 것에 익숙해지기

1주차에는 없었지만, 2주차부터는 메소드의 depth를 2까지만 허용하였습니다. 그리고 이는 제가 코드를 짜는 데에 많은 걸림돌이었습니다.

제 생각으로는 반복문이 두 번 들어가야 depth가 2라고 생각했지만, 그렇지 않았습니다. 들여쓰기를 기준으로 하는 것으로, 반복문 또는 조건문만 하나라도 사용하면 해당 조건에 맞출 수 없었습니다.

간단한 메소드에는 별 문제가 없었지만, 전체 로직을 진행하는 상황에서는 코드를 쭉 적지 못하니 여러 고민이 생겨났습니다. 결국 시간은 많이 소모되었지만, 왜 이렇게 해야하는지에 대해서는 조금은 알게 된 것 같습니다.

depth를 줄이려고 하다보니 자연스레 작은 기능별로 메소드를 만들게 되었고, 이는 우테코에서 하나의 메소드에서 한 가지 일만 하도록 최대한 작게 만들어라.라는 요청에 부합할 수 있었습니다.

메소드가 많아져 파악하기 힘들 것을 고려해, 더욱 직관적이고 뜻에 맞는 작명을 고민하게 되었고 이 또한 저에게 많은 도움이 된 것 같습니다.

6. HashMap에 대한 이해

2주차 미션에서는 각 자동차의 이동거리를 저장하기 위해서 HashMap을 활용해 구현하였습니다. 자동차의 이름과, 각각의 이동거리를 알아야 했고 변경도 해야 했기에 나름대로 괜찮은 판단이라고 생각했습니다.

하지만 테스트를 돌린 결과, 에러가 발생했습니다. 입력한 자동차들의 이름 순서와, 출력 순서가 다른 것이었습니다.

이는 해시맵은 순서를 고려하지 않는다는 점을 간과한 것이었습니다. 이를 알지 못해서 당황했고, 결국 알아보고 수정하는 데 시간을 더 사용했습니다.

또한 최종 우승자의 이동 거리를 파악하기 위해 고민을 하다가, values 중 최댓값을 바로 반환해주는 메소드를 찾게 되었습니다. 이는 Collections.max 였고, 앞으로 기억해두면 좋을 것 같다는 생각이 들었습니다.

7. 리팩토링에 더 많은 시간 쏟기

대부분의 사람들이 추천하는 것이, 우선 빠르게 만든 후에 리팩토링에 더 많은 시간을 쏟으라는 것이었습니다. 하지만 제 성격상 대충 만들고 다시 수정하는 것이 어려웠고, 결국 구현하는데 생각보다 더 많은 시간을 사용했습니다. 그리고 그 결과 리팩토링을 할 시간과 에너지도 부족하여 제대로 진행하지 못했습니다.

물론 이를 바로 바꾸기는 힘들겠지만, 앞으로도 지금처럼 계속 진행한다면 최종 코테에 가서도 돌아가긴 하는 쓰레기조차 만들지 못할 것 같다는 생각이 듭니다.

8. 설계 및 문서화 속도 증진

위의 내용과 일맥상통합니다. 기능 목록을 자세하게 작성한 것은 좋으나, 시간이 한정된 상황에서는 어느 정도 넘어갈 줄도 알아야 합니다. 하지만 이를 하지 못하여 이번 주차에도 문서화에 많은 시간을 사용하게 되었습니다.

문서화를 아주 꼼꼼히 하고 나니, 기능을 구현하는 데는 위치에 대한 고민도, 작명에 대한 고민도 많이 줄은 것은 분명 장점이었습니다. 하지만 모든 것이 제 머리에서 나온 설계대로 흘러가지는 않았습니다. 결국 코드를 짜며 수정을 계속해서 하게 되었고, 이 또한 많은 시간이 소모되었습니다.

시간이 많은 상황이라면 지금처럼 문서화를 열심히, 그리고 예쁘게 하는 것도 좋다고 생각합니다. 하지만 최종 코테는 5시간만 주어지기에, 지금의 방식보다 더 빠르게 하는 방법을 찾아야할 것 같습니다.

(2주차 깃허브 : https://github.com/bbbang105/java-racingcar-6)