필독 개발자 온보딩 가이드 1장

1장을 읽고 정리

읽게 된 계기

트위터를 시작했다. sns는 잘 안했는데 트렌드를 읽고 좋은 개발자분들이 트위터에서 활동을 많이 하기에 개발용으로 1개의 계정을 만들었다. 거기서 추천하는 책들 중에 시니어 개발자의 잔소리랑 실무에 대해서 알 수 있다고 해서 교보문고에 가서 구매했다. 아직 2장까지 밖에 못 읽었는데 재미있고 모르는 내용도 알게 되어 잊지 않고 자주 보기 위해 적어보고자 작성하게 되었다.

혹시 문제가 있다면 삭제하겠습니다!

[1장] 여정을 시작하며, 개발자로서 첫 출발 앞으로 어떤 길이 펼쳐질까?

📌 목표를 세우자

1. 기술 지식

• 컴퓨터 과학의 기초 지식을 갖추자

🍀 통합 개발 환경(IDE), 빌드 시스템, 디버거, 테스트 프레임워크 등을 어떻게 사용하는지 알아여 하며, 지속적 통합, 지표 및 모니터링, 설정, 패키징 시스템 등도 능숙히 다룰 수 있어야 한다.

• 테스트 코드는 사전에 만들어 개선해야 하며, 아키텍처 차원에서 결정을 내릴 때는 운영측면도 고려

2. 실행력

• 코드를 이용해 문제를 해결함으로써 가치를 만들어내며 업무와 비즈니스 간의 연결고리도 이해

• 코드 작성 + 테스트, 코드 리뷰 + 긴급 대응 업무 교대 진행 + 운영 이슈 디버깅

🍀 주도적이면서 누군가에게는 의지할 만한 사람이 돼야 한다.

3. 의사소통

• 문서는 물론이거니 구두로도 명확하게 소통

• 피드백을 효과적으로 주고받으며 적극적으로 도움을 요청하고 모호한 상황에서는 명확한 정보를 요구 할 수 있어야 한다.

4. 리더쉽

• 범위가 잘 정의된 작업을 독립적으로 수행할 수 있어야 하며, 실수로부터 빠르게 배울 수 있어야 한다.

• 변화와 모호성을 잘 처리하며 프로젝트와 분기별 계획 수립에 적극적 임해야 한다.

📌 초보자

1. 온보딩 회의

🍀 회사와 팀 그리고 업무 방식에 익숙해져야 하며 온보딩 회의도 참석해야 한다.

• 회사가 OT가 없다면, 직속 팀장에게 조직도(담당 엄무, 인력 구성, 보고 체계 등), 타 부서 안내, 협업 관계 등을 설명해달라고 요청 후 메모해두자.

• 개발환경과 시스템 접근 권한을 셋업하고 보편적인 팀의 절차들과 회의 일정 파악

• 문서도 읽고 팀원들과 소통도 해야하며, 문서 오류를 수정하며 팀에 기여 해야한다.

2. 셋업 과정 문서로 남겨두자

• 추가적인 온보딩 절차(시스템 접근 권한 획득, 개발 환경의 셋업, 코드의 체크아웃 및 빌드)등을 갖춰지지 않은 회사라면, 내가 직접 만들어보자.

3. 현 조직의 업무 진행 절차를 개선하는 것이 아니라 이해하는 것이다.

• 작은 규모의 작업부터 해보자

• 주석 수정 같은 소소한 작업도 좋다.

4. 코드 편집기나 IDE를 셋업하자.

• IDE는 팀이 쓰는 것을 사용하며, 익숙하지 않다면 온라인 튜토리얼을 찾아보자.

• 필요하다면 팀에서 어떤 코딩 규칙을 세웠는지 그리고 어떻게 적용하면 되는지 물어보는 편이 좋다.

5. 팀장이 스탠드업 미팅, 스프린트 계획, 회고, 전사 회의 등 팀이나 회사 회의에 추가해뒀는지 확인하자

• 일대일 회의 제도가 있다면 팀장에게 일대일 회의 일정 잡아달라고 하자.

📌 질풍 노도의 성장

1. 모르는 점이 있다면 질문하고, 작업에 대해 자주 리뷰해줄 것을 팀에게 요청하자.

• 기초 작업을 완료했다면 기존의 코드베이스에서 작업한다.

• 모르는 점이 있다면 질문하고, 작업에 대해 자주 리뷰해줄 것을 팀에게 요청하자.

2. 학습 : 코드를 빌드, 테스트, 배포하는 방법을 잘 살표보자

• 풀 리퀘스트, 코드리뷰를 읽어보자.

• 꾸준한 학습 필요

3. 팀장은 주로 진척사항을 파악하길 원하므로 어떤 방식으로 현 상황을 공유할지 물어보자

4. 스프린트 계획 회의 시작하는 첫 번째 계획 회의 등에 참여 시, 회의에서 로드맵에 대한 개요난 개발 계획 절차에 대해 물어보자

📌 신뢰할 수 있는 기여자

더 큰 규모나 큰 작업이나 기능 구현 시 참여하게 되면 신뢰할 수 있는 기여자

1. 손쉽게 운영할 수 있는 프로덕션 수준의 코드를 작성하는 법, 의존성을 적절히 관리하는 방법, 깔끔한 테스트 코드를 작성하는 방법을 배우자

2. 다른 팀원을 돕고 도움받으며 피드백을 하며 받으며, 헷갈리는 문제가 있으며 항상 질문을 하자

3. 팀 계획에 참여하고 팀장과 협업해 OKR(목표와 핵심 결과)를 설정하자

📌 운영의 바다

참여하는 작업의 규모가 점점 커질 수록 코드가 사용자에게 전달되는 과정에 대해 더 많이 알게 될 것이다.

1. 코드 전달 과정에서는 테스트, 빌드, 릴리스, 배포, 롤아웃 등 많은 일이 일어난다. 스킬 필요

2. 변경사항 롤아웃 후에는 팀이 만든 소프트웨어 운영해야 한다.

• 각종 지표, 로그, 추적 도구 등을 이용해 실행 중인 소프트웨어를 디버깅하게 될 것이다.

• 어느 시점에는 긴급대응 온콜 대응 업무에도 합류하게 될 것이다.

• 소프트웨어 보호 방법도 배울 것이다.

📌 능력자의 땅

운영 후에는 팀은 우리가 소규모 프로젝트 정도는 스스로 주도할 수 있는 역량을 갖췄다고 생각할 것이다.

1. 기술 설계 문서를 작성하고 프로젝트 계획 수립도 거들어야 한다.

• 첫 설계에 안주하지 말고 트레이드오프를 생각하고 시간이 지나도 발전을 지속할 수 있는 시스템을 위한 계획을 세우자

2. 모든 것을 새로 재작성 시도는 하지 마는 것을 추천한다.

• 아키텍처, 빌드 및 배포 시스템, 테스트 환경의 결함 등이 눈에 띄게 되며, 그렇게 일상적인 업무 그리고 유지보수와 리팩터링 작업 사이에 균형을 찾는 방법을 배운다.

3. 팀장에게 의견 공유

4. 장기적인 목표 설정 후 성과 리뷰하며, 동료들에게 피드백 받자.

📌 정리하며

이 책... 취업하고 보니 신입은 초보자, 질풍 노도의 성장 이거랑 비슷하다는 것!!! + 중간 중간 상황 공유는 꼭 필요하다!!!