[우아한 테크코스 5기] 프리코스 마지막 회고록

마지막을 기념하며

우아한테크코스도 벌써 마무리가 되어간다.
가장 크게 느낀점으로는 식상하지만 성장했다라고 할 수 있다.
지금까지는 코드를 적을 때 별생각들이 없었다. 문제나 다른 프로그램을 만들때도 그냥 기능이 성공적으로 동작하는지에만 집중했었다.

하지만, 이제 기능을 구현할 때, 어떤 경우가 있을까? 이렇게 넣으면 괜찮을까? 라고 계속 생각하게 되는 개발자, 아니 무언가를 만들어 내고 제공하는 입장으로서의 성장이 가장 큰 성장이라고 할 수 있다.

개발자로서의 성장도 물론 4주동안 많이 성장했다고 생각을 한다.
기존에는 클래스라는 개념을 배웠을 때 Capsulation에 대해서 getter, setter만 알았다.
캡슐화를 하기 위해서는 단지, 맴버변수만 private하게 선언을 하고, getter, setter를 기계적으로 넣을 뿐, 왜 그렇게 사용하지? 라는 생각이 부족했다.

일급 컬렉션 등을 알게 되면서 지금까지 작성했던 내 코드는 말도 안되는 것이라는 것을 알게 되었다.
final을 통해서 불변하게 하고, getter를 쓸때도 불변이라는 것을 지켜서 원하는 그냥 값 자체만 넘겨주고 하는것들을 통해서 이것이 제대로된 캡슐화구나 라는 것을 알게 되었다.

이뿐 만이 아니다. TDD를 지켜야한다, Refactoring을 읽어야한다., 등등의 말들이 나에게는 "그래 그냥 좋은거지, 나중에 회사가서 그 때부터 지키면 되는거지"등의 안좋은 생각만 가지고 있었다.

많이 말해서 알겠는데 왜 좋은 건지에 대해서는 이번 프리코스에서 많이 느꼈던 것 같다.
테스트 코드를 작성하고 나니 리팩토링과 내 코드에 대한 자신감이 많이 생겨나게 되었다.
그리고 Refactoring을 하고 나서 코드를 읽는게 쉬워지게 되었다.

코딩을 해봤으면 사실 누구나 느꼈을 것이다. 내가 짠코드를 사실 하루만 되도 이해하기 어렵다는 사실을
이런 점들이 해소가 되었다. 코드를 좀 더 잘보이도록 수정할 수 있게 하면서 작성하니까 코드에 대한 이해가 늘어서 금방금방 적응할 수 있었다.

마지막으로 Enum을 왜 이제 알았지? 라는 생각이 들었다.
Enum만큼 좋은 것이 없다고 느낄때가 많아졌다.

매일 매일 내 코드는 하드 코딩이었다. 그러다보니 값을 동시에 바꿀때도 힘들었고 이런일도 있었다.

매도/매수를 각 0, 1의 값에 매핑을 해서 저장을 하였는데, 코드를 볼때마다. 매도가 0이었나? 매수가 0이었나...
하면서, 항상 IA를 뒤져보곤했다.

불편함을 느끼면서도 방법을 몰랐었다. 상수라는 개념을 쓰고나니 되게 편해졌고, 이런 상수를 Enum에서는 상태까지 관리할 수 있다는것이 말도안되게 편하다는 것이 눈앞에 다가왔었다.

이번 프리코스는 사실, 학기중이라는 부담감과 여러가지 할일들에 의해서 바쁜 와중이었다.
하지만, 프리코스를 할 때는 그것들을 잊고 코딩에 몰입할 수 있어서 너무 행복했다.
하루종일 해도 지치지 않고 시간가는줄 모르고 했던적이 한두번이 아니며, 코드작성의 묘미를 느낄 수 있었다.

이런 프리코스를 공짜로 경험한다는것이 행복했었다. 하지만, 이제 프리코스도 마무리할 시간이 다가왔다.
많이 배웠으니까 어느정도 어떤식으로 공부를 해야하는지 감도 잡은것 같다. 더 하고 싶지만, 어떻게 될지는 잘 모르겠다.

4차 다리 건너기 게임

이번 다리 건너기 게임에서는 클래스 분리에 대해서 많은 노력을 무엇보다 들였었다.
사실 좌충우돌 여러가지 사건들이 있었다. 하나하나 적으면서 생각해보려한다.

기능 요구사항은 항상 꼼꼼히

첫 번째는 '기능 요구 사항을 꼼꼼히 읽자'다 이번에 기능 요구사항 중에서 이런 항목이 존재했다.

기능 요구 사항

사실 이번에는 실수 하지 않도록 하기 위해서 CheckList를 다음과 같이 작성을 하였지만 이 부분을 주의깊게 보지 않았다.

Check-List

그래서 인지... BridgeGame을 Controller로 생각하고 기능을 짜기 시작했다.
이후 제출 전날에 알아서 급하게 부랴부랴 리팩토링을 했던 기억이 있다.

하지만, 코수타에서도 말했듯이 미리 테스트 코드를 단단하게 짜놨기 때문에 이 부분에 대해서 그래도 편하게 리팩토링을 하는 경험을 했던 것 같다.

이전 3차에서도 이런 경험을 하였는데, 계속 경험할 수록 테스트 코드는 그저 신이야... 라고 생각을 하게되었다.

MVC 패턴

이번에는 특히나 클래스의 분리에 대해서 많이 생각했던 주차였던 것 같다.
그러면 도대체 어떤식으로 클래스를 분리하면 좋을까? 라는 생각이 들어서 찾아보게 되었다.
항상 이런 생각은 나 뿐만이 하는것이 아니라 대가 들이 이미 정리해둔 개념들이 있기 때문에 쉽게 찾을 수 있었다.

그 중 선택했던 것은 MVC 패턴이다. Spring을 배웠다면, 누구나 익숙한 패턴으로 볼 수 있다.
각각 Model, View, Controller로 나눠서 각각의 의존도를 낮추고 객체지향의 사실과 오해에서 말했던 메세지를 통해서 어떤한 결과를 받을 수 있는 좋은 패턴이라고 볼 수 있다.

그렇기 때문에 적용하려고했는데 사실 막막했었다. 그리고 공부를 하면서 많이 반성을 했던것 같다.
기존 MVC 모델을 너무 대충 아뭐... 클라이언트 요청이 들어오면 대충 Controller에서 처리하고... Model에서 그냥 서비스로직 다 떄려박고... 이러한 생각으로 그냥 기계처럼 짜왔던것 같다.

근데 이제 클라이언트에 응답을 받는것을 내가 어떻게 할지 정했어야했고 대충 MVC에 대해서 이해하고 기계적으로 코드를 짜왔기 때문에 작성하는데 많이 어려움을 느꼈었던것 같다.

Model에 이 기능을 넣어야하나? Controller에 이러한 메서드가 들어가는게 맞나? 라는 고민들이 코드를 짤때마다 많았던것 같다. 그렇기 때문에 좀더 깊숙히 공부할 수 있었고
클래스 분리에 따라서 많은 필요없는 코드들이 각각 정리 될 수 있었다.

Enum

저번 Enum도입때 Enum이 너무 좋았기 때문에 이번에도 Enum을 가차없이 도입하기로 하였다.
총 3개를 넣을 수 있었는데 BridgeCommand, BridgeState, GameState 총 3개로 나눠서 관리를 했는데 상태와 여러가지 변수를 한번에 넣을 수 있다는 장점으로 여러코드에서 많이 사용할 수 있었던 것같다.

이중에서 뭔가 겹치는거는 합치거나 굳이 Enum을 써야 했을까...? 라는것도 있었지만 내 주관에는 필요하다고 해서 막무가내로 생성하고 밀어붙였던 것같다.
그래서 리팩토링에 대해서 Enum은 특히 생각을 많이 했지만 더 좋은 방법이 생각나지 않은 점이 아쉬웠다.

이제 진짜 끝

계속 느끼는 것이 아쉽다... 프리코스가 1년짜리였으면 좋겠다... 라는 생각을 많이한다.

하지만, 생각하는 방법도 알고 공부를 어떻게 해나가야하는지 감을 잡았던것같다.
그리고 더욱 성장하는 개발자가 될 수 있도록 불씨를 집어넣어준것 같았다.

이 불씨가 꺼지지 않도록 계속해서 노력해서 좋은 개발자가 되도록 노력하려고 한다.
이런 성장할 수 있는 기회를 준 코치님들께 감사의 인사를 전하려고 한다.
그리고 같이 성장하고 지식공유를 지속적으로 해준 프리코스를 함께했던 분들께도 감사의 인사를 남기려고한다.

감사합니다😀