[하루 한 시간] FSD 적용 소감

• 회사 프로젝트 하나에 FSD 아키텍처를 도입해보았다.
• 최대한 다른 것들은 건드리지않고, 폴더구조만 변경하려 했다.
• ai에게 FSD로 아키텍처를 변경하면 좋은점에 대해 키워드를 달라고했고 거기에 대한 생각을 적어봤다.

1. 명확한 책임 분리 - 컴포넌트가 어느 레이어에 속하는지 고민하면서 자연스럽게 역할이 명확해짐

• 컴포넌트가 어떤 레이어에 속해야하는지 고민해보면서, 어? 이게 잘못된 위치네? 또는 이게 더 명확한 컴포넌트 이름이 되겠다 싶은 부분을 발견할 수 있었다.
• 또는 하나의 Context(나는 상태관리로 React Context를 사용하고 있다.)로 묶어 관리하던거 2개로 분리해야 되겠다고 납득되었던 적이 있다.

2. 예측 가능한 파일 위치 - "이 코드 어디있지?" 찾는 시간 줄어듦

• 2번은 내가 판단할 수 있는 부분이 아니라 애매하다.
• 내가 보기엔 꽤나 나아진거 같은데, 당연히 나는 직접 리팩토링을 한 당사자니 그렇고
• 팀원들에게 보여줬을 땐, 좋아진거 같다곤 하는데 그들이 직접 코드를 봐야하는 상황이 될때까지 진짜 피드백은 받기 어려울 것 같다.

3. 리팩토링 방향성 확보 - shared 에서 위 레이어로 올리는 경로

• 요거는 이전에 Atomic패턴이였나? 했을 때 보다 훨씬 명확해서 좋았다.
• 일단 pages와 shared에 넣고, pages에서 덩어리들을 widgets로 분리하면 된다.
• 그리고 서로 다른 widgets에서 공유해야하고, 왠지 도메인.. 스럽거나 행동..스러운 것들은 일단 features와 entities에 넣었다. (ai에게 물어가며 했지만 애매했다.)
• 애매하다고 생각하는 부분은 따로 뒤에 적겠다.

4. 비즈니스 로직 집중화 - shared는 순수유틸만, 도메인 로직은 상위 레이어로 올라가면서 코드 의도가 명확해짐

• 이것도 어느정도 맞는거 같다.
• 특히 shared에 존재하는 것들은 어떤 유형의 도메인에도 얽히지 않고, 전역에 존재해야하는게 너무나도 명확한 친구들만 남게 되었다.
• 이건 정말 처음오는 사람이 봐도 아 이거는 전역으로 사용하구나를 한 눈에 알 수 있을 거 같았다.
• 하지만 widgets에 부피가 커졌는데.. 후술하겠다.

5. 의존성 규칙 강제 - 하위 레이어가 상위 레이어를 참조 못하게 막으면서 순환 참조가 자연스레 방지

• 순환참조라는걸 해본적이 없어서.. 뭐 어쨋든 더 강하게 막았다니 좋은거겠지?

6. context/provider 패턴 정리 - pages에 provider, widgets/features에 consumer로 명확하게 분리되면서 데이터 흐름 파악 쉬워짐

• 이라고 키워드를 던져줬는데.. 흠 잘 모르겠음
• 우선 context를 정의하는 코드를 가능한 아래 레이어에 두어야하는게 조금 뭔가 어색해보였음
• 물론 이게 보다보면 이게 맞는거일 수도 있는데 만약에 features에서 사용하는 context라면 context생성코드는 features에 있고 Provider는 pages에 있을 수 있는데..
• 뭔가 룰은 맞는데 아직은 어색해보임

7. 결론 및 느낀점

• 음 결론적으로 꽤나 가성비 좋았던 리팩토링 같았다.
• 대부분 내가 짯던 프로젝트라서 그런지 크게 어려운 부분도 없었고
• 변경해 감에 따라 내가 놓쳤던 부분도 발견하고(공통으로 사용하는 기능인데 하나가 누락되어있었다.)
• 제일 좋았던건 shared가 아주 작아진것!
• 생각보다 여러 도메인?에 얽히지 않는 코드가 희귀했다.
• 위에 레이어보다 아래로 갈수록 아래에 두어도 되는지 여러번 고민하는 과정이 꽤나 즐거웠다.
• 물론 위에 이야기한것처럼 어떤 것을 features로 entities로 둬야하는지는 끝내 명확히 나누지 못했다.
• 그래서 widgets가 굉장히 비대해보였고, 적절히 더 아래 레이어로 나누었을때 진짜 fsd의 참맛을 느낄 수 있지 않을까 했다.
• 이렇게 widgets에서 더 잘 나누지 못한 이유는 그동안 내 코드(컴포넌트 및 컨텍스트)가 UI + 데이터 + 로직이 섞여있는채로 있었기 때문이다.
• 여기서 도메인에 대한 개념은 entities로 로직에 대한 부분은 features로 나누는게 앞으로의 할 일 인듯 하다.
• 그래도 변경해보기 잘했다는 생각이 들었고 다른 프로젝트의 코드도 변경할 예정이다.
• 만약 FSD구조가 정말 좋을까 하는 사람이라면, 도입해봐도 좋다고 추천할것 같다.
• 아래는 ai가 추천하는 배워야하는 것들이다. fsd구조를 잘 하기 위해
  1. 도메인 주도 설계 기초 - Entitiy, Value Object 개념
  2. 요구사항 명세서에서 명사 추출 - 그게 도메인 객체
  3. 비즈니스 로직 분리 - UI에서 독립적인 로직 찾기

마지막으로 영상 하나 추가해본다.
최근에 봤는데 정말 좋았다.
어떻게 하면 성장할 수 있는가에 대해 타일러는

• 하루 안에 끝마칠 수 있는 무언가를 해라. 라고 하는것 같았다.
• 나도 틈틈히 하루 안에 끝낼 수 있는 무언가를 계속 해볼것 같다.
• 하루 한 시간도 그런것의 일환이다.
  https://www.youtube.com/watch?v=PVIrUc4gqqE