- 운전 방법은 안정적이면서 표준적인 것이 좋음
- 프로그래밍에서도 안정적이고 최대한 표준적인 API(Application Programming Interface)를 선호
- 라이브러리가 변경되어도 이전 라이브러리를 유지하는 경우가 많음
- 따라서 개발자가 안정적인 라이브러리로 업데이트하는 것을 두려워한다는 것은 매우 좋지 않은 상황
- 처음부터 안정적이지 않은 모듈을 많이 공부하는 것보다는 안정적인 모듈부터 공부해 두는것이 좋음
- 작성자가 ‘API' 또는 ‘API의 일부’가 불안정하다면, 이를 명확하게 알려 줘야 함.
- 일반적으로 버전을 활용해서 라이브러리와 모듈의 안정성을 나타냄
- 많은 버저닝 시스템 (versioningsystem)이 있지만, 일반적으로는 시멘틱 버저닝(Semantic Versioning, SemVer)을 사용함
- MAJOR 버전: 호환되지 않는 수준의 API 변경
- MINOR 버전: 이전 변경과 호환되는 기능을 추가
- PATCH 버전간단한버그수정
- MAJOR를 증가시킬 때는 MINOR와 PATCH를 0으로 돌려두고 MINOR를 중가시킬 때는 PATCH를 0으로 돌려둠
- 0인 경우(0.y.z)는 초기 개발 전용 버전을 의미하며 언제든지 변경될 수 있어 안정적이지 않다는 의미
- Experimental 메타 어노테이션을 붙이면 요소를 보고 사용할 수 있지만, 사용할 때 경고 또는 오류가 출력됨
- 실험적 기능으로 유지하는 것을 두려워하지 말기. 채택 속도 는느려지지만, 더 오래 동안좋은 API를설계하는 데 도움이 됨
- 안정적인 API의 일부를 변경해야 한다면, 전환하는 시간을 두고 Deprecated 어노테이션을 활용해서 사용자에게 미 리 알려 줘야 함
- 직접적인 대안(direct alternative)이 있다면, IDE가 자동 전환을 할 수 있게 ReplaceWith를 붙여 주는 것도 좋음
- 직접적인 대안(direct alternative)이 있다면, IDE가 자동 전환을 할 수 있게 ReplaceWith를 붙여 주는 것도 좋음
- 커뮤니케이션은 버전 이름, 문서, 어노테이션등을 통해 할수 있음