이전 블로그에서 컴포넌트 하나를 어떻게 구성하는지 다뤘다. 뷰와 비즈니스 로직을 분리했다. what, how 키워드를 기준으로 what은 컴포넌트에 남기고 how는 분리하는 컴포넌트를 만들었다.

진정한 colocation

하지만.. 근본적으로 컴포넌트 하나를 바꿨다고 내 프로젝트 전체가 내가 원하는 방향으로 바뀌는 것은 아니다. 진정한 colocation은 hooks, utils, types까지 하나의 폴더에 존재해야 진정한 coloation이라고 생각한다.

왜냐? 일단 아주 유명한 개발자가 그렇게 얘기했기 때문에 믿을 수 있는 점과, 하나의 폴더 내에 필요한 파일들이 전부 존재하기 때문에 처음 코드를 접하는 사람도 쉽게 수정이 가능해 지기 때문이다.

그래서 src/hooks, src/types, src/utils에 있던 파일들을 내 components/modules/auth/hooks, types, utils에 위치시켜 해당 파일들은 auth에서 사용하는 파일들, todo에서 사용하는 파일들을 전부 분리했다.

프로젝트 트리를 보자!

modules
│       ├── auth
│       │   ├── api
│       │   │   └── api.ts
│       │   ├── hooks
│       │   │   └── useAuthSubmit.tsx
│       │   ├── login
│       │   │   └── Login.tsx
│       │   ├── signUp
│       │   │   └── SignUp.tsx
│       │   ├── types
│       │   │   └── index.ts
│       │   └── utils
│       │       └── validation.ts
│       └── todo
│           ├── Todo.tsx
│           ├── api
│           │   └── api.ts
│           ├── hooks
│           │   ├── useGetTodo.tsx
│           │   └── useInput.tsx
│           ├── todoAdd
│           │   ├── TodoAdd.tsx
│           │   └── hooks
│           │       └── usePostTodo.tsx
│           ├── todoDetail
│           │   ├── TodoDetail.tsx
│           │   └── hooks
│           │       ├── useDelTodo.tsx
│           │       └── useGetTodos.tsx
│           ├── todoEdit
│           │   ├── TodoEdit.tsx
│           │   └── hooks
│           │       └── usePutTodo.tsx
│           ├── todoList
│           │   └── TodoList.tsx
│           ├── types
│           │   └── index.ts
│           └── utils
│               └── debounce.ts

아 추가적으로 api까지 필요한 modules에 정의해서 src/api에 있던 호출 함수들을 필요한 폴더에 위치시켰다.

자칫 폴더 마다 hooks 폴더, types 폴더가 있어 복잡해 보일 수 있겠지만, 해당 기능 하나를 볼 때는 전혀 불편하지 않았다. 오히려 한 곳에 모아두고 관리할 때보다 직관적으로 구조를 알 수 있어 훨씬 좋아졌다.

아토믹도?

그렇다면 사실 아토믹 구조의 폴더를 만들 때도 src/components/atoms, src/components/moculeres, src/components/organics로 나누는 것이 아니라, 해당 기능 별로 아토믹 구조를 따로 만드는 것이 더 직관적이지 않을까 생각이 들었다.

프로젝트를 진행하면서 아토믹 구조를 적용했었는데 하나의 아톰 컴포넌트로 여러 곳의 서로 다른 ui를 가진 컴포넌트로 만드는 것은 굉장히 힘든 일이다. 그리고 그렇게 구성한다면 아톰 컴포넌트가 너무 지저분 해지기 때문에 다른 버튼이라면 다르게 정의해 주는 것이 맞다고 생각한다. 아닐 수도 있지만 내 경험은 그렇다.. 하나의 컴포넌트에서 여러 ui를 제작하려 하다보니 엄청나게 머리가 아팠었다. (원래 아픈 것..?)

이에 대해서는 아토믹 디자인에 대해 더 공부를 해봐야겠다.

클린코드는 멀고 멀었다.

이제 겨우 todo 리스트 만들기의 폴더 구조를 잡고, 가장 베이직한 로직을 분리시키는 연습을 했다.

나는 그동안 프로젝트를 하면서 무엇을 고민했을까. 분명 좋은 코드를 짜기 위해 이것저것 봤는데, 그 이것저것이 무엇이었을까. 내가 집중했던 것은 무엇일까.

일단 디자인 패턴을 적용했고, 관심사 분리를 목적으로 전부 다 분리해서 한 곳에 넣었던 것... 그 때는 무슨 생각이었을까 떠올리면, 나름 나만의 논리가 있었다.. 그리고 현업에 있는 코치님의 도움도 있었다. 보통 따로 분리한다고 하니 의심없이 전부 분리!를 외치며 모든 것들을 분리했다.

왜 나는 검증과정을 거치지 않았을까? 이게 진짜 올바른 것인가? 깊게 고민했다면 아닐 수도 있겠는데?를 생각하지 않았을까?

하지만 이제 학습하는 방법을 알았다. 세상에는 정말 좋은 자료들이 많았다. velog, tstory만 아는 세상과 구글을 아는 세상은 정말 달랐다. 정말 좋은 자료들을 만들기 위해 많은 사람들이 노력하고 있다는 것을 이제는 완전히 알게 되었다. 그래서 하나씩 쭉쭉 읽어나갈 예정이다.

읽는다고 해결될 일은 아니다. 읽고 적용하고를 반복해야 그것이 내 것이 되고, 이렇게 블로그에 정리하면 진짜 내 것이 되지 않을까..?

후 개발자 되는 일이 저엉말 어렵도다..!