🥨 내가 사용하는 로직 분리
- 중복되는 로직 방지를 위한 커스텀 훅
- 뷰와 비즈니스의 구분이 어려워지고, 코드의 가독성을 위해 시작한 뷰/비즈니스 로직 분리
-> 중복을 줄이고, 긴 코드를 무조건 짧게 만드는 것이 나의 습관(?) 가치관.. 이었다. 그게 좋은 줄 알고 사용해왔던 것이다. 그리고 큰 프로젝트를 진행하던 와중 의문이 생겼다.
🤔 긴 코드보다 분리된 로직을 찾으러 들어가는 게 더 복잡한 과정 아닐까? ...
위 폴더 구조를 보면, 각 컴포넌트마다 훅이 있는데.. 이건 비즈니스 로직을 모두 분리해준 것이다. 중복 로직이 아니고, 재사용성이 없었지만 내 눈엔 코드가 너무 길어보였기 때문에... 따로 빼주었다.
그렇다면, 훅(?)의 내부 코드중 하나를 보자 ! 👀
과연... 이 코드 분리시킬 필요가 있었을까?
뷰와 비즈니스 로직 분리라는 핑계로, 마땅한 이유가 없이 로직을 분리시킨 것 같다.
또한 이렇게 분리해둔 훅을 실제 사용할 때는
{ data, ReportAttachmentInfo, onDrop } = useAddFile(); 이렇게 가져와서 쓰게 되는데, 다른 사람이 이 코드를 볼 때는 useAddFile은 뭐야 ..? 무슨 역할을 하는 것일까... 라고 생각할 것 같다.
심지어 나조차도 시간이 지나면 .. 못 알아볼 수도 ! ^^
다른 훅 파일의 로직들도 거의 다 이렇게 생겼다. 지금 와서 보니까, 굳이 분리해서 찾아가는 불편함을 겪을 필요가 없었던 것 같다.
🟢 결론 (?)
정답이다! 라고 생각하는 로직 분리는 없다.
결국 훅파일을 전부 없애고 다시 비즈니스 로직을 제자리에 넣어줬는데 코드가 긴 기분이라 찝찝하기도 하지만.. 저렇게 냅다 재사용성이 없는 로직들을 빼는 건 좋지 않은 것 같다.
나처럼... 뷰와 비즈니스 로직 분리의 개념에 대해 제대로 알지 못하고 남용하는 사람이 있을까 하고 남기게 되었다! 로직을 무작정 분리하는 건 훅도 아닐뿐더러, 때로는 로직이 길어도 어떤 기능을 하는 지 정확하게 나타내는 코드가 더 나을 수도 있다. 💨
