[신승준] 챕터 21: 의존성 관리

챕터_21/신승준.md

@@ -0,0 +1,39 @@
+# 의존성 관리
+
+소프트웨어 엔지니어링에서 이해도가 가장 낮고 가장 어려운 주제에 해당한다.
+
+> 그래서인지 패키지에 문제가 생겼을 때 막상 검색해보면 명확한 해결법을 제시하는 자료가 존재하지 않는 경우가 많았던 것 같아요.
+> 이럴 때 정말 LLM이 있어서 다행이라고 느끼네요.
+
+## 임포트 시 고려사항
+
+- 여러분이 실행할 수 있는 테스트가 있는 프로젝트인가
+- 테스트는 모두 통과하는가
+- 의존성 제공자는 누구인가
+- 지향하는 호환성 정책은 어떠한가
+- 인기 있는 프로젝트인가
+- 파괴적인 변경이 얼마나 빈번하게 행해지고 있는가
+
+> 실제로 회사에서 패키지들을 구축하거나 외부 패키지를 도입할 때 한 번쯤 해봤던 생각들이 많네요.
+
+## 유의적 버전(Semantic Versioning, SemVer)
+
+- 메이저: API가 변경되어 의존성을 이용하던 기존 코드를 깨뜨릴 수 있음
+- 마이너: 순수하게 기능 추가만 있음
+- 패치: 내부 구현 개선 및 버그 수정
+
+## 유의적 버전의 한계
+
+메이저, 마이너, 패치 등 버전의 숫자들이 호환성을 확실하게 보장해주진 않는다.
+
+ex. 1.1.4에서 1.2.0으로의 버전업, 즉 마이너 버전업은 API 추가와 버그 수정만 포함되었다는 소리이니 사용하는 측에서의 업그레이드는 안전하다고 보장할 수 있는가?
+
+## 의존성 내보내기
+
+공개한 의존성을 안정성 있게 지원한다면, 마음대로 수정하는 것이 어려워진다. 심지어 내부 용도와 맞지 않는 방향을 선택하도록 강요받을 수도 있다.
+
+> [tkdodo 형이 react-query에 mutationOptions가 추가되는 걸 싫어하던 기억이 나네요.](https://github.com/TanStack/query/discussions/6096)
+
+> [결국 굴복하시던 게 재밌었어요.](https://github.com/TanStack/query/discussions/6096#discussioncomment-12944553)
+
+> [그리고 실제로 추가까지 ㄷㄷ](https://github.com/TanStack/query/pull/8960)