도입배경
프로젝트에서 채팅 게임을 만들고 있었다.
채팅에 턴, 시간제한 등 여러 게임요소가 추가되며 다음고 같은 문제점이 발생했다.
- 상태 관리가 복잡해졌다.
- 로직 코드가 길어졌다.
이를 개선하기 위해 Recoil과 Custom Hooks 패턴을 도입하는 리팩토링을 진행했다.
Custom Hooks패턴?
- 기존의 컴포넌트에선 로직과 UI를 한 곳에서 작성한다.
- Custom hooks패턴은 로직을 hooks로 분리하여 관리하는 디자인 패턴이다.
Custom Hooks 패턴과 Recoil을 사용하여 리팩토링
앞서 살펴본 문제점 1. 복잡해진 상태관리, 2. 길어지는 로직코드 이를 개선하기 위해 Recoil과 Custom Hooks 패턴을 도입하여 리팩토링을 진행했다. 이미 부분적으로 프로젝트에 Custom Hooks 패턴을 사용하고 있었지만, 유저 채팅 부분을 리팩토링하며 Custom Hooks 패턴을 엄격하게 적용해보았다.
state는 recoil을 사용하여 분리하고 Socket과 관련된 로직을 제외한 모든 로직은 Hooks로 분리했다. 특정 상태와 로직이 필요한 컴포넌트는 Recoil을 직접 구독하고, Hooks에서 로직을 가져오므로 props drilling은 자연스럽게 해결된다. 또한, 로직을 재사용하여 코드 중복을 줄일 수 있다.
이를 통해 각 컴포넌트는 소켓 관련 로직과 props 그리고 UI만 관리한다. 이렇게 되면 컴포넌트의 책임이 명확해지고, 관리가 쉬워진다. 또한 상태와 로직이 분리되므로, 각 컴포넌트는 그것이 필요로 하는 상태와 로직만을 관리하게 되고 이로 인해 코드의 가독성과 유지보수성이 향상된다.
후기
이번에 채팅게임에 recoil과 엄격한 Custom Hooks패턴을 도입한 리팩토링을 진행하며 디자인 패턴을 좀 더 잘 알게 되었다고 느꼈다.
이전에도 useUserHook을 만들어서 유저 관련 로직을 분리하거나, Custom Hooks 패턴의 원리와 유사한 개념으로 api 폴더를 분리하여 사용하곤 했었다.
하지만 이번에 리팩토링을 진행하여 소켓을 제외한 유저채팅 관련 모든 로직에 Custom Hooks 패턴을 적용하고 Recoil로 전역 상태 관리를 수행하자 컴포넌트의 복잡성이 획기적으로 감소함을 느꼈고, Custom Hooks 패턴의 효용을 좀 더 체감할 수 있었다.
그러나 이번 프로젝트에서 엄격한 Custom Hooks패턴은 유저 채팅 부분에만 도입하였다. 가장 큰 이유는 다른 기능의 경우 복잡성이 그렇게 높지 않아 가독성과 유지보수성이 괜찮다고 생각했기 때문이다.
프론트엔드 디자인 패턴엔 정답이 없고, 패턴의 장단점을 이해하여 적절하게 사용하는 것이 적절하다는 말을 많이 들어 봤는데 이번 리팩토링을 진행하며 확실히 느낄 수 있었다.
