질문
팀 내에서 코드리뷰는 어떻게 진행하시는지
한 레포를 여러팀에서 사용하는 경우가 많음
일단 팀 내에서만 코드 리뷰를 하는 편
다른 팀과 같이 이야기해서 코드 리뷰에 참여하는 경우도 있음
gitlab을 사용하는 중, 리뷰어를 1명만 지정할 수 있음
Merge Request 링크를 팀원에게 공유
2명 이상의 approve가 필요
사소한 변수명, 크리티컬한 이슈까지 전부 코멘트하는 편
크리티컬하지 않은 사소한 부분은 추가적 상의를 하고 최종적으로 MR을 올린 사람이 결정
MR을 올리면 빌드, 테스트, 린트가 돌아감
CI/CD로 테스트 서버까지 올라감
커밋 단위로 리뷰를 하는지 파일 변경에 대해서만 리뷰를 하는지
파일 변경 위주로 리뷰를 하는 편
커밋 단위로 하면 흐름 파악이 힘들 수 도 있기 때문
vue 전역 store pinia에서 state를 정의할 때 as 타입 단언을 사용하는 것, 비동기로 가져올 데이터를 빈 객체로 초기화 해 놓는 것에 대해서
state 타입 선언을 위해 데이터의 타입을 전부 옵셔널로 정의 하는 것은 좋지 않은 방법이라고 생각
as 단언 대신 어디선가 타입을 정의할 수 있는 방법이 있을 것이라고 생각
빈 객체 대신 as 단언으로
데이터타입 | null 로 정의할 수 있을 듯타입스크립트를 사용하다보면 타입을 정의하는 것이나 유니온 타입에 대해 찾아보게 되고 자연스럽게 습득 될 것이라고 생각
토이 프로젝트
정부 공공 API를 활용하는 방법이 있음
firebase, strapi, hasura같은 db를 활용하여 백엔드에 대한 큰 지식 없이 프로젝트를 해볼 수 있음
sql이나 DB 지식이 없어도 graphql이나 rest api를 자동으로 생성해줌
거창하게 생각하지 않고 사소한 것을 만들어 보는 것도 좋음 → 의외로 좋은 결과로 이어질 수 있음
붕어빵 지도, 트리 꾸미기
악의적인 접근, 공격에 대해 한번쯤 고려해 볼 필요가 있음
어느 단계에서 전역 스토어를 도입하는게 좋은지
4~5 뎁스 이상인 경우 전역 스토어를 도입하는 것이 좋을 듯
전체 props를 바로 하위 요소를 넘겨주는 경우라면 props도 나쁘지 않음
반대로 props를 선택적으로 넘겨줘야 한다면 전역 스토어를 도입하는것이 좋을 듯
케이스 바이 케이스, 주관적 판단이 필요, 정답은 없음, 차선책 찾기
코드를 작성할 때 이런 부분을 고민하는 과정에서 시간이 많이 소요됨
다른 전역스토어를 사용하는 것보다 useContext의 사용이 와닿지 않는데 useContext를 사용해야하는 기준이 있는지
최대한 서드파티를 사용하지 않으려함, 어찌되었던 최적화에 영향을 주기 때문
페이지 단위에서 전역스토어를 사용하지 않았다면 최대한 useContext를 활용해보려고 하는 편
다만 리렌더링에 대해 고민해봐야함
본인만의 기준으로 사용하면 됨
맹목적으로 방법론은 쫒는 것은 비효율적 일 수 있음 ex) 아토믹 디자인
apollo client에서 onCompleted에서 데이터를 파생시켜도 되는지에 대한 논쟁비동기나 애니메이션 처리시 레이아웃 shift를 막는 방법이 있는지
반응형 처리
비동기 데이터를 가져오는 과정에 대한 처리,
이미지 Fallback 처리
skeleton 처리
이런 것을 잘 처리하는 것이 실무에서 중요한 부분
사용자 경험에 있어 영향을 많이 받는 부분
케이스 별로 정리하고 공부해보면 좋을 듯
사용하는 이미지의 비율이 각각 다른 경우 강제로 늘리는 것이 괜찮은지
좋지 않음
레터 박스 or 크롭 처리 → SEO에 좋지는 않을 듯
이미지를 img tag 대신 background-image로 가져오면 SEO에 좋지 않은 영향을 미침
개인/토이/사이드 프로젝트를 진행하면서 Lighthouse 점수를 확인해 보는 것도 좋을 것 같음
비동기 데이터는 resolve 됐지만, 이미지의 로딩은 이루어지지 않은 경우에 대한 처리
비동기 데이터의 로딩과, 이미지의 로딩은 별개로 생각해야 함
이미지의 크기에 따라 로딩 시간이 달라질 수 있음
저용량 썸네일 이미지를 먼저 보여주고, 이미지 로딩 완료를 이벤트로 받고 src를 변경해주는 방법도 있음
Storybook 도입에 대해
storybook에 대해서는 긍적적으로 생각
storybook을 따로 챙기는 부분에 대해 망각할 수 있음
컴포넌트를 시각적으로 바로 볼 수 있는 부분이나, 문서화
신규 개발자가 프로젝트를 파악하는데 큰 도움이 됨
Storybook은 명세서인지 TDD 용도로 사용할 수 있는지
명세서에 가까움 TDD용도로도 사용할 수 있을 듯
TDD 라이브러리를 대체할 목적으로는 부족한 부분이 있을 듯
TDD만을 위해 도입하는 것은 리소스 낭비