조금 늦게 써보는 회고글이다. 3주차는 배운점 느낀점이 정말 많았던 한주였다. 그래서 회고를 좀 구구절절 써볼까한다.
배운점과 노력한점
MVC 패턴의 적용 지난 2주차 과제를 하면서 입출력을 하는 로직을 메인함수에 썼다가 지저분해지는 것 같아 클래스 내의 메소드로 만들었었다. 그런데 하면서 입출력에 대한 코드를 분리하면 더 좋았겠다는 아쉬움이 남았다. 또한 메소드를 이어주는 중간단계 코드를 작성하는 부분도 클래스 내부에 써야 하는지 메인함수에 써야 하는지 혼동이 되었고, 결국은 메인함수에 쓰긴 했지만 가독성이 떨어지는 문제가 있어서 아쉬움이 있었다.
그리고 나서 2주차 코드리뷰를 통해 내가 고민하고 있던 부분인 핵심 로직과 입출력 부분의 코드를 분리해서 작성하는 MVC패턴을 접했다. 그래서 이게 해답이라는 생각이 들었다. 나랑 비슷한 생각을 한 사람들이 있어서 이런 디자인 패턴이 만들어졌을테니 역시 사람들은 비슷한 생각을 하는가보다. 게다가 이번 3주차 과제 요구사항 중 '핵심 로직을 구현하는 코드와 UI를 담당하는 로직을 구분한다’ 라는 부분을 보고 이 기능을 잘 수행할 수 있는 MVC 패턴을 적용해볼 필요성을 느껴 도입하게 되었다. 또 이번 과제는 입출력이 많았기 때문에 입출력 로직이 독립적으로 수행하는 것이 여러모로 좋을 것 같았다.
하지만 MVC패턴의 도입은 쉽지 않았다. 구글링을 통해 접한 자료들은 Model, View, Controller 의 역할을 조금씩 다르게 정의하고 있었고 이것을 확장시킨 패턴도 존재하여 혼란스러웠다. 그래서 본래 내가 사용하고자 했던 목적인 MVC 패턴의 로직 분리에만 신경 써서 모델은 변수와, 변수가 변경될 때 처리할 방법에 대한 내용을 ,뷰에 입출력 함수를, 컨트롤러에 모델과 뷰를 가지고 흐름 제어를 수행하겠다는 명확한 설정을 잡고 시작하니 수월하게 코드를 작성할 수 있었다. 결과적으로 내가 고민하던 중간 단계 코드를 컨트롤러에서 효과적으로 제어할 수 있어 좋았다.
무작정 모든 객체를 클래스로 만들기보다는 필요하다면 일반 객체로도 사용해보기로 했다. 특히 뷰의 로직은 다양한 입력을 받기 때문에 클래스보다는 일반 객체로 만드는 것이 더욱 적절할 것이라 판단하였고, 컨트롤러에 값을 저장하면 안된다는 원칙 또한 있었기 때문에 뷰 로직에 대한 인스턴트 생성을 막기 위해서 일반 객체로 사용했다.
효율적인 자료구조를 사용하는 것을 고민해보았다. 당첨 통계를 어떻게 효율적으로 저장하고, 보여줄 수 있을지 고민하였다. 우선 3개당첨부터 순차적으로 출력해야하니 순서가 있는 자료구조가 필요했고 출력할 키를 조회하면 값이 바로 나오게 하고싶었다. 한마디로 키-값 쌍이 있는 자료구조가 필요했다. 따라서 map 을 활용하여 코드를 간결하게 만들었고 효율적으로 값을 조회할 수 있도록 만들었다.
지난 2주차 피드백으로 하나의 함수에는 한가지 일만 하도록 한다는 것을 보고 이번에 더욱 함수분리에 신경을 썼다.
아쉬웠던점
테스트 코드를 중간중간 작성하지 않았다. 원래는 기능 하나를 만들때마다 테스트코드를 만드는게 맞고, 더 좋은 건 테스트 코드를 먼저 작성하는 것이다. 그게 TDD개념이 되는 것이다. 프리코스를 하면서 TDD 시도해볼까 했지만 나한테는 테스트코드를 제대로 작성하는 것만 해도 성장이라고 생각했기 때문에 시도하지 않았다.
그런데 그게 이번주차 실패의 원인이 되었다 ^^..
구현을 제출 마지막날 저녁즈음에 마무리해서 그때부터 테스트코드를 작성하기 시작했는데 알고보니 테스트코드 샘플에 맞추려면 구현 코드를 일부 수정해야 했다. 그래서 부랴부랴 수정하는데 시간이 없어 결국 제대로 실행되지 않는 코드로 제출해버렸다. 해당 기능에 대해서 테스트코드를 바로 작성했었다면 이런 일이 없었을 거라 생각하니 참 후회가 되었다.
OutputView 객체가 데이터를 의존하게 만들었다. 원래 View는 데이터에 대해서 아예 모르는 것이 정상인데 내가 데이터를 주입해주기보다는 View객체 안에서 하드코딩한 부분도 있었다.
느낀점
이번 주차는 새로운 기술을 도입하려다보니 MVC패턴에 대해 많이 공부하고 이전 기수분들의 글이랑 코드도 많이 참고했다. 그러면서 벽을 느꼈던 것 같다. 아.. 대체 뭔말이지.. 싶다가 새로운 기술을 빨리빨리 적응한 걸 보면서 놀랍기도 했다.
그리고 무엇보다 회고를 기술 위주로 엄청 자세하게 작성한 걸 보면서 감탄했다. 참 실력있는 사람들이 많은듯..
그래서 이번에는 나도 기술에 대한 부분을 좀 써봤다.
그리고 4주차 메일은 받았지만 이번주에 거의 실패나 다름없는 결과물을 만들어내서 너무 슬펐다. 제출마감 두시간전까지만 해도 잘만 돌아가던 내 소중한 코드들이었는데 테스트코드 때문에 돌아가지도 않는 쓰레기가 되어버려서 슬프고 아쉬웠다. 다음날 아침에 학교 가는데 좀 눈물났다. 어쩌면 뽑힐 수도 있다는 행복회로를 돌렸었나보다. 근데 이렇게 회고를 해보니 내 탓이었던 것이 커서 이젠 아쉬운게 좀 덜하다.
이걸 계기로 TDD를 이제 해보면 되는 것이다.
그리고 처음엔 어려웠지만 과제 하면서 MVC패턴도 감을 잡고 꽤 원칙대로 잘 구현한 것 같아서 뿌듯하기도 하다. 프리코스 아니었으면 이런게 있는줄도 몰랐을 것이다.
이번 주차는 망했기 때문에 뽑힐 가능성은 0에 가까운 것 같아서 4주차 메일을 받고 마지막 남은 과제를 할까말까 고민했다. 근데 나는 또 준비하고 있는 코딩테스트가 있으니 그걸 하는 편이 나을 것 같다. 만약 코딩테스트가 없었다면 했을 것이다. 이 과제가 분명히 또 엄청난 성장을 줄 것은 분명하니까 말이다. 그리고 또 주제도 재밌어보인다.
그래도 이 짧은 기간동안 진짜 몰입하고 성장했다. 나에게 클린코드에 대한 시야를 넓여주었으니 정말 감사한 일이다.
