배포 링크

https://dev4n4.github.io/front_6th_chapter2-3

과제 체크포인트

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기

• 전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
• Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
• FSD(Feature-Sliced Design)에 대한 이해
• FSD를 통한 관심사의 분리에 대한 이해
• 단일책임과 역할이란 무엇인가?
• 관심사를 하나만 가지고 있는가?
• 어디에 무엇을 넣어야 하는가?

체크포인트

• 전역상태관리를 사용해서 상태를 분리하고 관리했나요?
• Props Drilling을 최소화했나요?
• shared 공통 컴포넌트를 분리했나요?
• shared 공통 로직을 분리했나요?
• entities를 중심으로 type을 정의하고 model을 분리했나요?
• entities를 중심으로 ui를 분리했나요?
• entities를 중심으로 api를 분리했나요?
• feature를 중심으로 사용자행동(이벤트 처리)를 분리했나요?
• feature를 중심으로 ui를 분리했나요?
• feature를 중심으로 api를 분리했나요?
• widget을 중심으로 데이터를 재사용가능한 형태로 분리했나요?

심화과제

목표: 서버상태관리 도구인 TanstackQuery를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기

• TanstackQuery의 사용법에 대한 이해
• TanstackQuery를 이용한 비동기 코드 작성에 대한 이해
• 비동기 코드를 선언적인 함수형 프로그래밍으로 작성하는 방법에 대한 이해

체크포인트

• 모든 API 호출이 TanStack Query의 useQuery와 useMutation으로 대체되었는가?
• 쿼리 키가 적절히 설정되었는가?
• fetch와 useState가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
• 캐싱과 리프레시 전략이 올바르게 구현되었는가?
• 낙관적인 업데이트가 적용되었는가?
• 에러 핸들링이 적절히 구현되었는가?
• 서버 상태와 클라이언트 상태가 명확히 분리되었는가?
• 코드가 간결하고 유지보수가 용이한 구조로 작성되었는가?
• TanStack Query의 Devtools가 정상적으로 작동하는가?

최종과제

• 폴더구조와 나의 멘탈모데일이 일치하나요?
• 다른 사람이 봐도 이해하기 쉬운 구조인가요?

과제 셀프회고

이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.

우선 FSD는 말만 많이 들어봤고 제대로 써본 경험은 없었다. 과거에 FSD 공부를 해보려고 FSD 공식 문서를 읽으면서 익숙해지려고 노력했었는데 문서의 내용이 와닿지 않아서 결국 아 이런게 있구나~ 정도로만 이해하고 지나갔던 기억이 난다...반성.. 그때도 여전히 widgets, features, entities 가 무슨 차이인가 하고 헷갈려했던 것 같다. 이번에 이렇게 직접 해보니까 확실히 해보기 전에 비해 FSD 감각이 생겼다고 생각한닷.

이번 과제를 하면서 이전에 비해 새롭게 배웠다고 느낀 점은...(개념적인거 말구)

머릿속으로 생각만 하지말고 일단 코드로 표현해보기! 그러고 나서도 안되면 AI를 갈구던가 주위에 물어보던가 하기...

나는 행동하기 전에 생각을 많이 하는 편이라 실행이 느리다는 단점이 있다. 그래서 개발할때 턱괴고 스크롤만 내리면서 생각만 10분 20분 하고 그런다. 이번 과제는 더욱이 정답이 있다기 보다는 본인이 판단한 FSD를 설계하는 느낌이었어서 생각할 거리가 너무 많았다. 그래서 혼자 삽질도 엄청 하고 뭐 별거 다 찾아서 읽어보고 고민도 많이 하고 그러면서 시간을 많이 흘려보낸 것 같다... 힘든 밸런스게임이었다...ㅜㅜ 근데 하면서 깨달은건데 그렇게 고민이 될 때가 AI를 활용해야 하는 시점이 아닌가 하는 생각이 들었다. AI한테 시뮬레이션을 돌려보라고 하거나.. 내 가설이 적절할지를 판단해 달라 하면 나도 생각이 더 빨리 정리될 것 같았다. 뭔가 나만의 AI 쓰는 타이밍을 알게된 것 같은 느낌인데 안쓰는 것 보다는 이렇게라도 활용하는 게 좋지 않을까.. 어쨋든 손으로 적어봐야 생각이 구체화가 되고 그걸 기반으로 판단을 빨리 할 수 있게 되니까 그런 걸 잘 해보려고 노력해야겠다는 생각이 든다.

본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?

1. 과잉생각 멈추가

멘토링 이후에 "과잉 생각 그만하고 일단 뭐라도 코드를 짜보자!" 라는 생각이 들어서 대체로 그렇게 하려 했던 것 같다. 나는 행동하기 전에 생각을 많이 하려는 편이고, 욕심도 많다. 그래서 자꾸 한 번도 안해본 것을 한 번에 잘 하고 싶어한다. 그래서 개발 속도가 느려지고 질문도 안(못)하게 되는 것 같다. 당장 다른 사람들 코드를 보고 자괴감이 들고 막 내가 엄청 못한거같고... 이러면 안될거같고 그런 생각이 들어도 그냥 할 수 있는 데 까지(내가 생각이 닿은 데 까지) 일단 만들어 보고 리뷰를 많이 받거나 다른 사람들의 코드를 많이 보는 편이 더 도움이 될 것 같다.

2. FSD 밸런스게임

각 레이어의 성격을 이해하고 최대한 적확하게 배치를 하고 싶었다. 그래서 정말 애매하다 싶은거는 주변에 자주 물어보며 다녔다. 근데 물어봐서 더 헷갈리게 된 것 같기도 한데 오히려 내 호불호가 확실히 생긴 것 같아서 좋다는 생각도 들었다... 물어보고 다같이 토론하면서 밸런스게임 하는것도 재밌었고 FSD에 대한 이해도가 오르는 기분이었다. 다른 사람에게 내 의견을 설명해주는 것도 나의 성장에 도움이 되는구나 하고 느끼기도 했다.

FSD 논란을 종결해보고 싶었다... 그래서 코드를 쪼개서 넣으면서 이건 왜 여기 들어가야 하는가에 대한 이유를 머릿속에 꼭 정리하고 배치하려고 노력했다. 지금 누가 코드 아무데나 짚으면서 이건 왜 저기가 아니라 여기 넣었냐! 하면 이유 다 설명할 수 있다.

아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.

코드 구조를 변경하면서 받은 피드백중에 내가 FSD를 너무 Presentation vs Container 패턴 처럼 사용하고 있다는 피드백을 받았다. FSD는 Presentation vs Container 패턴만을 위한 폴더 구조가 아니기 때문에 상태와 뷰를 그렇게까지 분리할 필요가 있느냐? 합치는게 낫지 않겠느냐 라고 하셨는데 그 부분이 아직 감이 안온다. 말로는 이해가 됐는데 뭔가 코드로 어떻게 저게 가능하지 하는 생각이 든다.. 그래서 아직 내가 잘 모르는 것 같다.

이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.

전에 비해 FSD에 대한 이해도가 높아졌기 때문에 나중에 FSD 구조를 보게 된다면 뜯어보면서 생각해 볼 것 같다. 이전에는 그냥 FSD로 된 폴더 구조를 보면 뭐야 몰라 무서워 상태였는데 이제는 다행이도 질문이나 토론 정도는 가능하지 않을까 하는 자신감이 생겼다.

챕터 셀프회고

클린코드와 아키텍처 챕터 함께 하느라 고생 많으셨습니다! 지난 3주간의 여정을 돌이켜 볼 수 있도록 준비해보았습니다. 아래에 적힌 질문들은 추억(?)을 회상할 수 있도록 도와주려고 만든 질문이며, 꼭 질문에 대한 대답이 아니어도 좋으니 내가 느꼈던 인사이트들을 자유롭게 적어주세요.

클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기

• 더티코드를 접했을 때 어떤 기분이었나요? ^^; 클린코드의 중요성, 읽기 좋은 코드란 무엇인지, 유지보수하기 쉬운 코드란 무엇인지에 대한 생각을 공유해주세요
• 어떤 기분이었나요 : 솔직히 전 회사의 코드(급하게 개발하느라 정리되지 않은 코드들)가 생각이 났고 그래서 오 나는 이런걸 잘 고칠 수 있겠다 하는 자신감이 뿜뿜했었습니다.. 막상 해보니 생각보다 고단했지만 뭔가를 뚝딱뚝딱 만드는 ASMR 영상을 보는 기분이 들었고 깔끔해지는 것을 보니 기분이 좋았습니다... 저는 더티코드를 깔끔하게 바꾸는 것을 좋아하나봅니다..
• 클린코드의 중요성 : 클린코드는 동료 개발자의 이해를 돕고 잠재적으로 버그를 줄일 수 있으므로 개발자는 개발을 할 때 이를 신경써야 할 의무가 있다고 생각합니다.
• 읽기 좋은 코드 : 흐름이 명확하고 변수명이 깔끔히 잘 정리되어 있고 적당한 크기로 분리되어 있으며 서로 얽혀있지 않은 각자의 역할이 확실한 코드..
• 유지보수하기 쉬운 코드 : 한번의 하나의 일만 하며 되도록 순수함수를 추구하는 코드. 역할이 명확히 분리된 코드?

결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리

• 거대한 단일 컴포넌트를 봤을때의 느낌! 처음엔 막막했던 상태관리, 디자인 패턴이라는 말이 어렵게만 느껴졌던 시절, 순수함수로 분리하면서 "아하!"했던 순간, 컴포넌트가 독립적이 되어가는 과정에서의 깨달음을 들려주세요
• 커스텀 훅을 제가 잘 안써봤어서 이때 제대로 공부를 하고 사용해 봤습니다. 사실 이미 쓰고 있었는데 개념으로써 정리가 안되었던 것이었습니다..
• 비슷한 역할을 하는 코드끼리 모아서 사용하는 것의 편리성을 알았고, 전역 상태관리를 하면서 props drilling이 없어지고 컴포넌트가 독립적이 되어가는 것을 보며 즐거웠던 기억이 납니다.
• 코드들을 보면서 처음에 이걸 어떻게 순수함수로 바꾸나... 하고 막막해서 고민을 좀 했었는데, 결국 대체로 받은 인자를 조건에 따라 일정한 객체 형태로 return 하고 그걸 hooks에서 가져다 쓰는 형태로 만들면서 이렇게만 해도 코드가 어느정도 패턴화 되면서 뭔가 깔끔해진 것 같다는 느낌이 들어서 좋았습니다.

응집도 높이기: 서버상태관리, 폴더 구조

• "이 코드는 대체 어디에 둬야 하지?"라고 고민했던 시간, FSD를 적용해보면서의 느낌, 나만의 구조를 만들어가는 과정, TanStack Query로 서버 상태를 분리하면서 느낀 해방감(?)등을 공유해주세요
• FSD는 역시 진입장벽이 좀 있는게 맞구나 하는 생각이 들었고 나만의 FSD... 에 대한 정리는 된 것 같은데 다른 사람들도 이에 공감해줄지는 사실 잘 모르겠습니다.
• 멘토링때 테오님이 "그래서 FSD가 마이너한거다" 라고 하셨는데 무슨 말씀이신지 알 것 같습니다..
• 그래도 FSD 구조를 사용하면서 코드를 배치할 때 본인만의 확고한 이유와 기준이 있으면 괜찮지 않을까 생각합니다.

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문

• 실무를 하는 팀에서 FSD를 사용할 때, 뭔가 그 팀 만의 FSD 룰이 생기나요? 지금 과제를 하면서 팀원들과 이야기를 나눴을 때 다 각자가 생각하는 기준이 달랐거든요. 실무에서도 각자가 생각하는 기준이 다를 것 같은데 이런건 어떻게 통합되고 합의되나요?