WIP - 논의 자료 준비 중입니다 👻
제안 태도도구를 더 잘쓰기 위해 어떤 노력을 하셨나요?학습했던 것들에 대해 깊이 있게 대답할 수 있나요?제안 개발 컨벤션코드가 스스로 설명하지 못 하는 내용은 주석으로 설명해요제안 기술브랜치(PR) 머지 전략 → Squash로 하자스타일링 도구 → Tailwind로 하자UI Framework → (무엇이든) 사용하자서버 상태 관리 → 직접 하기보단 React-query로 관리하자패키지 매니저 → berry, pnpm 중 하나를 사용하자단위 테스트 작성 → 재사용되거나 복잡한 코드에는 작성하자개발 방법론: 작게 시작해서 빠르게 개발하자
제안 태도
도구를 더 잘쓰기 위해 어떤 노력을 하셨나요?
- <개발바닥 라이브 중>
- 신입 프론트엔드 취준생분) 프로젝트 ~만큼 했는데 서류 탈락해서 고민이다.
- 진행자분) 라이브러리 쓰는 건 누구나 쓰는데 더 잘 쓰기 위한 노력을 뭘 했는지 써보면 좋겠다.
학습했던 것들에 대해 깊이 있게 대답할 수 있나요?
- <F-Lab 프론트엔드 소개 페이지 중>
- 모든 면접관들이 입을 모아 말하는 것이 "지원 자격이나 우대 사항에 써있는 기술 잘 다 모른다고 해도 되니, 한 개만이라도 제대로 대답하는 사람이 있었으면 좋겠다" 입니다.
제안 개발 컨벤션
코드가 스스로 설명하지 못 하는 내용은 주석으로 설명해요
제안 기술
브랜치(PR) 머지 전략 → Squash로 하자
- 병합은 Squash로 한다.
- 장점:
- git history가 선형적이라는 rebase의 장점
- 커밋이 하나여서 전체 그림을 보기 쉽다는 squash의 장점
- 단점: git lens로 각 Line 별 변경의 이유를 볼 때 commit message가 PR 제목이므로 명확히 이해하기 어렵다.
- Merge Conflict는 PR 작성자가 한다.
git pull --rebase origin main로 최신 main 브랜치 커밋을 리베이스로 받아오고,- 충돌이 있으면 해결 후 commit하고 PR을 생성한다.
- 예시
- (TBD)
- 참고 자료
![[Git] 이게 머지? Merge를 하는 세 가지 방식!](https://www.notion.so/image/https%3A%2F%2Ft1.daumcdn.net%2Ftistory_admin%2Ffavicon%2Ftistory_favicon_32x32.ico?table=block&id=c9716b80-0e33-4c5b-9765-262a3f4a8c8b&cache=v2)
![[Git] 이게 머지? Merge를 하는 세 가지 방식!](https://www.notion.so/image/https%3A%2F%2Fimg1.daumcdn.net%2Fthumb%2FR800x0%2F%3Fscode%3Dmtistory2%26fname%3Dhttps%253A%252F%252Fblog.kakaocdn.net%252Fdn%252FuyJbn%252FbtrVpfOPd3S%252FXnqqOrGG9L29yKbZ7SYRgK%252Fimg.png?table=block&id=c9716b80-0e33-4c5b-9765-262a3f4a8c8b&cache=v2)
스타일링 도구 → Tailwind로 하자
- Tailwind
- (당연하지만) 런타임 코드가 없어, 성능 저하가 없다.
- 런타임 성능 저하가 없는 다른 유명 도구로는 https://vanilla-extract.style 가 있다.
- Tailwind와는 Utility-first가 아니라는 점에서 다르다.
- 생산성이 말도 안 된다.
- 초기 퍼블리싱에서 마크업과 스타일을 계속 바꿔갈 때 특히 유리하다.
- 긴 스타일(flex + padding + gap + border + backgroundColor + color + hover 등)을 입력하는 시간이 압도적으로 빠르다.
- 스타일 입력 시간이 체감 상 2배, 3배 빨라진다.
- 특히 미디어 쿼리나 상태 조건 부 스타일 입력이 빨라진다.
- 아주 가벼운 마음으로 작은 변화를 줄 수 있다.
- 빠르게 쓸 수 있으니 의욕이 난다!
- 매번 스타일드 컴포넌트를 정의하지 않아도 된다.
- 다른 파일 혹은 저 아래에 정의한 후 계속 왔다 갔다 하지 않아도 된다.
- 좋은 단위로 생성하고, 이름을 지어주지 않아도 된다.
- Tailwind는 분리되지 않은 상태로 있어도 자연스럽지만, styled-components는 이상하게 분리되어 있는 경우 부자연스럽다.
- 기본 프리셋 값이 매우 좋다.
- 기본 크기가 4px (0.25rem) 단위로 정의되어 있는데 매우 좋다.
- (ex)
p-2 = padding: 0.5rem; - 기본 컬러셋이 매우 좋다!
- (ex)
text-orange-500,text-green-500 - 응집도 있는 스타일 단위 정의에도 문제가 없다.
- 함께 다니는 스타일은 커스텀 클래스를 작성하면 크게 줄어든다.
- (ex)
.btn,.btn-primary - 당연히, 컴포넌트로 뺄 수도 있다.
- (ex)
<Button>,<Button variant="primary"> - 쓰기 최적화된 도구가 맞지만 유독 Tailwind여서 읽기 어렵다는 이슈 없었다.
- 어떤 도구를 쓰더라도, 남의 스타일을 고치려면 읽어야 하는 css규모는 비슷하다.
- Raw HTML Tag가 같이 보이기 때문에 의도 파악이 크게 어렵지 않다.
- (ex)
<li className="flex flex-col gap-2 p-2 border-2 ...">을 보면 List 컨테이너인 게 쉽게 보인다. - Tailwind의 축약어는 오히려 전체 스타일을 표현하는데 드는 코드가 줄인다.
- styled-components 등은 full css를 표현해야 하기 때문이다.
- (ex)
"flex flex-col"vs"display: flex; flex-direction: column;" - Tailwind는 template string 등으로 동적 생성이 불가하다보니, 스타일을 생성하는 코드보다 스타일 문자열이 코드에 그대로 보존되어서, 오히려 머릿 속에서 컴파일하지 않아도 된다. (대신 이렇게 하면 코드가 좀 길어질 수 있다.)
- e.g. 텍스트 컬러 분기 예시 (TBD)
UI Framework → (무엇이든) 사용하자
- 무엇을 사용하든 사용하는 게 사용하지 않는 것보다 나을 확률이 90% 이상이라고 생각
- Tailwind와 사용했을 때 Tailwind 기반의 UI Framework를 사용하지 않는다면 Tailwind의 class 재활용이 다소 떨어질 것이라고 생각
- 주요 Tailwind 기반 UI Frameworks:
- Shadcn
- 미니멀, 깔끔한 인상을 줄 수 있다. 캐주얼 하지 않고 포멀하다.
- 단순한 스타일만 있는 게 아닌 기능도 포함하고 있다.
- e.g. Sonner → Noti 스택을 스스로 관리한다.
- e.g. Dropdown → on/off 상태를 스스로 관리한다.
- Daisy UI
- 캐주얼하고 가벼운 디자인이다. 약간 저 퀄 느낌이 날 수 있다.
- 단순 스타일 위주로 제공된다. 기능은 대개 직접 만들어야 한다.
서버 상태 관리 → 직접 하기보단 React-query로 관리하자
- React-query의 장점
- 경쟁 상태 발생
- useEffect에서 query하는 경우:
- state, props가 바뀌는 순서와 비동기 데이터가 도착하는 순서는 다를 수 있다.
- state, props는 새로운 id를 갖고, 비동기 데이터는 예전 id를 갖는 게 마지막 응답하면, 서로 불일치가 발생한다.
- 로딩 상태가 관리 대상에 추가됨~!
- 이건 react-query 쓸 때도 똑같은 듯
- 추가로
signal도 필요한데, 이걸 fetch에 전달하면 알아서 취소해준다고 함 (잘 모르겠음 이건 fetch 쪽 스펙도 봐야 할 듯) - 이건 react-query든 fetch든 뭐든 공통 코드로 빼면 매우 편해질듯 :)
- React-query는 data fetcing 라이브러리가 아니라 비동기 상태 관리자이다.
- Camera API 같은 비동기 상태에도 사용할 수 있다.
- 이것들을 맛 보면 되돌아갈 수 없다.
invalidateQueries로 기존 서버 상태를 초기화하면 자동 re-fetch를 해준다.패키지 매니저 → berry, pnpm 중 하나를 사용하자
- yarn berry 혹은 pnpm을 도입한다면 큰 러닝 커브 없이 설치 속도 개선을 얻을 수 있다.
- 설치 속도 개선 = 배포 속도 개선 (p.s. berry와 pnpm의 전략은 다르다)
- 도구가 알아서 해주니, 가져다 쓰면 되어서 비용이 매우 낮다.
- Next.js를 사용할 거라면, pnpm을 사용해보는 게 좋겠다 (turbopack이 berry는 미지원)
- 참고 자료
단위 테스트 작성 → 재사용되거나 복잡한 코드에는 작성하자
- 테스트의 장점
- 테스트를 실행하는 것은 개발 서버를 키는 것만큼 쉽다. (
pnpm test) - 첫 PR 이후에는 기존 동작의 무결성을 회귀 테스트가 알아서 체크해준다.
- 테스트는 코드의 사용 사례에 대한 문서화 도구이며 유효성 검사가 셀프로 된다. (vs 주석)
- 단위 테스트는 실행 속도가 빠르다.
- watch 모드로 실행한다면 매 코드 변경 시마다 기존 동작이 깨졌는지 확인할 수 있다.
- 특히 watch 옵션을 수정된 파일로 한정한다면 대부분 즉시 실행 완료된다.
- 테스트 작성 대상
- 테스트 가치가 높은 코드를 테스트해 수동 테스트 비용을 줄인다.
- 재사용되는 코드
- e.g. 공통 회원 상태, 스토리지 저장, 공통 컴포넌트의 뷰
- 재사용되지 않더라도 복잡한 코드
- 혼자서 복잡한 코드는 내부 로직 변경 시마다 매번 테스트하게 된다.
- 외부와 복잡하게 얽힌 코드는 외부 코드 변경 시마다 매번 테스트하게 된다.
- 테스트 비 대상
- 테스트 비용이 낮은 코드
- 동작이 자주 바뀌는 코드
- 테스트 코드도 함께 유지보수해야 하므로, 동작이 바뀌면 테스트도 유지보수해야 하므로 오히려 속도에 저하가 온다.
- 테스트 작성 내용
- 해당 코드의 사용 방법을 작성한다.
- 각 사용 사례와 의도한 결과를 명세한다. (happy path)
- 조금 더 쓴다면… 사용하면 안 되는 사례와 실패하는 결과를 명세한다. (unhappy path)
- 뷰가 없는 Custom Hook → state 변경 함수 호출 후 state 변화 관찰
- 뷰만 있는 Presentational Component → event 발생 후 view 변화 관찰
- 기본적으로 스타일에 대한 테스트는 어렵다.
- (화면이 실제로 어떻게 렌더링 되는지)
- 단위 테스트에서는 JSDOM을 사용하므로 Text, Element로 검증한다.
- 화면에 해당 Text가 있는지, 해당 버튼이 있는지 등
- 한계:
- 스타일을 검증하는 것은 한계가 있다.
- 화면은 자주 바뀔 수 있다. 이 경우 테스트 코드도 변경해줘야 해서 일이 더 많아진다.
개발 방법론: 작게 시작해서 빠르게 개발하자
- (TBD)
- 참고 자료
