프로그래밍에서는 안정적이고 표준적인 API(Application Programming Interface)를 선호한다.
- API가 변경되고 개발자가 이를 업데이트했다면 여러 코드를 수정으로 업데이트해야한다.
이 때, 많은 요소가 이 API에 의존하고 있다면 큰 문제가 된다. 특히 다른 개발자가 API를 사용한 경우에는 익숙하지도 않아 어려울 것이고 변경 대응이나 대안 찾는 것도 어려울 것이다.
라이브러리의 작은 변경은 이를 활용하는 다른 코드들의 많은 부분을 변경하게 만들 수 있어 이전 라이브러리를 유지하는 경우도 많다. 그치만 이럴수록 업데이트는 어려워지고 버그, 취약성 등이 발생할 수 있다.
따라서 안정적인 라이브러리로 업데이트하는 것을 두려워하는 건 좋지 않다.
- 사용자가 새로운 API를 배워야 한다.
처음부터 안정적이지 않은 모듈을 많이 공부하는 것보다 안정적인 모듈부터 공부해두는 것이 좋다.
하지만 좋은 API를 한 번에 설계할 수는 없다. 그래서 개선하기 위해 변경을 하기 떄문에 이를 안정적으로 유지하기 위한 의견을 제시해서 균형을 맞춰보자
일반적으로 버저닝을 통해 모듈의 안정성을 나타낸다. 많은 버저닝 시스템이 있지만 일반적으로는 MAJOR, MINOR, PATCH로 나뉘어 구성된 시맨틴 버저닝을 사용한다.
- MAJOR 버전: 호환되지 않은 수준의 API 변경
- MINOR 버전: 이전 변경과 호환되는 기능을 추가
- PATCH 버전: 간단한 버그 수정
각각의 부분은 0 이상의 정수로 구성되고 변경사항이 있을 때 1씩 증가시킨다. MAJOR를 증가시킬 떄는 MINOR, PATCH를 0으로 MINOR를 증가시킬 땐 PATCH를 0으로 돌려둔다.
또한, 베타 버전이 오래 유지되는 것을 싫어하는 사람들이 있지만 코틀린도 1.0 버전까지 도달하는 데 5년 이상의 시간이 걸렸다. 그리고 그 과정에서 많은 것이 바뀌어 코틀린에게는 굉장히 중요한 시기라고 할 수 있다.
그리고 새로운 요소를 추가할 때 Annotion를 잘 쓰자!
-
@Experimental: 아직 해당 요소가 안정적이지 않다. -> 경고 또는 오류(설정된 레벨에 따라 다름)가 출력됨 -
@Deprecated: 전환하는데 시간을 두게끔 해당 함수는 곧 제거된다고 넛지 -
@ReplaceWith: 직접적인 대안이 있다면 IDE가 자동 전환할 수 있게 사용
이런 식으로 사용자에게 노티를 줘서 변경에 적응할 시간을 주는데, 때론 널리 쓰이는 API는 최신/안정적 버전으로 적용 시간을 몇 년으로 잡기도 한다.
정리
사용자는 API의 안정성에 잘 알자. 안정적인 API를 사용하는 것이 좋다. 다만 이 안정적인 API에서 예상치 못한 변경이 일어났다면 가장 나쁜 상황이다. 이런 변경은 수많은 사용자에게 고통을 줄 수 있기 떄문이다.
모듈과 라이브러리를 만드는 사람과 이를 사용하는 사람들 사이에 커뮤니케이션이 중요하다. 커뮤니케이션은 버전 이름, 문서, 어노테이션 등을 통해 할 수 있다. 또한, 안정적인 API에 변경을 가할 때는 사용자가 적응할 충분한 시간을 줘야 한다.
