label(Integer)를 더하면 다시 빌드할 때 label(null)이 깨진다

새 이름으로 가죠. labelNumber(Integer value) 하나면 끝나요. 기존 호출부마다 null을 캐스팅하게 만들면 이번 변경과 상관없는 코드까지 비용이 번져요. 라이브러리 패치도 더 작게 끝나고요. 이름을 같이 쓰려면 메서드 목록이 깔끔해 보이는 것 말고 구체적인 이득이 있어야 하는데, 아직은 안 보여요.

산출물 두 개를 따로 둔다. 옛 선언으로 컴파일한 클라이언트 바이너리 하나. 그 소스는 재빌드용 픽스처로 보관한다. 둘은 서로 다른 질문에 답한다.

바이너리가 보여 주는 것은 옛 호출 지점이 어느 오버로드를 가리키는지뿐이다. 메서드 본문이 바뀌었다면 그건 그것대로 검토한다. 이번 릴리스의 증거는 옛 바이너리 실행 결과와 label(null)을 포함한 소스 재빌드 결과다. 어느 쪽도 다른 쪽을 대신하지 않는다.

동의해요. 그리고 다음에 그 호출부를 고칠 사람에게도 이득이 있어요. labelNumber(null)이라고 쓰면 어떤 동작을 의도했는지 바로 보여요. label(null)에 캐스트를 붙여도 예전 선택은 유지되지만, 나중에 읽는 사람 눈에는 군더더기 같아요. 코드를 정리하던 누군가가 불필요하다고 지우면 빌드가 다시 깨져요. 캐스트 쪽으로 간다면 마이그레이션 노트에 그 캐스트가 왜 있는지 한 줄 적어 두는 게 좋겠어요.

별도 이름이 무난한 기본값이라는 데는 동의합니다. 그래도 마이그레이션 안내는 원하는 것이 서로 다른 두 호출자를 구분해야 합니다. 예전 문자열 동작을 원하는 호출자는 label((String) null)이라고 쓰면 됩니다. 새 숫자 연산을 원하는 호출자는 숫자용 메서드를 호출해야 합니다. 둘 다 모호성을 없애지만 같은 수정은 아닙니다.

오버로드를 둘 가치가 있는 경우는, 타입이 정해진 인자를 넘기는 호출자에게 같은 이름이 두 연산의 관계를 유용하게 알려 줄 때뿐입니다. 그렇다면 릴리스 노트에 깨지는 null 호출과 그 명시적 수정, 기존 바이너리에 관한 설명을 나란히 보여야 합니다. 그 관계를 실제 용례로 설명하지 못한다면 labelNumber가 낫습니다. 메서드 목록을 가지런하게 보이려고 기존 호출자에게 소스 수정을 떠넘기지 않으니까요.