넘블에서 "로그인 모듈 만들기" 이라는 주제로 챌린지를 시작했다.
실무와 가장 근접하게 좋은 코드 작성이 포커스라서 도움이 될것같아서 신청했다.
1회차 챌린지 목표
우선, 1회차는 로그인 관련된 로직을 클래스로 묶어서 프론트엔드에서의 객체지향에 대해 고민해보는 회차이다.
보통 프론트엔드 챌린지는 눈에 보이는 컴포넌트를 만드는게 대부분이라, 모듈설계에 자신이 없었다.
그렇다 보니, 어떤 프로젝트를 해도 비동기 처리하는 부분을 설계할때가 가장 어렵게 느껴졌다ㅠ
그래서 이번 챌린지에서는 인터페이스와 클래스, 메서드를 정의하여 지속가능한 설계를 배워보는 것!이 목표였다.
리액트 컴포넌트 관련 레퍼런스는 많지만, 이런 레퍼런스는 적용하기 어려워서 냉큼 신청함.
그리고 챌린지 종료 후, 상위 참가자에게 코드리뷰를 통해 피드백을 준다고 하는데
내가 되지 않더라고 코드리뷰를 보고 공부할 수 있기 때문에 기대가 된다....
적용하려 노력한 부분(+코드리뷰 후 내용추가예정)
꽤 추상적이어서 막막했다 ㅠㅠ
그래서 챌린지 호스트님이 주신 힌트로 몇가지 컨셉을 익히고 설계했다.
1. SOLID
- AuthService, UserService 클래스의 공통적인 부분 추상화.
- 모듈(파일, 클래스, 메서드 등)이 하나의 역할만 하도록.
- 범용적인 기능 (ex. CRUD)를 추가했을 때, 구조에 문제가 없는지 파악, 개선
이런 힌트를 얻었다.
레퍼런스로 주신 컴포넌트의 응집도 관련 영상도 보고,
프론트엔드에서의 SOILD 원칙 을 찾아보며 공부했다.
내가 한 작업은, 라이브러리(js-cookie, axios)와 강한 의존성을 띄는 부분을 없애기 위해 중개모듈을 추가하여 의존성을 제거하기!
이 부분은 SOLID의 Liskov 역전 원칙을 적용했다.
이렇게 하니, 라이브러리를 사용하는 부분은 중계모듈이 담당하도록 역할을 분리하게 되었다.
자연스럽게 SOLID의 Single Responsibility 원칙이 해결되었다.
그리고 해당 라이브러리는 내가 생각한 Service Layer의 역할인 "서버와 Fetch하는 비동기를 담당"에서 계속 쓰일 것이라고 생각했다.
따라서 Service Layer에서 계속 사용할 부모 클래스를 만들어서 이 라이브러리 중계모듈을 연결해주었다.
부모 클래스를 상속받은 중계모듈을 사용하여, 해당클래스의 역할이 아닌 부분은 역할 위임을 통해 해결했다,
그런데 조금 염려되는 부분은 SOLID의 Interface 분리 원칙에 위배되는 것은 아닐지? 하는 점이다.
쿠키가 사용되지 않는 모듈도 있을 것같아서..
그래서 코드리뷰에서 제일 궁금한 점은 부모모듈을 어떻게 설계하는지 이다.
2. 클래스와 메서드 정적타입, 인터페이스 추가하기
일단, 각 fetch담당하는 함수마다 필요한 파라미터가 다르고 리턴값도 달랐기 떄문에 정의가 필요했다.
컴포넌트에서 필요한 값을 적절히 주고 받기 위해서 함수의 파라미터와 axios 리턴값에 대한 타입정의를 추가했다.
그리고 클래스의 interface를 추가하여, 해당 클래스가 어떤 역할을 하는지 보여주었다.
3. 커스텀 훅 useRequest 제작
useQuery를 사용할 중계모듈이라고 생각하고 제작했다.
컴포넌트에서 직접적으로 리액트 쿼리를 불러오지 않도록, useRequest를 인터페이스로 사용하도록 했다.
아쉬운 점은, 서비스 레이어에 있는 각 메서들을 컴포넌트에서 직접 불러와야 하는 점이다.
useRequest 내에서 미리 불러오는 방식으로 해보려고 했으나, 그럴려면 모드 메서드에 대한 타입을 제네릭으로 지정해주는 방식으로 해야할 것 같다.
확신이 없었고 시간이 부족해서 충분히 고민해보지 못한 것 같다.
이 부분도 코드리뷰에서 궁금한 점 중 하나이다.
사실 객체지향에 대해 잘 모르고, 리액트 쿼리도 익숙치않아서 좋은 코드인지 잘 모르겠다.ㅜㅜ
아마 좋은 코드에 대한 인풋이 많이 부족해서 라고 생각한다.
하지만 이 시간이 없었다면 좋은 코드와 프론트엔드에서의 객체지향에 대해 생각해보지 못했을 것이다.
이 챌린지를 계기로 나의 코드 퀄리티에 대해 반성(...)하게 되었다.
리팩토링과 좋은 설계에 대해 공부하기로 함(인강 결제 완..)
