Intro

CMC & UMC 해커톤에서 FE 개발자들끼리 세팅을 맞추고 시작하였다. 근데 오늘 또 해커톤이라,, CMC분 없이도 야무지게 해내기 위해 FE 개발자들끼리 맞춰야하는 것들을 되새겨보는 시간을 가져보겠다.

개발자 환경 세팅

cmc 죠스타 존경합니다!

버전

• 노드, 디노 >> 노드
• yarn, pnpm, npm 등등 >> npm
• 웹뷰방식 or 순수 리액트 네이티브 방식 >> 순수 리액트 네이티브
• expo 방식 react-native-cli 방식 >> react-native-cli

사실 이 얘기를 나눴을 때 초큼 멘붕이였다. 그래서 다시 복습 겸,
npm과 yarn의 차이 :
node 개발 환경에서는 패키지 매니저로 npm 또는 yarn을 쓴다.
npm과 yarn은 자바스크립트 패키지 매니저이다.
솔직히 여태 yarn 설치 귀찮아서 npm 써왔는데 해커톤 때 약간 흠칫하셨던 거,,, 기억이 나네요!
그래서 둘의 차이는 무엇이냐! 'yarn이 npm의 조금 더 개선된 버전이다'
1. 속도가 더 빠르다. (performance)
2. 보안성이 좋다. (security) 로 나뉠 수 있겠다. 당연히 npm 이후 npm의 부족한 점들을 이제 yarn이 보완해서 나온 것이다 라고 이해하면 된다.
Yarn은 npm이 사용하는 동일한 npm 구조에 의존한다고 한다.
패키지의 레지스트리에 대한 것은 바뀌지 않았고, 설치 절차가 바뀌었다고 생각하면 된다.
그렇다고 yarn 무작정 쓰자는 아니다.
yarn 또한 디스크 용량을 많이 잡아먹는다고한다. npm도 개선된 버전이 계속 나오면서 속도는 yarn과 별반 차이가 없다고 볼 수 있다...!
결국 npm yarn, 어떤 걸 써도 무방하다.
https://seogeurim.tistory.com/12

언어적인 측면

• 자바스크립트를 쓸건지 타입스크립트를 쓸건지 >> 자바스크립트

이 부분에 대해선 아마 js 로 이번 해커톤에선 임하지 않을까 (4기 챌린저들 뿐이니..)

코드 컨벤션

• 함수의 형태를 어떻게 짤건지

  • 에로우 함수, 함수 선언문 >> 에로우 함수

• 타입스크립트를 쓴다면

  • 타입단언 사용을 허용할것인지
  • any, undefined, unknown의 사용을 허용할것인지
  • 옵셔널 체이닝의 사용여부를 어떻게 할것인지

• 이벤트 함수명을 어떻게 할것인지 >> handle~~~

• 컴포넌트화의 기준을 아토믹 스타일, 필요에 맞춰서하는 스타일중 어떤걸 선택할것인지. 혹은 더 좋은 방침이 있는지 >> 도메인 단위로 구축

  컴포넌트화의 기준이 이제 얘기를 나눌거리가 되지 않을까싶다. 사실 밤 새는 입장에서 걍 더럽게 짜도 돌아가면 그만이라는 마인드가 나중엔 차지하게된다......... 반성해.
  1 아토믹 스타일 : 작게 작게 작게 병합 알고리즘 같은 느낌으로 생각하자 컴포넌트의 재사용성을 높일 수 있지만, 시간이 없는 해커톤에선
  2 도메인 단위로 구축하는게 베스트!일 것 같다는 소신.
  하지만 깔끔한 코드 작성을 위해서라면 아토믹 스타일을 지켜서 쓰는게 좋을 것 같다.

• 테스트 코드를 작성할것인지 >> pass

• 어느 범위까지 커스텀훅으로 관리할것인지 >> 리액트 쿼리 코드, 중복되는 코드만 커스텀 훅으로 관리.

커스텀 훅은 개발자가 만드는 훅으로 복되는 로직을 묶어 하나의 컴포넌트로 만들듯이 반복되는 메서드를 하나로 묶어 사용한다.Input과 Fetch를 관리할 때 자주 쓰인다.
지켜야 될 점은 리액트 내장훅과 마찬가지로 커스텀 훅의 이름은 use로 시작!
https://velog.io/@niboo/React-Custom-Hook-%EC%9D%B4%EB%9E%80
이해가 쉽게 되는 예시는 위 레퍼런스를 참고!!

명명 규칙

• 변수 >> 카멜 표기법 (명사) boolean >> 동사 섞어서
• 함수 >> 동사 카멜 표기법
• 파일 >> 대문자 시작 카멜 표기법
• 클래스 >> 생략
• 인터페이스 >> 생략
• 타입(type) >> 생략

폴더 컨벤션

• constants 폴더를 사용할것인지 >> 생략
• apis에 fetching함수들을 담아 관리할것인지 (axios vs fetch)>> axios apis 폴더에서 관리
• 스타일을 어떻게 관리할것인지(사용되는 해당 컴포넌트에 같이 묶어 관리할지, 아니면 styles폴더에 모두 담아 관리할지) >> 스타일 나눠서 관리하기
• 유틸리티 폴더를 만들어 코드 중복을 방지할것인지 >> 생략

라이브러리

• 상태관리 라이브러리를 어떤걸 쓸것인지
  - zustand, recoil, redux, redux-tool-kit, jotai, mobx >> zustand

  이 부분에서도 이제 멘붕이 왔던 부분이다. redux만 배웠지 사실 zustand..?처음들어본다.
  그래서 간략히 조사해 본 결과
  
  이렇게 세가지가 많이 쓰인다.
  저는 이 중 Redux와 zustand만 정리해보겠다.
  Redux : 중앙 집중식 Storage와 상태 업데이트를 위한Reducer를 사용하고, 단방향 데이터 흐름을 따른다는 점을 들 수 있습니다.
  또한 미들웨어를 활용하여 여러 비동기, 로그 작업 등을 처리할 수 있는데 이 때 Redux를 위한 라이브러리를 사용하여 더 쉽게 구현이 가능하다! 하지만!!
  State가 변경 될 때 Component를 업데이트 해 주는 반응형 메커니즘이 기본적으로 탑재되지 않았기에, React의 자체 메커티즘을 활용하거나 추가적인 외부 라이브러리를 사용해야하며 진짜 복잡하다고 하네요
  그래서 cmc 선배분이 찬양하신 이 zustand에 대해 https://www.nextree.io/zustand/
  참고를 보면 이해가 더더 잘 될 것이다.
  사용법 https://velog.io/@yeonsubaek/React-Zustand%EB%A1%9C-%ED%8E%B8%EB%A6%AC%ED%95%98%EA%B2%8C-%EC%83%81%ED%83%9C%EA%B4%80%EB%A6%AC%ED%95%98%EA%B8%B0
  zustand는 발행/구독 모델 기반으로 이루어져 있으며, 내부적으로 스토어 상태를 클로저로 관리한다.

• 서버자원관리 라이브러리로 어떤걸 쓸것인지 >> 리액트 쿼리

• 스토리북을 사용할것인지 >> pass

• 모킹 라이브러리(msw)를 사용할것인지 포스트맨을 쓸것인지 >> msw

• 스타일 관리를 위해 어떤 라이브러리를 사용할것인지

  • css, scss, styled-components, emotion, tailwind >> styled-components
  • mui, chakra >> pass

• 네비게이션 라이브러리 어떤걸 사용할것인지(드로워, 스택, 탭) >> 탭, 스택

• 로딩 표현을 어떤걸 사용할것인지(로딩바, 스켈레톤 UI)

커밋 컨벤션

• fix: 버그 수정에 대한 커밋입니다.
• refact: 리팩토링 범위의 수정에 대한 커밋입니다.
• chore: 작은 범위의 수정에 대한 커밋입니다
• feat: 추가 기능에 대한 커밋입니다.
• style: 디자인 수정 커밋입니다.
• readme: 리드미 수정 커밋입니다.
• move: 폴더위치 변경.