- 프로젝트 시작 이전에 팀원과 협업 관련된 이야기를 나누고 싶은데, 무엇에 대해 우선적으로 이야기를 나누면 좋을까요? 예를 들어 각자 관심있는 기술 스택, 만들고 싶은 주제 등등…
멘토님 답변
팀원은 정해져 있으니까, 협업을 어떻게 할 지에 대해 이야기를 많이 해보는 게 좋을 것 같다.
- 일을 할 때 가장 중요한 것은 일정관리이다. 일정관리를 어떻게 해야하나?
- 일단 내가 8시간(1md: mans day) 개발을 했을 때 어느정도의 성과가 나올 수 있는지를 알아야 한다.
- 일을 받을 때, 어느정도 걸려요? 라고 물어보면서 주시는데, 8시간 동안(1md)의 업무량을 기준으로 몇 md 정도 걸립니다~ 라고 말할 수 있어야 하기 때문에 여유롭게 일정을 만드는 능력을 길러야 한다. 그것을 연습하는 게 지금 필요하다.
ex) 실무 사례
ex) 간트 차트를 써서 일정 관리하는 방법도 있다.
- 매니저의 역할: 매일 스크럼을 통해 매니징
- 이슈가 생기면 다른 사람이 투입되던가 업무 분담을 하던가 해야한다.
- 협업 관련 히스토리 관리, 태스크 관리...등은 히스토리가 퍼지지 않게끔 최소한의 도구만 사용하도록 한다.
기술 스택
- 기술 스택도 정리해보자. 기술 스택을 정하는 기준을 정리하는 게 좋다. 왜 그 기술을 사용했는지에 대한 답이 있어야 한다.
- 내가 이 프로젝트에서 무엇을 경험하고 싶은지에 대한 것을 결정하는 게 좋다. 무슨 기술을 쓰겠다 등등…challenging한 과제가 무엇일지…
- 기술 스택을 정할 때, 서로 이야기를 나누면서 눈치싸움을 한다.
- ex) 다 모르는 내용이면 내가 공부하고 팀원들에게 가르쳐준다.
- 프로젝트의 주제가 무엇인데 어떤 문제가 있었고 어떤 문제를 해결하기 위해 이 기술을 제안했고 그 기술을 채택해서 문제를 해결했다. 등등…의 내용이 이력서에 들어가야 한다.
- 프로젝트를 진행하면서 이력서를 작성해야한다. 어떤 시도를 했고 어떤 삽질을 했는지…
- 프론트엔드 단에서 프로젝트를 시작하는 게 처음인데, 실력적으로 부족해서 걱정이 됩니다! 최대한 프로젝트 전까지 열심히 공부하겠지만, 팀 프로젝트에서 개인의 부족한 부분을 어떤 식으로 커버할 수 있을까요?
멘토님 답변
- 실력적인 격차가 존재할 수 밖에 없다.
- 잘 못하는 사람들은 잘 하는 사람들이 어떻게 코드를 작성하는지를 살펴봐야 하고, 코드리뷰를 열심히 해야 한다.
- 코드를 많이 보면서 최대한 많은 시간을 들이는 게 필요하다... 결국 잘하는 사람보다 많은 시간을 들여야 잘 할 수 있게 된다..
- 그리고 코드를 왜 그렇게 작성하려 했는지... 그 코드가 어떤 의미를 갖는지... 물어보는 게 필요하다.
- 잘 하는 사람들은 그런 질문을 들었을 때, 설명하는 과정에서 많이 배워야 한다. 온전히 설명할 수 있어야 진정 내가 아는 내용이다.
- 열심히 질문 많이 하면서 기죽지말고, 더 성장할 수 있는 기회이니까 질문하는 것에 부끄러움이 없었으면 좋겠다.
(번외)
- 1md를 못하는 경우 경고를 해주어야 한다.
- 내가 열심히 하니 팀원들도 열심히 해야한다? 괜히 신경쓰이기 시작한다. 서로 부담주지 말고, 열심히 할 사람들은 열심히 하고.
- 내가 한 것만 면접관들이 질문하지는 않는다. 프로젝트 전반을 이해할 수 있어야 한다. 남이 짠 코드에 대한 공부를 해야한다…
- ex) 면접에서의 최악의 대답: 아 그부분은 제가 담당하지 않아서 잘 모르겠습니다.
- 프로젝트를 진행할때 기술스택을 정할때 팀원들과 의견이 맞지않을때 어떻게 설득해야할까요??
멘토님 답변
- 그것이 설득의 기술이다. 프로젝트에 반드시 필요한 기술이다라는 것을 어필하는게 중요하다.
- 모두가 새로 배워야 하는 기술은 2-3개를 넘지 않는게 좋다. 최신의 것만 가져가는 것은 의미가 없다.
- 각자 도전하고 싶은 기술들을 1-2가지 정도 가져와서 주장을 하고(실효성, 수치 등)를 제안해서 설득 해야한다. 남들이 반박하지 못하게끔 준비를 잘 해가면 된다.
- 데브코스에서 꼭 얻어가야 한다! 라는데 있을까요? (팀플, 네트워킹 등등…)
멘토님 답변
팀플 2개 반드시.
- 왜? 이력서에 적을 때 혼자 한 프로젝트 보다는 협업해서 한 프로젝트가 우선시 되는 경향이 있기 때문이다. 왜 그런 경향이 있을까?
- ex) 회사에서는 왜 프로젝트 경험을 이력서에 넣으라고 할까? 문제해결능력을 파악하려는 것이다.
- ex) 이력서 프로젝트 내용란에 메인 페이지 구현. => 어쩌라고?
- 내가 한 일들을 나열하는 게 아니라, 기술적이든 협업적이든 어떤 어려움을 겪었는지, 도전적인 과제를 어떻게 해결했는지에 대한 대답이 담겨있어야 한다.
- 개인 프로젝트에서 얻을 수 없는 경험들을 얻어가야한다. 외부에선 강제성이 없어서 프로젝트를 완성시키기가 힘들다.
- (데브코스 기간 동안) 정해진 시간 안에서 온전히 개발에 몰입하는 경험이 필요하다.
네트워킹
- 개발자 이직은 90% 인맥이다. (신입은 아닌거 같음)
- 연차가 높아질 수록 함께 일했을 때 좋았던 사람과 일하는 게 좋기 때문에…
- 장래를 위해서 네트워킹을 잘 해두면 경력자 이직에 좋다. 안 좋은 인상만 없으면 된다.
- 업계는 좁다
- 강사님과 멘토님과 친해지면 아주 좋다... 회사를 보는 관점. 회사의 소문. 등등... 회사 지원할 때 회사 어떤지... 이력서 첨삭도…
- 바짓가랑이 잡고 부탁하는 것을 부끄러워 하면 안된다... 데브코스 끝날 때 즘 도움이 많이 될 것이다.
- 공식문서, 독서 스터디를 진행할때 추천하는 방식있나요?
멘토님 답변
- 모여서 읽지 마라. 실용적이게 적용할 수 있는 책. 혼자하기 어려운 책을 선택하는 게 좋다.
- (ex) [리팩터링] 책. 리팩터링은 소프트웨어 공학적으로 프로그램의 기능은 동일한 데 코드만 바꾸는 것을 의미한다.
- 리팩터링은 기술이다. 어떤 관점에서 할 것인가. 어떻게 찢을 것인가. 각자 읽을 부분을 읽어와서 질문 같은걸 하는 식으로... 책 스터디는 내가 준비할 때와 준비안할때의 갭이 크다.
- 어떤 방법을 택하든 결국 어렵다. 어려우니까 시간을 투자하는 의미가 있는 것이다.
- useMemo와 useCallBack의 차이점을 잘모르겠습니당. useMemo는 리턴하는 값을 메모이제이션하고 useCallBack은 콜백함수 자체를 메모이제이션을한다는데..언제 어떻게써야할지 고민입니당.
- 말씀해주신 값과 함수 자체가 차이점입니다 ㅎㅎ 결국 둘 다 메모이제이션을 한다! 라는것이 중심이고 그 대상이 함수인지 값인지의 차이점입니다.
- 결국 함수나 값이나 부모에게서 받는 프로퍼티나 상태가 변경될 때 내부에 선언된 값들이나 함수들이 다시 재선언되지 않아도 되거나 재계산이 되지 않아도 될때 다시 발생하는 경우들이 있습니다.
- 사실 이런 동작들은 요즘 등장하고 있는 solid나 qwik같은데서는 자동으로 해주고 있어요 ㅎ.ㅎ 이런 이해가 어려운 부분들 때문에 과거에는 괜찮았지만 요즘 리액트가 욕을 많이 먹고 있습니다.
- 우선 메모이제이션을 한다는 것에 대한 의미를 알고 있는지! 이 글을 보고 먼저 정리를 해보시면 좋습니다.
- 메모이제이션에 대한 이해: https://d2.naver.com/helloworld/9223303
- useMemo와 useCallback에 대한 비교가 자세히 되어있는 글
- 간단한 둘의 비교로는 이 글도 나쁘지 않습니다.
- 이 글에서는 예시를 중점적으로 살펴보시는 것도 이해에 도움이 될 것 같습니다.
그럴때 디펜던시 어레이에 담긴 값이 변경되지 않으면 초기에 선언해둔, 계산해둔 값을 저장해두고 계속 씀으로써 반복되는 동작들을 줄여 효율을 높이게 됩니다