Item 28: Specify API stability

매번 다른 인터페이스와 마주하게 된다면 어렵고 힘들 것이다.

이는 프로그래밍에도 똑같다.

그래서 안정적이고 표준적인 Application Programming Interface (API)가 필요하다.

 

1. API가 바뀌고 개발자들이 update를 받으면, 그들의 코드를 수동으로 수정해야한다.

 이 API에 여러 의존적인 요소들이 많으면 문제가 될 가능성이 높다. 외부 라이브러리로 제공될 경우 어디서 어떻게 사용하는지 모르기 때문에 힘들다.

 유저 입장에서도 라이브러리의 API가 조금 바뀌면 사용하는 코드의 많은 곳을 수정해야할 수도 있다. 유저가 이러한 변화를 꺼리면 예전 버전을 오랫동안 사용하게 된다. 오래된 버전을 사용하게 되면 나중에는 업데이트를 하는 것이 점점 더 어려워지는 악순환으로 이어진다.

 

2. 유저들은 새로운 API를 공부해야한다.

 유저들은 이러한 상황에 에너지를 사용하고 싶어하지 않는다. 오래된 지식들이 보안이슈나 변화를 인지하기 어렵게 한다.

 

 다르게 말하면, 좋은 API를 설계하는 것은 굉장히 어렵다. 그래서 크리에이터들은 이를 개선하고자 한다. 가장 간단한 방법은 크리에이터들은 API나 그 일부가 불안정할 때 문서작업을 잘 정리해둘 필요가 있다. 좀 더 형식적으로 말하면 우리는 라이브러리나 모듈을 버전을 사용해 안정성을 관리한다.

 여러 버전관리 시스템이 있지만 그 중에 유명한게 Semantic Versioning (SemVer)이다. 그리고 이 시스템은, 버전을 3가지로 관리한다.

 

• Major 버전 : 호환이 되지 않는 API 변화가 있을 때.
• Minor 버전 : 하위호환을 보장하고 새로운 기능이 추가되었을 때.
• Patch 버전 : 하위호환을 보장하고 버그를 수정했을 때.

 Major 버전을 올리면 Minor, Patch 버전을 0으로 두고, Minor 버전을 올리면 Patch는 0부터 시작한다. Major 버전이 0인 경우는 보통 초기 개발에 사용하고, 안정적인 버전이라고 생각하지 않는다. 다만 beta로 오래 있는 것을 두려워하지 않아도 된다. Kotlin도 1.0에 도달하기 까지 5년이 걸렸다. 

 안정적이지 않은 기능을 제공할 경우에는 annotation을 사용해서 유저에게 알리도록 했다. 이를 통해서 deprecate될 API도 미리 알려줄 수 있다.