[리뷰] 필독! 개발자 온보딩 가이드 ~3장

< 책 정보 >

>

 

 

 

 

< 이 책을 읽게 된 계기 >

최근 새로운 기술들을 익히는 것에만 열중해서 지엽적인 관점으로 공부를 하다보니, 아직 배울 것도, 모르는 것도 많은 것 같아 막막함을 느꼈다.
그래서 현업 과정과 개발 과정의 과정을 개괄적으로 보고 싶었고, 개발자로서의 역량을 키울 수 있는 가이드가 되어줄 책이 필요했다.
책 제목 중 "온보딩 가이드" 라는 단어에서, 신입 개발자의 관점에서 현업 문화를 잘 설명해줄 것 같은 느낌을 받아 이 책을 읽게 되었다.

 

 

 

 

 

< 본문 핵심 >

 

1장. 여정을 시작하며

- 개발자로서 입사 후 겪게 되는 단계들을 설명하는 장이다 - 

 

 

모든 신입 개발자는 초보자 단계, 질풍노도의 성장 , 신뢰할 수 있는 기여자, 능력자의 단계를 거친다.

 

초보자의 단계에서는 회사와 팀, 그리고 업무 방식에 익숙해져야 한다 .

온보딩 회의에  참석하고, 개발 환경과 시스템 접근 권한을 셋업하고, 보편적인 팀의 절차들과 회의 일정을 파악해야한다.

이 시기에는 회사의 업무 수행 방식과 조직 구성, 협업 관계등을 파악한다.

 

 

질풍노도의 성장의 단계에서 팀을 위한 첫 번째 업무를 하게 된다.

기존의 코드베이스상에서 주로 작업하며, 코드를 빌드, 테스트, 배포하는 방법을 잘 살펴봐야 한다.

풀 리퀘스트와 코드 리뷰를 읽어보고, 기술 발표, 브라운 백, 멘토십 프로그램에 참여하는 것이 좋다.

 

 

신뢰할 수 있는 기여자의 단계에서 좀 더 규모가 큰 작업이나 기능 구현에 참여하게 된다.

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

팀 계획에 참여하고, 팀장과 혀법해 OKR(목표와 핵심 결과)을 설정한다.

 

 

능력자의 단계에서는 소규모 프로젝트를 스스로 주도할 수 있는 역량을 갖춘다.

기술 설계 문서를 작성하고 프로젝트 계획 수립을 거들어야 한다. 트레이드 오프를 생각하고 시간이 지나도 발전을 지속할 수 있는 시스템을 위한 계획을 세우자

유지 보수와 리팩터링 작업 사이에 균형을 찾는 방법을 배우게 된다.

 

 

 

 

 

 

2장. 역량을 높이는 의식적 노력

- 개발자로서 경쟁력을 갖추기 위한 방법들을 설명하는 장이다 -

 

 

소프트 엔지니어링 분야는 끊임없이 발전한다. 대학을 갓 졸업한 사람이든 노련한 경력자든 배움을 계속하지 않는다면 곧 뒤처지게 된다.  추천하는 학습 방법은 다음과 같다.

 

1. 직접 부딪혀보기 

: 문서를 읽어 배울 수 있는 것보다는 실전을 통해 배울 수 있는 것이 훨씬 많으므로, 코딩을 하고 결과물을 배포해야 한다.

 

2. 코드 동작을 이해하기 위해 다양한 실험을 해보기

: 디버거를 십분활용하여, 실행 중인 스레드, 스택 트레이스, 변숫값 등을 확인해본다.

예외를 던지거나 스택 트레이스를 출력해보거나, 로그를 기록해서 코드가 어떻게 동작하는지 파악한다.

 

3. 문서 읽는 습관을 들이기

매주 일정 시간을 할애해 팀 문서, 설계 문서, 코드, 티켓 백로그, 서적 기사, 기술 블로그 등을 읽어보자

 

4. 발표 영상을 찾아서 보자

튜토리얼, 기술 간담회, 컨퍼런스 발표 등을 확인하고, 기록하고 찾아보는 등 능동적인 자세로 시청한다.

 

5. 때로는 밋업과 컨퍼런스도 참여하자

컨퍼런스와 밋업에 참석하는 것은 네트워크를 구축하고 새로운 아이디어를 접할 수 있는 좋은 방법이다.

컨퍼런스는 학술 컨퍼런스, 관심주제 컨퍼런스, 벤더 쇼케이스 컨퍼런 스 등 세가지 유형이 있다.

 

 

 

 

 

 

3장. 코드와 함께 춤을

- 레거시 코드를 대하는 개발자의 자세에 대해 설명하는 장이다 -

 

 

 

기술 부채를 상환하는 방법

: 업무를 진행하면서 필요한 부분은 정리하고 조금씩 리팩터링을 하자. 변경 사항은 작고 독립적인 커밋과 PR (풀 리퀘스트) 로 만들자

 

기존 코드를 변경하는 단계는 다음과 같다.

 

1. 변경 지점을 확인한다.

2. 테스트 할 지점을 확인한다.

3. 의존성을 나눈다.

4. 테스트를 작성한다.

5. 변경을 적용하고 리팩터링한다.

 

이때, 의존성을 나누는 것은 테스트가 용이하지 않은 코드의 구조를 바꾼다는 뜻이다.

테스트 작성시에는 좀 더 쉽게 테스트 하려는 목적으로 접근제어자를 공개로 변경해서는 안된다. 테스트가 코드에 접근할 수 있지만, 캡슐화에 문제가 생기면 프로젝트에서 보장해야할 동작의 노출 범위가 커진다.

 

 

 

VCS (버전 제어 시스템)의 권장 기법을 활용하자

코드를 개발하는 동안 변경 사항은 일찍 그리고 자주 커밋해야 한다.

커밋을 자주 하면 시간의 흐름에 따라 코드가 어떻게 변화해가는지 볼수 있고, 변경을 되돌릴 수도 있으며, 원격 백업으로서 활용도 가능하다.

 

리뷰를 요청하기 전에는 브랜치를 리베이스하거나 커밋을 스쿼시해서 커밋 메시지를 명료하게 정리하자

 

'깃 커밋 메시지를 작성하는 7가지 요령' 은 다음과 같다.

1. 제목과 본문 사이에 빈 줄을 한 행 삽입한다.

2. 제목은 대문자로 쓴다.

3. 제목은 50자 이내로 제한한다.

4. 제목 끝에 마침표를 붙이지 않는다.

5. 제목은 명령형 문장으로 작성한다.

6. 본문의 각 행은 72자를 넘지 않게 한다.

7. 본문에는 코드가 어떻게 바뀌었는지보다 무슨 코드가 왜 바뀌었는지를 설명한다.

 

 

 

 

 

 

업스트림 커밋 없이 포크만 하는 것은 금물

포크란 다른 소스 코드 리포지토리에 대한 완전하며 독립적인 복사본으로, 자체 트렁트, 브랜치, 태그를 갖는다

깃허브와 같은 공유 플랫폼에서는 업스트림 리포지토리에 PR을 보내기 전에 해당 리포지토리를 포크한다.

포크를 해두면 해당 프로젝트의 주 리포지토리에 쓰기 권한이 없는 사람도 코드에 기여할 수 있다.

 

포크는 해당 프로젝트의 방향이 마음에 들지 않거나, 원래 프로젝트가 취소되거나, 주 리포지토리에 변경 사항을 병합하는 것을 허락받기 어려운 상황에 주로 포크한다.

 

하지만, 코드에 기여할 생각이 없으면서 해당 리포지노리를 포크하는 것은 권장되지 않는다. 

회사 내부에서 포크한 리포지토리를 관리하는 것은 위험한 일이기 때문이다.

 

 

 

 

 

코드 재작성에 대한 욕구를 견디자

기존 코드 리팩터링이 벅찬 나머지 기존 시스템을 통째로 날려버리고 새로 작성하면 어떨까하는 생각을 하지만, 코드를 새로 작성하는 것은 최후의 수단이라고 생각해야 한다.

코드 재작성은 들어가는 비용과 소요 비용이 생각보다 매우 크다. 특히 마이그레이션의 경우, 굉장히 오래 걸릴 수 있다.

 

 

 

 

 

< 후기 > 

신입 개발자에서 주니어, 시니어 개발자 마지막으로 CTO가 되기까지 수많은 배움과 노력이 필요하다는 것을 느꼈고,

개발자로서 계속해서 역량을 키우고 유지하기 위해서는 끊임없는 학습과 능동적인 자세의 중요성을 알게 되었다.

 

또, 학교에서 배우는 프로젝트와 달리, 현업에서 개발자로서 겪을 수 있는 시행 착오들을 알 수 있었는데, 

내가 진행했던 사이드 프로젝트의 경우, 각자 파트를 맡아 관련된 부분을 팀원 개인이 거의 맡아 하기 때문에, 기능 구현에만 초점이 맞추어져 있었고, 코드 리뷰도 거의 하지 않았었다.

하지만, 현업은 다른 부서와의 의견 조율, 트레이드 오프, 코드 가독성 등 고려해야할 부분이 많은 것 같다.

 

앞으로 개발할 때 커밋, 주석 등을 통해 코드 가독성을 높이도록 노력해야겠다.

또, 기회가 된다면 페어 프로그래밍을 경험해보는 것도 협업에 큰 도움이 될 것이라 생각했다.