중요!

면접을 볼 때 중요한 것은 지원자에게 무엇을 기대하는 지.
질문에 대답이 계속 산으로 가고 있음.
딱 질문에 대한 답만 담백하게 하면 됨.
ex) zustand 왜 사용했어요? 상태관리 하려구요.

1. git 과 gitHub 구분할 줄 알아야한다.

• git add, git commit, git push(협업에선 push를 기본적으로 막아둔다고 한다) 등
• git rebase를 할 줄 알면 좋다!
  
  

2. client, server 폴더를 나눠서 한 repo에 작업하지 말자.

• client와 server로 굳이 나눠서 쓸 필요가 없다. 나눠서 쓴다면 클라이언트와 서버가 코드나 자원을 공유할 때나 나눠서 쓸 이유가 있는 거다. 그게 아니라면 이러지 말자.

• 보통 현업에선 레포를 나눠서 하거나, 브랜치로 나눠서 한다.

• 브랜치로 협업하는 것에 익숙해지자.
  (ex: 지금 내가 하는 것처럼 git clone -> 작업 -> git checkout -b branchName -> git add. -> git commit ~ -> git push origin branchName -> 해당 브런치 pr)
  
  

3. env(환경변수)가 깃에만 올라가지 않으면 된다고 생각하는 지?

• 어차피 클라이언트에서 env 파일을 숨기는 건 불가능하다. env 파일이 레포에 올라가지 않도록 해도 네트워크에서 확인 가능하다.
• 작업을 할 때 env를 숨겨야 하는 지, 공개해도 될련지 잘 파악해야 한다.
• open api를 예를들면, 서버에서 api를 요청해서 클라이언트로 보내주는 것. (확실하지 않음)
  (ssr을 예를들면, Next.js에서 open api 요청을 해서 보내면 next.js 서버에서 보내는 거기 때문에 env가 노출될 일 없다)
  
  

4. 라이브러리를 사용할 때는 이유가 있어야 한다.

• 라이브러리를 사용하기 전에 그 라이브러리 마지막 업데이트가 언젠지, 얼마나 많은 사람이 사용하는지를 보고 gitHub에 들어가 코드를 확인해 보자. 코드가 별 거 없다면 그냥 그 코드만 긁어와서 사용하거나 아님 만들어서 쓰는 게 낫다.
  (ex: react-loading)
  
  

5. 코드를 큰 고민없이 짠 거 같다.

• 컴포넌트로 나눌 필요가 없는 것은 굳이 나누지 말자. (ex:serchBar)
  
  

6.페이지가 api 요청에 의존성을 너무 많이 가지고 있다.

• 이럴 경우 테스트하기 정말 힘들다.
• headline도 그렇고, news 페이지도 그렇고 한 페이지에 너무 많은 것을 하고 있다. 추상화가 되어야 한다.