원티드 프론트엔드 프리온보딩 (22.12.19 월 ~ 23.01.20 금)
1. 프로젝트 평가 기준 관련
📍코드의 가독성
1️⃣formatting -> prettier
2️⃣불필요한 코드 지우기
- 사용하지 않는 import 바로바로 없애기
3️⃣변수명
📍컴포넌트가 잘 분리되었는가?
- 단순히 물리적 단위로 분리하는 것만으로는 진정한 의미의 컴포넌트 분리라고 할 수 없다
- 논리적 단위로 용도에 맞게 필요한 컴포넌트를 설계한다
1️⃣이 컴포넌트는 어디에 사용되는가?
2️⃣이 컴포넌트의 역할과 책임은 무엇인가?
📍관심사가 잘 분리되었는가?
- 반복되는 코드들이 적절한 단위로 추상화되고 분리되었는가?
- 각 모듈, 함수, 클래스 등의 역할과 책임, 동작이 명확하게 드러나는가?
- 각 모듈은 재사용가능한 형태인가?
📍프로젝트의 아키텍쳐는 어떻게 설계되어 있는가?
- 모듈간의 의존성은 잘 설계되어 있는가?
- 외부의 변화에 유연하게 대응할 수 있게 설계되어 있는가?
2. 평가하는 입장에서 생각해보기
📍채용 목표 : 안좋은 사람 거르기
- 좋은 사람 뽑기 보다는 안좋은 사람 거르는 것이 중요
- 안좋은 사람은 자신의 역할에 충실하지 못한 것을 넘어 팀 전체에 부정적인 기운을 퍼뜨림
- 따라서 기업은 방어적인 태도로 지원자를 평가
📍내 과제의 To-be
- 계속 보고싶은 프로젝트, 더 나아가 더 알아보고 싶은 사람이 되기
- 평가자는 지원자의 제출물을 A -> Z 까지 다 읽지 않음 (시간.. 에너지 제약)
- 내 과제에 더 오래 머물고, 더 오래 보고, 나아가서 이 과제를 수행한 나라는 사람에 대해서 더 알아보고 싶게(레퍼런스 확인, 블로그, 깃헙, 면접 등) 하자
📍NG 사례 (하나라도 해당되면 합격 확률 급락)
1️⃣부실한 README
- 과제의 첫인상에 해당
- 평가자가 내 과제를 평가하는 시간과 에너지를 아낄 수 있게 도와야 함
2️⃣관리되지 않은 Git (commit history, branch)
- Git이 미숙하면, 이 사람이 협업이 가능한지 의문을 품게됨
3️⃣기능이 돌아가는지 확인 힘든 과제
- 레포를 클론하여 평가자의 PC에서 직접 실행하는 것은 매우 비효율적
- 환경에 따른 이슈 등이 있기 때문에 내가 통제할 수 있는 환경(배포)을 이용
4️⃣접근 불가한 링크 주소
- 배포된 서버를 비용 문제 등으로 종료할 경우에는, 반드시 기록을 남겨 알리기
5️⃣규칙성 없는 코드 포매팅 및 변수명
- 의미없는 x, y, data, info 사용 금지 => 협업에 악영향
6️⃣불필요한 라이브러리 사용
- 과제에서 허가되지 않은 라이브러리는 사용 금지
- 사용하지 않는 라이브러리는 제거