[프리온보딩] 220517 강의 메모 01 (코드리뷰)

코드리뷰

서론

• 초대손님 반갑습니다~~

웹스톤을 쓰는 이유?

• 추천받아서..?

코드리뷰 #1

Route는 최대한 간단해야 한다

• 레이아웃은 최상위에 배치해서 래핑하는 것을 추천
• 기업 같은 경우 페이지가 30~40개급이 돼서 라우터가 무거워질 수록 라우터 구성이 매우 복잡해진다

React-loadable

• 기본 Lazy 기능도 좋지만 loadable을 쓰면 조금 더 깔끔할 것

코드를 최대한 깔끔하게 쓰자

• && 연산자, || 연산자로 도배하는 것보다 if / else문, useMemo 사용하는 것을 추천
• 삼항연산자는 코드의 depth를 늘어나게 만든다
• 프론트엔드는 가독성이 중요 ⇒ 가독성을 신경쓰지 않으면 줄 수가 기하급수적으로 늘어난다
• 나중에 리팩토링 할 수 있으니 그걸 고려하자
• 공통컴포넌트로 쓸 수 있는 것들은 차라리 파일로 따로 빼자

useMemo

• 렌더링 최소화를 위한 훅
• 유의미한 성능차이를 주진 않지만, useMemo를 사용하는 것이 최소한의 props를 사용하여 최대한의 효율을 낼 수 있도록 습관을 들이는 것이 좋다
• useMemo, useCallback은 사용 유무의 성능차이가 크지 않으나 나중에 리팩토링의 용이성, 가독성을 위해 사용함

라이브러리 유명도 기준

• 리액트 라이브러리는 stars가 2K 정도면 인지도 있는 라이브러리라 볼 수 있음
• 언어나 라이브러리, 프레임워크의 인지도에 따라 또 다름
• 이슈가 잔뜩 있지만 해결된 이슈가 거의 없으면 망해가는 라이브러리라 할 수 있다 (...)
• 리드미가 구린 경우도 많다.. 리드미 꼭대기에 “이 라이브러리 망했어요" 하는 경우도 있음 ⇒ 리드미 잘 보기
• moment.js같은 것이 대표적인 legacy 라이브러리이니 거들떠도 보지 말고 day.js를 쓰세요

Props 전달 기준

• Props의 전달을 깊이 2 이상 (손주 컴포넌트까지) 하지 않기
• Props 개수가 3개 이상이 될 경우 리팩토링이 힘겨워진다
• Props 수가 3개 이상이면 파일 수가 많거나 파일당 라인 수가 몇천줄을 넘어간다는 의미
• 차라리 전역 상태관리 라이브러리를 사용하시오… 어디서 온 prop인지 거슬러 올라가기도 힘들어진다
• 프론트엔드는 수정싸움이라 수정을 빠르게 할 수 있을 수록 좋다..

기타 팁

• yml 쓰는 사람 처음봅니다 js랑 json만 씁니다
• 세미콜론은 취향차이니까...
• react-query의 반환 함수인 refetch() 는 promise 형태이고, promise에 then 안 쓰면 린터가 경고를 띄울 수도 있다
• useQuery에 pagination 기능이 있을 것이다 ⇒ 찾아보기
• 취향차이긴 한데 render 단의 가독성을 최소한 올리는 게 좋기 때문에 map 메서드 부분을 useMemo를 이용하여 분리하는 것이 더 깔끔할 수 있다
• 삼항연산자 안에서 반환 (return) 쓰지않기
• 컴포넌트에서 null 이나 <></> 반환하는 방법도 있지만 <React.Fragment /> 를 반환할 수도 있다 (근데 린터가 싫어할 수도 있음)

코드리뷰 #2

앱의 아키텍쳐 요구는 신경쓰지 않아도 된다

• MVP, MVC, MVVM 이런 거 신경썼다간 더 복잡해진다
• 이런 것들은 안드로이드 앱 만들 때 사용하는 것임
• 복잡한 로직은 커스텀 훅으로 빼 버리고 차라리 클린코드에 대해 연구하자

렌더링 부분 depth 줄이자

• depth 11개는 컴포넌트를 빼서 줄이는 것도 좋아보인다
• 주니어 ← 시간이 없어서 복잡하게 짤 수밖에 없었다 ← 핑계임
• depth가 깊어질 수록 나중에 리팩토링하는 시간이 더 오래걸린다... 최대한 파일이나 컴포넌트 분리할 수 있을 때 분리하자

클래스 컴포넌트 절대 금지

• 클래스 컴포넌트 쓴 포트폴리오 거들떠도 안 봅니다
• 인터넷에 옛날 자료가 많아서 그런 듯 한데, 신경쓰지 말자
• 프론트엔드에서 2016년도 자료는 고대의 유물 취급하자

기타 팁

• 마크업에도 신경쓰기
• 이 과제 디자인만 빼면 두시간도 안 걸릴 것 같은데..
• 렌더링 부분에 삼항연산자 어지간하면 노노
• 현업에서는 아이콘 라이브러리나 fontawesome 잘 안 쓰고, svg 파일 가져와서 사용한다 ⇒ 거의 볼 일 없다고 생각하면 됨 (디자이너분들이 알아서 아이콘 다 작업해줌)
• setTimeout ⇒ 약간 야매코드같은 느낌을 준다
• map, forEach ⇒ reduce를 쓰는 것을 추천드림

코드리뷰 #3

디자인 팁

• 디자인에 대한 감이 안 올 때는 dribble.com , pinterest, behance 같은 디자인 웹사이트 많이 참고하고 관찰하고 공부하자
• 디자인 보는 감각도 늘어나고, 레이아웃이나 컴포넌트 구조도 잘 구상할 수 있고, UI/UX적인 요소도 생각할 수 있다
• 개발에 너무 집중하지 말고, 기업이 어떤 것을 만들고 싶어하는지 기능적인 것을 생각해보자 ⇒ 어떤 것을 공부할 지 알 수 있다
• 무작정 검색하지 말고 어떤 것들이 기술적으로 필요한지 생각하고 검색하자
• BTB 회사보다 BTC 회사가 (비트코인 아님) 프론트엔드에겐 좋다
• 디자이너랑 친해지는 것도 좋은 생각이다

선호하는 라이브러리 및 프레임워크

• sass, scss 사용
• emotion 선호 ⇒ 서버사이드 렌더링을 지원하고, 바로바로 적용됨
• 스타일드 컴포넌트는 약간 뒤처지는 추세
• 정답은 딱히 정해져있지 않고, 기준만 명확하면 여러개 섞어 써도 된다
  • 예시: 컴포넌트는 emotion, 페이지는 sass 이런 식
  • 리액트가 자유도가 높은 편이라 자기만의 기준을 잡거나 회사의 기준을 따르면 된다
• tailwind 정말 싫습니다
  • 클래스명 너무 길어지고 테일윈드만의 기준을 외워야 하기 때문
  • 암기를 못하는 사람에겐 완전 별로인 라이브러리다
  • 차라리 직접 짜는 게 빠를수도..
  • 부트스트랩의 열화버전 느낌이 난다

react-device-detect

• 사용하는 기기 별로 화면 크기에 맞게 렌더링해주는 라이브러리
• 쓰지마세요.. 쓸필요 없는듯
• 좀 마이너한 라이브러리임

react-modal

• 포탈에 모달을 자동으로 심어주는 라이브러리
• 약간 더 편리하지만 react-portal 로 만들어도 괜찮다
• 모달과 팝업같은 경우는 state 공유가 가능하니까 마크업의 분리를 해보자

파일 정리 깔끔하게 하기

• 폴더명과 index.tsx 내의 컴포넌트명 일치시키는 것을 추천
• 또는 컴포넌트별로 파일을 분리하고 (Modal.tsx, Box.tsx 이런식) 이 컴포넌트들을 Index.tsx에서 불러와서 export만 하자
• 파일 정리를 미리미리 하지 않으면 나중엔 파일 개수가 몇십 개가 돼서 정리하기 힘들다

기타 팁

• 검색할 때 공식사이트보다 npm 먼저 나오는거 너무 킹받는다
• 리소스 (영상, 이미지 등) 는 assets 폴더에 정리하자
• 코드는 창의적인 것보다 알아보기 좋은 것이 좋다.. 중첩 forEach 등
• 삼항연산자에 렌더링 부분이 들어가는 게 별로다
• typescript union type 사용해보기, interface는 앞에 대문자
• 리액트가 state 덩어리라서 종류가 많아질 수록 난리가 난다

코드리뷰 #4

프로젝트에서 가장 많이 보는 요소

• package.json
  • 무슨 라이브러리 썼는 지, 스크립트가 얼마나 정리가 잘 되어있는지
  • 스크립트에 development, production-server등 따로 관리할 경우 스크립트가 복잡해지므로, env를 사용하는 등 이걸 잘 정리하는지가 조금 관건이 된다
  • devDependency도 볼 때가 있다 ⇒ 제대로 정렬되어 있지 않을 경우 (dev에서만 사용해야 할 라이브러리가 dependency에 올라가있을 경우) 감점 요소가 된다
  • 개발환경에서만 사용하는 라이브러리는 devDependency로 내리자 (@types, @testing 등)
• readme.md
  • 무슨 라이브러리 썼는지 적혀있는 것도 봄
  • 폴더구조, 동작예시 등

확장자 통일하기

• ts랑 js 중 하나로 통일해서 쓰세요
• ts랑 tsx 정도는 분리해도 된다 (로직 / 렌더링)

기타 팁

• 줄임말 어지간하면 쓰지말자,, 별다줄 노놉
• 취업하면 깃허브 잔디가 갑자기 사라진다... 나중에는 자기 코드 리팩토링이나 쓸만한 코드 분리 등을 자주 하게 될 것
• 프론트엔드는 가독성이 정말 중요하다!! useEffect 등에 함수 길게 늘여쓰는 거 전혀 좋지 않다
• 함수같은것도 다른 파일로 분리하는 습관을 들이자
• 변수명에 callback 같은 보편적인 네이밍 하지 말자
• 컴포넌트 return 안에 (렌더링 부분에) depth 깊게 들어가서 길게 작성하는 것 아주 비추
• props명과 변수명 일치시키는거 추천 ⇒ 나중에 헷갈릴 수 있으므로

쉬는시간

• 서버는 express를 사용하거나 자사 라이브러리를 손수 사용해서 간단하게 만든다

코드리뷰 #5

뭔가 부자연스러운 반응형 디자인 수정하기

• 비율을 적당히 맞춰서 작성하자
• 간격같은 부분은 반응형이라고 간격이 부자연스럽게 달라지면 안된다

import 순서 추천

1. node-modules에서 가져오는 라이브러리들
2. 타입
3. 유틸리티 (hooks, utils, services)
4. 컴포넌트
5. 스타일

이벤트에서 e는 무조건 들어온다

e && e.preventDefault(); // 이렇게 할 필요 없음

• 이벤트에서 e는 무조건 들어오기 때문에 조건 넣을 필요가 없다
• 통일성 맞추기 (조건 쓸거면 아래에도 써주기)

useMemo, useCallback 사용해야 하는 경우

const isTestPage = location.pathname === '/';
const isTest2Page = location.pathname === '/test';

// location에 따라 변수가 결정되므로, 이럴 때 useMemo로 묶어주자

• 변수가 별로 없는 경우는 그냥 넣어도 된다
• 변수가 별로 없어도 계산량이 무진장 많은 경우 useMemo, useCallback 고려해보기
• 오히려 useMemo, useCallback으로 도배하다가 성능이 나빠지는 경우도 있을 수 있다
• 데이터가 1초에 몇 번씩 바뀌어서 들어오는 케이스는 캐싱할 필요도 없기 때문에 useMemo의 의미가 없다

기타 팁

• 로딩중일 땐 데이터 받아오지 않도록 막아줘야 한다
• 리렌더링되었을 때만 데이터를 받아오게 하는 것을 추천
• import 정리 좋습니다
• header, main, footer 깔-끔 (시맨틱 태그 애용해주세요)
• if 중첩 최대한 안 들어가는 게 좋다 (cascading 막자)
• 컴포넌트가 조금 길어진다 싶으면 하위 컴포넌트로 분리하기
• 훅 순서 ⇒ useCallback, useEffect, useMemo
• 조건문에서 배열 여부를 알고 싶다면 array.length 대신 lodash의 isArray를 사용하는 게 가독성에 좋다 (length 속성은 문자열에도 들어있으므로…)
• 슥 보면 아 이런 내용이구나 하고 알 수 있는 코드가 좋은 코드다 (여러 번 생각하도록 만드는 코드는 좋지 않은 코드이다)

코드리뷰 #6

useState 남발하는 것 비추

• 컴포넌트 또는 기능 단위로 분리하자
• 너무 보기 힘들어진다....

기타 팁

• react-portal 안 쓴 것 살짝 아숩다
• NotPage 폴더명 쪼끔 아쉽다
• apikey 따로 빼셔야 합니다
• 관심사 분리 잘 하기
• store 라이브러리 쓰면 JSON.parse 쓸 필요가 없어짐
• state만 잘 조작하면 프론트엔드 취업은 어렵지 않다
• 개발자의 월급 한계는 월 천 정도이다?

코드리뷰 #7

SSR

• 기업에서 ssr 꼭 쓰는 경우 아니면 요즘은 잘 기피하는 분위기
• 리액트 다루는 것도 힘든데 next.js 까지 가져오면 머리 깨진다
• 한달 반 공부해도 될까말까 한 분량이다 왠만하면 피하자
• 이걸 배포하려면 인프라, CI/CD, Github Workflow, AWS, 도커 등등을 공부해야 할 것이고, 얘네를 싹 공부해야 next.js를 쓸 수 있을까말까하다
• 서버사이드 렌더링의 개념만 알고 넘어가고, 리액트랑 타입스크립트를 열심히 공부했다고 생각이 될 때쯤 (먼 미래에) 공부하자
• 기업에서 가산점을 준다고 해도 일단 무시하고 넘어가세요... 주니어는 답변을 제대로 할 수 없는 깊은 영역이다

주석 최대한 줄이기

• 클린코드의 기준으로 주석은 못 짠 코드를 변명하는 수단이라고 판단한다
• 주석을 달지 말고 코드를 알아보기 쉽게 깨끗하게 짜는 것에 집중하기
• 다만 CSS에서 특정 웹에서의 동작오류 등 불가피한 경우에는 써도 괜찮다
• 최대한 줄이라는 뜻

코드리뷰 #8

폰트

• 영문 폰트는 용량이 굉장히 작은 편이다 (한글이나 한자 폰트가 문제임)
• Pretendard 추천
• 폰트 구별할 때 ㅈ 어케 생겼는지 보면 된다
• 나눔폰트 계열은 ㅈ이 이상하게 생겼다
• Noto Sans가 무난하고 짱이지만 숫자와 영어가 너무 못났다

MVP 등

• 컨테이너 컴포넌트 구조는 별로다
• 주니어 프론트엔드 개발자만 있거나 사수가 MVP 구조를 사용하는 회사가 MVP 구조를 사용한다
• 커스텀 훅 쓰자 차라리

기타 팁

• 리코일은 아직도 알파다.. 맨날 바뀐다.. atom만 쓰시오...
• 리액트 네이티브도 아직도 알파다... 우리 자식세대에도 알파일 것만 같다
• dotenv, prop-types 필요없다
  • dotenv는 CRA에 기본탑재
  • prop-types는 타입스크립트에선 필요없다

기타 사항들

• 라이브러리를 쓰기 전에 직접 구현 또는 어떻게 작동하는지 알아보고 사용하자 (내부 코드 읽어보자)
• 리액트 라이프사이클에 대해 확실하게 이해하자
• 리덕스 공부해보자 ⇒ 리액트 + 리덕스 조합이 짱이다
• 작은 회사는 도커, 큰 회사는 쿠버네티스 쓴다 ⇒ 쿠버네티스가 어렵지만 거대한 구조 다루기엔 좋다
• 보통의 오픈 API는 엔드포인트를 지정할 수 있는데, 그게 없으면 CORS로 고생길이 열린다
• 린터는 하나도 무시하지 마세요