필독! 개발자 온보딩 가이드 서평
이직을 앞두고
이직을 코앞에 두고 어떤 공부를 해야 좋을까? 우선 이직할 회사의 기술 스택이 떠오른다. 기술 스택에 맞게 인강을 듣거나 책을 보는 등 가능한한 공부를 해야 당연하다는 생각이 든다. 하지만 소프트 스킬은? 업무 방식과 회사의 문화가 완전히 다를 텐데 그건 어떻게 대비해야 할까?
꼭 대비할 필요는 없다
본인은 불확실한 미래는 대비를 해야 직성이 풀리는 사람이고 직접 부딪히고 깨져보는게 타입인 사람은 꼭 대비할 필요는 없다고 생각한다.
모든 사람들이 서비스 회사에서 시작하는 건 아니다
나는 개발자로서 첫 커리어를 일반적인 IT 서비스 회사가 아닌 바이오 기업에서 시작했다. 일은 즐거웠지만 서비스 회사로의 이직을 앞두고 나는 내가 '잘' 일하고 있는 건지는 항상 의문이었다.
예를 들면 우리 회사는 도메인은 매우 복잡하고 업무 방식은 다소 경직되어 있는 편이었다. 놓여진 상황 속에서 최대한 바꿔보려고 모두가 노력했지만 어쩔 수 없이 안되는 부분도 많았다.
코드 리뷰, 배포, 설계, 온콜 등 전 회사에서 부족했던 부분은 언제나 내게 불안한 요소였다.
세상에 좋은 책은 많고 시간은 부족하다
세상에 좋은 책은 많다. 하지만 그걸 다 읽을 시간은 절대적으로 부족하다. 부족한 부분이 한 두 개도 아닌데 어떻게 한 번에 여러 권의 책을 읽을 수 있겠는가
이럴 때 개발자의 개괄적 길을 알려주는 좋은 책이 바로 이 개발자 온보딩 가이드 책이다. 처음에는 '온보딩'이라는 단어를 보고 새로운 회사에 적응하는 책인줄 알았다. 하지만 책을 읽으면서 온보딩이 온보딩 회사가 아닌 온보딩 개발자에 더 가깝다는 걸 느꼈다. 책은 개발자로서 첫 출발부터 학습, 코드 작성, 테스트, 배포, 온콜 등 개발자의 업무 사이클을 모두 다룬다.
모든 면을 다루다보니 깊이가 떨어지는 건 사실이지만 현재 내가 어떤 스킬이 부족하고 더 공부해야할지는 확실히 알 수 있다. 특히 챕터마다 말미에는 레벨업을 위한 읽을거리가 적혀있기 때문에 챕터를 읽으면서 내가 부족한 부분이라고 생각되면 다음에 읽을거리까지 체크할 수 있는 구성으로 되어있다.
실제로 아는 사람들이 이직을 한다면 꼭 권하고 싶은 책이다.
밑줄 긋기
운영 환경을 고려한 코드 작성
개발자의 필수 체크리스트
이것만은 지키자
- 런타임 에러보다는 컴파일 타임에 에러를 검출하자.
- 가능하면 불변 변수를 사용하자.
- 입력과 출력을 검증하자.
- OWASP가 발표하는 10대 웹 애플리케이션 취약점은 숙지해두자. ... (생략)
이것만은 피하자
- 예외를 이용해 애플리케이션 로직을 결정해서는 안 된다.
- 리턴 코드로 예외를 처리해서는 안 된다.
- 처리할 수 없는 예외는 잡지 말자.
- 로그를 여러줄로 나누지 말자 ... (생략)
포스트모텀 문서 작성은 장애를 처리하는 온콜 엔지니어의 책임이며 이 문서에는 장애의 원인, 장애를 통해 알게 된 내용, 향후 재발 방지를 위한 방안 등을 기록해야 한다. 포스트모텀 문서를 작성하는 방법과 템플릿은 다양하지만 아틀라시안의 템플릿이 좋은 예시가 될 것이다.
견고한 소프트웨어를 위한 기술 설계 절차
팀이 사용 중인 템플릿이 있다면 해당 템플릿을 사용하고, 없다면 다음 구조를 활용해보기 바란다.
- 개요
- 현재의 상태와 컨텍스트
- 변경해야 하는 이유
- 요구사항
- 고려할 수 있는 해결책
- 채택하려는 해결책
- 설계와 아키텍처
- 시스템 다이어그램
- UI/UX 변경
- 코드 변경
- API 변경
- 영속 계층 변경
- 테스트 계획
- 롤아웃 계획
- 미결 사항
- 부록