원티드에서 진행하는 프리온보딩 프론트엔드 코스에 지원하고, 합격한 다음 오늘 첫번째 수업을 듣게 됐다.
👊 접수 후기
과제 자체는 난이도가 있는 편은 아니었으나
일찍 접수하면, 가산점을 준다는 것을 가산점 마감 기한 이틀 전에 보는 바람에
(아 가산점은 못 참지)
남은 이틀동안은 거의 밤 새다시피 과제만 한 것 같다.
심지어 본가 내려갔다가 올라오는 날도 있어서 비행기에서 Styled Component를 작업했던 기억이 있다.
과제만 제출하면 되는 일반 전형이 있고, 기타 취업 지원센터 및 제도와 연계된 전형이 있었는데,
서류를 준비하는 게 번거롭지만 그래도 내가 해당되는 전형으로 따로 신청했다.
숏에세이도 적었어야 했는데, 하면서 프리온보딩 참여 기업에 대한 TO를 확인하면서 신입을 뽑는 비중이 아주 적다는 걸 몸소 느낄 수 있었다.
(신입은 어디서 경력을 쌓나요...)
아무튼 합격했다.
9월 첫째 주부터 화, 금 14~17시 고정 시간으로 5주간 진행된다!
무엇보다 신청하면서 꼭 합격됐으면 좋겠다는 생각을 했던 이유는 바로 마지막 학기 공강 시간에 딱 맞는 시간이었기 때문이다.
편-안
👀 새로 배운 내용
오늘은 그리고 기다리고 기다리던 프리온보딩 첫 번째날!
새롭게 배운 것들을 그날마다 정리할 예정이다.
이번 수업 목차는 다음과 같다.
1-1) Orientation
시작하기 전에
멘토가 전달하고자 하는 것
커리큘럼 안내
기업 과제 진행 방식
기업 꽈제 평가 방식
1-2) 과제 피드백
과제의 주제
과제에서 파악하고자 하는 것
과제에서 중점적인 기준이 된 사항들
피드백 사항
1-3) 프로젝트를 하기 전 알아야 할 팀으로 일하는 법, 개발자의 기본기
Overview
Git & GitHub를 사용하면서 지켜야 할 것
History 관리 및 브랜치 관리 전략
ESLint와 Prettier, Git Hook을 이용한 팀의 능률 올리기
1-4) 과제 안내💃 Orientation
무엇보다 내 생각과 많이 달랐던 것은, 프리 온보딩 과정은 교육을 제공받는 시간이 아니라는 것.
교육이 중점이 아니라 스스로를 훈련하는 과정이란 것을 누누히 강조했다.
나는 사실 교육을 듣는 것에 더 치중될 줄 알고 신청한 것인데,
이 부분에 대해서는 약간 예상을 빗나갔지만, 어떻게 보면 내가 안일했던 것일지도 모른다.
떠먹여주는 것에 익숙해지지 말고 직접 먹이를 찾아 나서 사냥하는 법을 배우는 것으로 마음을 가져야 겠다.
그리고 프리 온보딩 수료 이후 스스로에게 기대하는 부분도 생겼다.
- 스스로 좋은 코드에 대해 견해를 가진다
- 왜 이걸 사용하는지, 이걸 적용하면 뭐가 좋은지를 알 수 있다.
지금 오픈소스 컨트리뷰트도 하고 있는데 계속해서 느끼는 것은,
내가 코드리뷰를 할 만한 지식과 견해가 부족하다는 것이었다.
코드를 봐도 이게 어떻게 돌아가는지 간신히 파악하는데,
사실 돌아가기만 하면 장땡아닌가?
이 코드가 좋은 코드인지, 과연 코드에서의 '좋다'는 어떤 의미를 가지고 있는지 알 수 없었다.
프리 온보딩 기간 중 위의 사항들을 배울 수 있다니 참 반가운 소식이었다.
🤦♀️ 과제 피드백
본격적인 팩트 폭행 시간이었다.
README.md 작성이 그렇게 중요한 줄 몰랐는데, 멘토님의 말씀을 잘 들어보니 제일 중요하다.
코드를 열심히 짰다고 해서 끝난 것이 아니라 기업 과제라고 생각하면,
이 README.md가 내 코드를 읽고 싶게 만드는 지 결정짓는 중요한 요소이다.
난 정말 최소한의 조건에 맞춰서만 작성했는데, 여기서 TroubleShooting이나 기술 스택 선정 이유 등을 더 추가했으면 좋았을 것 같다.
이전 프로젝트에서는 그렇게 정성들여서 만들었는데, 왜 이번 것은 그렇지 못했을까.
뭔가 간단한 프로젝트이기에 쉽게 넘어가려는 자기 합리화가 크게 작용했던 것 같다.
그리고 배포도 마찬가지... 괜히 안되면 화날 것 같아서 굳이 하지 않았는데,
사실 생각해보면 기업 관계자들이 코드를 뜯어보기는 커녕 clone해서 실행까지 시킬 시간이나 있을까?
간단한 토이 프로젝트를 배포하는 연습도 꾸준히 해야할 것 같다.
👨👩👧👦 프로젝트를 하기 전 알아야 할 팀으로 일하는 법, 개발자의 기본기
이전 엘리스에서 여러 프로젝트를 진행하면서
code, commit, PR convention.. 등은 아무래도 어때 식으로 정했던 적이 많은데,
이런 convention을 정하는 것이 커뮤니케이션 스킬을 강화할 수 있는 방식의 일종이라는 말씀을 듣고
생각이 많이 바뀌었다.
아무래도 코드리뷰 때 기본적으로 통일될 수 있는 코딩 스타일에 대해 논하는 것은 커뮤니케이션 비용을 낭비하는 것과 다름없다.
따라서 미리미리 초기에 ESLint, prettier과 같은 툴로 코딩 스타일을 통일시키고, 협의를 통해 commit message, branch name 등을 통일시키면 불필요한 논의를 피할 수 있을 것이다.
🤸♀️ 더 공부하고 싶은 내용
혼자서 typescript 프로젝트를 진행할 때, ESLint 설정에 애를 먹었던 기억이 있는데,
오늘 배운 것을 바탕으로 다시 한 번 ESLint 설정을 도전해보고 싶다.
그래서 초기 설정은 이제 익숙하게 하면 좋겠다.
🧘♀️ 느낀 점
- 모든 것을 누군가 떠먹여주기만을 기다리지 말자.
- 취업은 완벽주의가 참 중요하다.
'중요할까?'라고 생각하는 부분이 생기면 '괜찮겠지'하고 넘어가지 말고 찾아서 공부하고 보완하자. - 5주간 함께 기업 과제를 수행해가는 팀이 짜졌는데, 확실히 다른 사람이 짠 코드는 바로 이해하기 힘들었다. 다른 사람의 코드를 읽어보고 이해하는 연습의 필요성을 느꼈다.
