[ 학습 목표 ]
- Github 기반으로 온라인
코드 리뷰코딩 컨벤션을 준수하며 개발단위 테스트를 작성하며 개발함수(또는 메서드)를 분리하는 리팩터링
💭 TMI
레벨 1 첫 미션이 마무리가 되었다. 기능 요구 사항, 프로그래밍 요구사항, 과제 진행 요구사항을 참고하여 문제를 해결하였다. 문제와는 별개로 한가지 고민이 있었다.
좋은 코드란 무엇인가?
원래는 가독성이 좋은 코드의 유일한 기준이였고, 일단 잘 읽혀야 좋은 코드라고 느껴졌다. 미션을 진행하면서 코드리뷰를 받아보는 경험 또는 도메인 로직을 위한 단위 테스트를 작성하는 경험 은 이번이 처음이다. 팀프로젝트를 진행하면서 코드 품질을 신경쓰는 건 쉽지 않다. 내 생각엔 쉽지 않은 정도가 아니라 불가능에 가깝다. 습관적으로 작성하는 코드가 대부분이고, 기능에 문제가 없다면 딱히 개선할 생각이 들지 않는다. 하지만 미션을 진행하면서 그전에 공부했던 흐름과 다르다는 것을 느꼈다.
📘 배운점 & 느낀점
기능 구현하기 바쁜 것이 아닌, 비교적 간단한 문제에 대해 설계를 고민하며 문제 해결방법을 배우고 있다. 어떤 역할을 할 지, 여러가지 역할을 하고 있지는 않은 지, UI로직과 도메인 로직이 분리가 되었는 지 등 페어 프로그래밍을 진행하며 한줄한줄 코드의 이유를 만들어간다.
1단계 미션을 진행하면서 좋은 코드의 새로운 기준이 생겼다. 테스트 하기 쉬운 코드 인데, 테스트하기 쉬울수록 가독성있고 확장성 있는 코드가 되는 것 같다. 제어할 수 없는 값들을 외부에서 주입하여 테스트하기 어려운 코드를 분리해낼 수 있다. 이를 통해 테스트하기 쉬운 코드를 분리시키고 불필요한 의존성도 줄어든다. 이러한 장점이 있는데, 1단계 미션에서 가장 크게 느낀 부분을 2가지 키워드로 설명하고 싶다.
✅ controller
프리코스 때부터 많은 PR에 MVC 패턴이 도입된 것을 확인했지만 필요성을 느끼지 못해 도입하지 않았다. 하지만 UI 로직과 도메인 로직을 완전히 분리하고, 테스트하기 쉬운 코드를 만드려고 노력하다보니 UI 로직(view)과 데이터(model)을 연결시켜주는 역할이 필요했다. 이에 controller를 도입하여 view와 model의 상태변경를 감지하고, 그에 따라 처리하는 역할을 위임하였다. 또한 도메인 모델 쪽의 테스트하기 어려운 부분을 분리하여 순수한 도메인 로직만을 포함할 수 있게 되었다. 디자인 패턴을 적용했다라기보단 controller의 역할과 필요성에 대해 좀더 이해하게 되었다.
✅ jest
처음에는 현재 위치와 우승자를 출력 하는 게 핵심 로직이라고 생각하여, console.log를 모킹하여 단위테스트를 진행하였다. 하지만 jest.fn을 사용하지 말라는 요구사항이 추가되었고, 이를 함수를 모킹하지 않고 테스트하기 좋은 코드에 대해 고민해봐라 로 이해하였다. 테스트하기 어려운 랜덤값을 테스트하려면 메소드의 인자로 값을 넘겨야 했다. 그걸 고려하여 코드를 구현했더니 자연스럽게 해당 코드는 테스트하기 쉬워지고, 이것을 의존하는 상위계층의 테스트만 어려워졌다. 이런식으로 가장 바깥(controller)으로 테스트하기 어려운 부분을 밀어내는 것이 테스트하기 쉬운 코드로 만드는 방법 중 하나라고 한다. jest에 좀더 익숙해졌고, 단위테스트의 목적과 용도에 대해 이해하게 되었다.
