- 학습 목표 1. "필독! 개발자 온보딩 가이드 - 레거시 코드에 임하는 우리의 자세" 정리
코드가 지저분해 지는 것
-
발생하는 이유
- 개발자가 다른 사람이 작성한 코드를 이해하지 못 함
- 서로 코딩 스타일이 다름
- 기술 스택과 제품 요구사항 개선
-
관리 방법
- 코딩 스타일 맞추기
- 버그 탐지 도구 사용하기
- 코드 리뷰
- 지속적인 리팩토링
기존 코드의 단점을 수정하면서 나중으로 미뤄둔 작업
트레이드 오프를 충분히 고려하고, 팀이 나중에 충분히 해결할 수 있는 문제라면 좋은 부채라고 할 수 있다.
그런데 이 부채때문에 서비스 기능이 정상적으로 동작하지 않거나 장애를 일으키면 이는 나쁜 기술 부채이다.
-
기술 부채를 상환하는 방법
- 상황을 사실 그대로 설명한다.
- 부채의 위험과 비용을 기술한다.
- 해결책을 제안한다.
- 대안에 대해 논의한다. (부채를 그냥 두는 방법 포함)
- 트레이드 오프를 따져본다.
-
기존 코드를 안전하게 수정하는 방법
- 변경 지점을 확인한다.
- 테스트할 지점을 확인한다. (수정하고자 하는 코드의 진입점)
- 의존성을 나눈다. (dependencies가 아닌, 코드 구조를 의미)
3-1. 기능을 최소한으로 나눠서 각기 분리된 기능이 독립적으로 수행될 수 있도록 - 테스트를 작성한다.
- 변경을 적용하고 리팩토링 한다.
- 되도록 검증된 기술을 사용하자
- "평범한 기술은 어디서 문제가 발생하는지가 잘 알려져 있다는 장점이 있다." - Dan McKinley
- 기술의 성숙도가 낮다는 것은 커뮤니티 규모가 작으며, 안정성도 낮고, 문서화도 미흡하며, 호환성도 낮다는 사실을 의미한다.
- 업스트림 커밋 없이 포크만 하는 것은 금물이다.
- 포크하여 작업하는 경우, 항상 업스트림 레포의 최신 버전이 반영되어 있어야 한다.
- 코드에 기여할 생각이 없으면서 해당 레포를 포크하는 것은 권장되지 않는다.
- 역시 책은 좋은 거 같다. 단순히 "A가 맞다"를 생각하고 있었는데 왜 A가 맞는지 뿌리부터 알 수 있는 느낌이 든다.
- 오픈소스에 기여해보고 싶은 생각이 들었다. 아직은 실력이 부족해서 당장은 어려울 수 있겠지만, 어떤 오픈소스들이 있는지부터 찾아봐야겠다