크리스 리코미니 · 드미트리 리아보이 - 『The Missing README』

읽은 기간: 2023.8.22 ~ 2023.9.30

원제 - The Missing README: A Guide for the New Software Engineer

번역본 제목 - 필독! 개발자 온보딩 가이드

사실 원제 Missing README 에 더 혹해서 제목에 넣었다.

 

개발자 조립하기

이 책은 우리 팀의 프린스펄 엔지니어였던 장현희 님이 번역하고서 팀 개발자들에게 선물로 남겨주신 책이다.

이 책은 나에게 『프로그래머의 길, 멘토에게 묻다』, 『커리어 스킬』에 이어

벌써 3번째 개발자 온보딩 가이드 책이 되어주었다.

 

개발자 온보딩 가이드 책의 좋은 점은 믿고 참고할 수 있는 로드맵이 되어준다는 점이다.

같은 책을 여러 번 읽어도 독자가 어떤 시기에 읽었는지에 따라 감상이 많이 달라질 수 있는 것처럼,

얼핏 비슷해 보이는 부류의 책들이라도 언제 어느 책을 읽었느냐에 따라 배우는 것들이 또 많이 달라진다.

이 책을 읽을 때도 이미 알고 있는 내용들이 많았다.

하지만 새로 배우는 것들도 만만치 않게 많았고,

예전에는 잘 이해하지 못했던 것들도 다시금 되새겨보며 이해하게 되는 것들도 있었다.

반기별로 한번씩 딱 읽어주면 스스로가 알고 있는 것들이 어느 정도이며,

경력을 쌓아 올리기 위한 준비가 얼마나 되어 있는지를 깨우치기에도 좋다.

그러니 이미 읽었던 책과 똑같은 부류의 책이라고 배척하지 말고, 그 안에서 어떻게든 배울 점들을 찾자.

 

새로 알게 된 내용들

software entropy

• 코드를 여기저기 바꾸다가 자연스럽게 지저분해지는 현상
• 서로의 코딩 스타일이 다르거나, 기술 스택, 요구사항, 버그, 성능 최적화가 있을 때 생기곤 함
• 해결책: 버그 탐지 도구 사용, 코드 리뷰, 지속적인 리팩토링

technical dept

• software entropy를 가중시키는 요인
• 기존 코드의 단점을 수정하면서 나중으로 미뤄둔 작업들
• 원금과 이자를 생각할 것
  • 원금: 수정해야 할 원래의 단점
  • 이자: 단점을 수정하지 않고 코드를 발생할 때의 비용
• 레거시 코드에는 수많은 기술적 부채가 존재
• 프로젝트가 지저분해질 정도로 오래 살아남았다는 좋은 표시일 수 있다!

테스트를 더 촘촘하게

• 테스트 종류
  • 단위 테스트: 작은 동작에 대한 집중적인 테스트
  • 통합 테스트: 여러 컴포넌트를 함께 테스트
  • 시스템 테스트: 시스템 전체의 end-to-end 검증
  • 인수 테스트: 사용자의 인수 조건을 만족하는지 검증
• 테스트 도구
  • 모킹 라이브러리: 객체지향 코드의 단위 테스트에서 인터페이스를 모방하는 stub을 활용하게 해 줌
  • 테스트 프레임워크: 사전 셋업, 사후 해제, 검증 메소드, 코드 커버리지 도구와의 통합 기능 제공
• 입력이 같으면 출력도 항상 같은 결정적 코드 작성을 위한 팁
  • 시드값 사용: 난수 생성기가 있는 경우 난수를 고정하기 위한 시드값을 사용하자
  • 원격 시스템 호출 자제: 단위 테스트에서 하지 말고 통합 테스트에서 하자
  • 클럭: 시간값에 의존하는 경우 클럭을 사용해서 시간값을 고정하자
  • 0번 포트: 0번 포트를 지정하면 OS에서 사용 가능한 포트를 자동으로 열어줌

이 밖에도 빌드 → 릴리스 → 배포 → 롤아웃으로 이어지는 딜리버리의 4단계,

온콜 업무, 기술 설계 절차, 진화하는 아키텍처에 대한 부분들이 특히 인상 깊었다.

하지만 이걸 전부 다시 정리하면 지면이 너무 길어지니 이만 줄여야겠다.

https://github.com/nmin11/TIL/tree/main/Soft%20Skill/the-missing-readme

 

로드맵 바로잡기

나도 벌써 일해온 경력이 쌓여서 어느덧 1년 차 개발자가 되었다.

그런 만큼 이제는 이런 책을 읽으며 '아, 이런 게 있구나!' 에서 그칠 것이 아니라,

지금 내 상황에서 어떤 것들이 필요할지, 어떻게 더 효율적으로 경력을 쌓을 수 있을지 고민해봐야 한다.

 

내가 이번 책에서 특히 인상 깊었던 부분들은 테스트, 소프트웨어 딜리버리, 진화하는 아키텍처 관련 내용들이었다.

이런 부분들을 내가 어떻게 보강할 수 있을까?

역시 사이드 프로젝트가 답이라는 생각이 든다.

하지만 현재 나는 이미 채용 사이트 크롤링 관련 사이드 프로젝트를 구현하고 있다.

게다가 사실은 이 크롤링 작업 및 CLI 화면 구현이 난이도가 생각보다 빡세서 고전을 면치 못하고 있다.

지금 와서 드는 생각은, 구현 난이도가 보다 단순한 사이드 프로젝트를 만들면서,

테스트나 배포 자동화에 대한 공부를 더 깊게 해 보면 어떨까 하는 생각이다.

솔직히 이제 와서 기존의 프로젝트를 포기하고 싶지도 않다.

그러니 이번 사이드 프로젝트는 '작동하는 소프트웨어 만들기' 에 집중해서 빨리 끝내는 데에 초점을 두자.

'이거 재밌겠다!' 하는 마인드로만 사이드 프로젝트를 밀어붙이지 말자는 얘기다.

그리고 다음에 또 사이드 프로젝트를 만들 때에는 내가 정말 필요로 하는 학습 범위에 집중할 수 있도록 하자.