사내 온보딩 가이드를 최신화하고 있는 찰나, 이 책이 출간되어 도움을 얻고자 읽게 되었다.
책을 읽고 새로 알게 된 내용에 대해서 정리해보려고 한다.
기술 부채를 상환하는 방법
- 단기적인 관점에서는 부채를 더 쌓아두면 제품의 출시가 빨라진다.
- 장기적인 관점에서는 부채를 해결하면 출시 속도가 빨라진다.
- 기술 부채를 논의하는 좋은 방법은 아래와 같은 방법으로 제안하고, 제안한 내용을 문서로 작성한다.
- 상황을 사실 그대로 설명한다.
- 부채의 위험과 비용을 기술한다.
- 해결책을 제안한다.
- (부채를 그대로 두는 방법을 비롯하여) 대안에 대해 논의한다.
- 트레이드오프를 따져본다.
사내에서 많은 제안들을 하고 있지만, 주로 슬랙과 같은 사내 메신저로 제안을 하다보니 일정 기간 이후에는 메시지가 사라진다.
그래서 나중에 어떤 것들을 제안했는지 검색해보면 검색이 되지 않았는데, 향후에는 제안한 내용들을 위키페이지로 만들어서 제안을 해야겠다.
레거시 코드 변경 알고리즘을 활용하자
- "레거시 코드 활용 전략"에서는 기존 코드를 안전하게 수정할 수 있는 과정을 다음과 같이 소개한다.
- 변경 지점을 확인한다.
- 테스트할 지점을 확인한다.
- 의존성을 나눈다.
- 코드의 동작이 바뀌어서는 안되기 때문에 원하는 입력값을 대입하여 기존과 동일한 결괏값을 가지는지 확인한다.
- 테스트를 위해 private 메서드와 변수를 public으로 변경하면, 테스트에는 접근할 수 있지만 캡슐화에 문제가 생기게 되며, 이로 인해 동작의 노출 범위가 커지게 된다.
- 테스트를 작성한다.
- 변경을 적용하고 리팩터링한다.
테스트 코드를 처음 도입했을 때 팀원분들에게 가장 많이 들었던 질문은 "private 함수는 어떻게 테스트해야하는가?" 이였다.
이에 대해서 private 함수를 새로운 클래스로 분리하는 것으로 제안하였다.
private 함수를 테스트하고 싶은 이유는 private 함수에 중요한 로직이 있다고 봐도 과언이 아니다.
중요한 로직일수록 테스트가 가능해야 하며, 테스트 케이스를 통해 이를 충분히 검증되어야한다.
버전 제어 시스템의 권장 기법을 활용하자
- 코드를 변경하여 커밋 시 "어떻게" 바뀌었는지보다는, "무슨" 코드가 "왜" 바뀌었는지를 설명하는 것이 좋다. - 깃 커밋 메시지를 작성하는 7가지 요령 중에서
모든 설정을 로그에 기록하고 검증하자
- 설정값을 로그에 기록하면 애플리케이션이 적절한 설정값을 로드했는지 여부를 확인할 수 있다.
- 설정값을 로드할 때에는 항상 검증해야 하며, 검증은 가능한 한 이른 시점(설정을 로드한 직후)에 한 번만 하면 된다.
최근 SharedPreferences를 DataStorePreferences로 마이그레이션을 진행하고 있다.
마이그레이션을 할 때 작업 단위로 로그를 출력하여, 마이그레이션이 잘 되고 있는지 확인한다.
마이그레이션이 아니더라도, 내부 저장소에 값을 설정 시 현재 내부 저장소에 저장된 값들을 로그로 출력하게해서 항상 검증을 해야겠다.
테스트를 꼭 해야 할까
- 의도치 않게 코드의 동작이 바뀌는 것을 방지하고 깔끔한 코드를 작성하게 도와준다.
- 문서 역할을 할 뿐 아니라 실험을 위한 공간으로서의 역할도 한다.
- 소프트웨어가 원하는 대로 동작하는지를 검증한다.
- 새로운 변경사항이 추가되도 기존 동작을 유지할 수 있는 방패막이가 되어준다.
- 미숙한 인터페이스 설계를 일찍 발견해서 수정할 수 있다.
테스트 코드를 작성하면 어떤 것이 좋을까? 라는 질문에 매끄럽게 대답하지 못하는 경우가 있어서 정리해보았다.
효과적인 버전 제어를 위한 브랜칭 전략
트렁크 기반 개발(Trunk-Based Develop)
- 개발자가 브랜치를 공유하지 않으며 시간 단위가 아닌 일 단위로 신속하게 트렁크로 머지하는 환경에 적합하다.
- 코드 베이스가 잘 동기화돼 있으면 마지막 순간에 통합하는 과정에서의 장애물을 피할 수 있으며, 버그나 호환성 문제도 일찍 발견할 수 있다.
- 반면, 트렁크에 버그가 존재하면 모든 개발자의 개발 속도가 느려진다.
- 항상 릴리즈 가능한 상태로 유지하며 릴리즈 또한 상당히 자주 일어난다.
사내에서 트렁크 기반 개발 전략을 사용하고 있다.
피쳐 브랜치 기반 개발에 너무 익숙한 나머지, 트렁크 기반 개발에 적응하기에 시간이 걸렸다.
내가 느낀 트렁크 기반 개발은 아래와 같은 장점은 아래와 같다.
- main 브랜치는 항상 릴리즈가 가능한 상태로 유지된다.
- conflict 발생 시 상대적으로 코드 수정이 적다.
- 브랜치의 수명이 짧게 유지된다.
단점은 아래와 같다.
- PR이 사슬처럼 연결되는 경우, 한번 conflict가 발생하기 시작하면 연결된 PR들 전부 rebase를 해야하므로 피로도가 높다.
- Github 기준 Squash 혹은 Rebase Merge 기능을 활용하기에 제약이 있다.
- Squash 혹은 Rebase Merge는 머지 시 commit id가 변경되므로, conflict가 발생할 확률이 높다.
- Git 또는 Github flow에 적합하지 않다.
기능 플래그를 활용하자
사내에서 트렁크 기반 개발 전략을 사용하고 있다보니, 자연스럽게 기능 플래그를 사용하고 있다.
기능이 완전히 구현되지 않았더라도 main 브랜치에 지속적으로 머지되지만, 기능 플래그를 끈 상태로 개발되기 때문에 배포를 하더라도 문제가 없다.
또한, main 브랜치는 데일리 QA를 통해 매일 검증을 진행하고 있기에, 기능이 완전히 구현되지 않더라도 안정성을 확보할 수 있다.
다만, 기능 구현 시 if문으로 감싸서 코드를 작성해야 하기 때문에 코드가 지저분해보일 수는 있다.
그리고 기능 플래그는 Remote Config와 같이 원격으로 관리하고 있어서, 기능에 문제가 발생하면 원격으로 해당 기능 플래그만 꺼서 영향범위를 최소화할 수 있다.
이직은 신중하게
- 이직을 자주 하면 여러분의 결정이 장기적으로 어떻게 작용하는지 확인할 길이 없어, 시니어 엔지니어로서 필요한 직관을 늘리는 데 방해가 된다.
- 잦은 이직은 모든 것이 장밋빛으로 보이는 시기가 지나고 상황이 어려워지면 여러분은 곧바로 이직할 거라고 우려하기 때문에, 채용 담당자가 좋게 보지 않는다.
- FOMO(Fear Of Missing Out)은 흔쾌한 이직 사유가 아니다.
- FOMO는 뒤처지는 것에 대한 강박적인 두려움을 말한다.
- 뒤처지는 것이 두렵다면 밋업과 컨퍼런스에 참석하면서 새로운 아이디어를 계속 접하라.
나 또한 그렇지만 이직 사유를 "성장하고 싶어서" 라고 말하는 사람이 많다.
면접을 봤었던 과거들을 떠올려보니, 이직 사유를 "성장"을 중점으로 진행했던 면접들은 대부분 탈락했던 것 같다.
