2번째 커피챗

궁금한 거 있으면 슬랙으로 언제든지 물어봐주세요~ 슬랙으로 소통하는 것을 권장합니다. 막히는 부분에 대해 굳이 질문을 따로 하지 않더라도 답변드릴 수 있기 때문에!

eslint, prettier

• 목적: 여러 명이 개발하지만 외부에서 봤을 때는 단 한 명이 개발한 것처럼 보이도록
• 클린 코드, 높은 정합성

• 린트는 팀원끼리 합의해서 최대한 고통받지 않는 선에서 가져가자

• 기본적으로 airbnb 룰을 채택하고 하나하나 뺄 수도 있다

• eslint 룰 하나하나 확인하면서 선택하려면 프로젝트 시작 전 미리 하는 게 좋다

Next.js

• 한정된 시간 내 너무 많은 새로운 기술을 채택하는 것은 오히려 마이너스 요인

• 건강을 고려하면 뺄 건 빼는 게 좋지 않을까

• 개인적으로 Next를 빼고 React를 쓰는 게 좋을 것 같다
• (공부는 해야 하지만) 면접에서도 Next가 필수는 아닌 것 같다
• CRA의 근본적인 문제점(SSO, meta 태그 등)을 해결하지 않으면 쇼핑몰 같은 서비스를 구현하기 어렵다 → 취업하고자 하는 도메인 고려

• Recoil과 React Query까지는 괜찮을 것 같다

• Next.js 환경 세팅하는 것만으로도 2주 걸릴 수 있다

• 기존에 아는 것과 새롭게 배우는 것을 적절히 섞어서 하는 게 만족도가 높을 것 같다
• 코드의 질이나 면접을 고려했을 때 플러스 요인이 될 수 있음

• (민재) 프로젝트를 마친 후에 Next로 마이그레이션을 해도 괜찮을까요?
• 좋은 것 같다. 일단 1차적으로 완성하고 추가적으로 액션을 취하는 게 면접관 입장에서도 충분히 플러스 요인이 될 수 있다.
• 시간이 있다면 도입해보고 한 달 동안 도전해보는 것도 좋지만 우리의 시간은 그렇게까지 넉넉하지 않다..!

경로 alias

백엔드와의 협업

• 백엔드의 개발 방식

• 어떤 주제로 할지 정해졌다면 화면을 어떻게 구성할지 함께 논의한다.
• 화면을 보면서 어떤 API가 필요한지 파악함
• ex. 게시글 리스트 → 카드 → 좋아요, 조회수, 댓글 수
• 이를 바탕으로 DB 작업 진행

• 과정
• 프론트가 백에게 각 페이지별로 필요한 데이터가 무엇인지 정리해서 전달
• 전달한 것을 토대로 프론트와 백 소통
• 어떤 식으로 데이터를 뿌려줘야 하는지 정의내림(API 설계 = 요구사항 정리)
• 설계를 기반으로 백엔드 개발 시작
• 프론트는 sample json data를 만들어서 테스트를 돌려보면서 그에 맞는 UI 개발

• 사전에 논의하고 설계한 대로 될 것이라는 보장이 없다. 중간에 문서가 변경될 수도 있다.
• 어쩔 수 없이 받아들여야 합니다..ㅎㅎ
• 이 과정이 끝나면 백엔드와 크게 부딪힐 일이 거의 없다

• 불합리한 부분에 대해서는 의견을 표출할 수 있어야 합니당

프로젝트 관련 조언

• eslint, prettier, 공통 컴포넌트까지 논의해보면 좋을 것 같다.

• 어떤 기술을 활용하기 위해 추가적으로 공부해야 할 시간이 너무 오래 걸리면 좋지 않다(cypress, e2e도 마찬가지)

• 초반 기획 설계에서 어디까지 개발이 가능하고 개발 실력이 어느 정도인지를 명확하게 파악할수록 좋은 성과를 얻는 편이다.

• 디자인 시스템도 만들어보면 좋은데 만들더라도 공통적인 컴포넌트(input, image, select, color 등)만 진행하고 더 이상 진행하지 않는 것을 추천한다.
• 짧은 기간 내 디자인시스템을 잘 만들어서 잘 동작되게 하는 건 사실상 불가능하다.
• 지정한 props가 변경되지 않으리라는 보장을 하기 어렵다. 수정하더라도 그때그때 스토리북에 반영하지 않으면 크게 의미가 없다

• 취업을 위해 다양한 기술 스택과 디자인 시스템에 도전해보려고 하는 것 같다
• 이런 요소 하나하나로 판가름난다기보다는 사용한 이유와 근본적인 요소가 더 중요함
• 면접에서 물어보는(중요하게 보는) 것
• 상태 관리 라이브러리를 선택한 이유?
• 선택한 라이브러리의 장점과 단점?
• 현재 프로젝트와 해당 라이브러리의 장점이 잘 어우러졌는가?

매력적인 포트폴리오

• 1기 수림님 포트폴리오 참조

• 프로젝트에 대한 간략한 설명 + 클릭 시 자세한 설명
• 팀 프로젝트에서 내가 개발한 부분
• 회고
• 구현 화면 또는 동작하는 url
• 회의록
• 깃헙 레포에서 확인할 수 있으면 더 좋다

• 깃헙 프로필도 중요하게 볼 수 있음
• pinned repo나 최근 프로젝트
• 리드미가 잘 쓰여져 있는지(템플릿 그대로 쓰거나 비어 있는지)
• 커밋 내역(단순 디자인 커밋만 있는 건 아닌지, 포트폴리오 내용과 일치하는지)
• 잔디(private repo에서 작업하더라도 표시되더라도 세팅하기)
• 대외활동 및 오픈소스 활동 여부

• 개발하는 것 자체에 대한 재미와 열정이 잘 드러나 있는 사람을 선호한다
• 글로 표현하지 않아도 커밋 등을 통해 드러난다

• 이력서에 쓸 줄만 아는 정도의 기술 스택을 넣어도 되는 걸까?
• 면접 때 질문이 들어와도 답변할 수 있는 게 아니라면 빼는 게 낫다

기타

• lighthouse는 돌릴 때 당시의 네트워크 환경에 따라 다르게 나옴
• 모바일 퍼포먼트 측정은 3G를 기준으로
• 참고할 만한 수치로 생각하는 게 좋다

면접

• 혹시 궁금한 거 있으신가요? 라고 물어보셨을 때, ‘아까 답변하지 못했던 ~~에 대해 혹시 답변해주실 수 있을까요?’ 라고 묻는 것도 좋다

• 정말정말 가고 싶은 회사는 중간부쯤에 면접을 하는 게 합격 가능성을 높일 수 있다!