더 이상 사용되지 않는 메소드를 삭제하기 전에 얼마나 걸립니까? [닫은]

38

공용 API를 유지 관리하고 메소드를 더 이상 사용하지 않아야합니다.

삭제하기 전에 몇 개월 / 년 / 버전 수에 대한 일반적인 규칙이 있습니까?

java deprecation

— deviDave
소스

27

일반적인 규칙은 "귀하 및 / 또는 고객이 필요로하는 한 유지하십시오"입니다.

— Robert Harvey

15

"공개"를 정의하십시오. 일반적인 "자신의 책임하에 사용"면책 조항이있는 무료 오픈 소스 소프트웨어 아니면 계약이 존재하는 소프트웨어를 판매 했습니까?

— Doc Brown

11

이는 사용자가 어떤 시장에 있는지와 API 비용을 지불하는지 여부에 달려 있습니다.

— 17 of 26

10

또한 감가 상각을하는 이유가 무엇인지에 따라 다릅니다. 옛날 방식은 보안 위험입니까? 불행히도 불행한 설계 결정으로 인해 이전 방식이 근본적으로 그리고 고정적으로 불안정한 이유를 찾았습니까? 옛날 방식이 예전보다 훨씬 느려 집니까? 대상 시스템 (예 : 임베디드 시스템)에 메모리가 부족하고 문자 그대로 두 API를 모두 사용할 수 없습니까? 아니면 "더 나은"방법을 찾고 유지 관리 오버 헤드를 줄이기 위해 이전 코드를 정리하고 싶습니까?

— jrh

8

java.io.StringBufferInputStreamJDK 1.1 (1997?) 이후로 사용되지 않습니다. 이 질문에 대한 옳고 그른 대답은 없습니다. 이전 버전과의 호환성을 제공해야 할 필요에 따라 다릅니다.

— Laiv

52

최소한 사용하지 않는 메소드를 제거하기 전에 한 버전으로 유지해야합니다. 최대 시간이 없다고 생각하지만 실제로 제거하지 않으면 사용 중단이 약간 의미가 없습니다.

주요 버전 릴리스는 더 이상 사용되지 않는 메소드를 제거하기에 좋은시기입니다. 부 릴리스에는 일반적으로 주요 변경 사항이 포함되어서는 안됩니다. cHao가 의견에서 언급했듯이, 사용 중단이 반드시 삭제 될 것이라는 것을 의미하지는 않으므로 사용 중단 후 삭제하려는 경우 명시 적으로 메모하고 타임 라인에 대한 지침을 제공해야합니다.

— 지미 제임스
소스

58

지원 중단은 반드시 최종 삭제에 대한 것은 아니므로 제거하지 않은 지원 중단은 의미가 없습니다 (역 호환성이 중요한 경우에는 종종 올바른 일임). 종종 요점은 "지금 우리가 더 나은 방법을 가지고 있기 때문에 더 이상이 방법을 사용해서는 안됩니다"라는 의미 일뿐입니다.

— cHao

9

@cHao 더 이상 사용되지 않는 항목이 계속있을 것으로 예상해서는 안됩니다. 프로젝트에서 더 이상 사용되지 않는 기능을 제거하지 않을 것이라는 특별한 진술을하고 싶다면 괜찮습니다. 그렇지 않으면 결국 제거 될 것입니다. 내가하고 싶은 요점은 당신이 이것에 대해 어떤 종류의 엄격함을 유지하지 않으면 사람들은 그것이 결코 일어나지 않을 것이라고 믿게 될 수 있다는 것입니다. 10 년 이상 사용되지 않는 기능이 현재 제거되고있는 최신 버전의 Java가 등장했습니다.

— JimmyJames

6

@cHao 차라리 프로젝트는 더 이상 사용되지 않는 기능을 제거하고 싶습니다. 사용자가 실제로 전환 동기를 부여하는 것의 이점이있을뿐만 아니라 더 이상 사용되지 않는 인터페이스가 다른 개선 사항을 방해하지 못하게합니다.

— jpmc26

9

@cHao 상황에 맞는 것입니다. 저의 경험에 따르면 사용 중단 정책이 명확합니다. 더 이상 사용되지 않는 기능은 향후 언젠가 제거 될 것이라고 명시되어 있습니다. 더 이상 사용되지 않는 기능에 문제가 발생하는 경우가 많으며 단순히 이전 버전과의 호환성을 중요시 하는가의 문제가 아닙니다.

— JimmyJames

6

@JimmyJames에 동의하지 않기 위해 더 이상 사용하지 않을 예정입니다. 사용 중단 기간은 일시적인 이전 버전과의 호환성을 제공하는 방식으로 존재하므로 소비자는 새로운 기능으로 마이그레이션 할 수 있습니다. 더 이상 사용되지 않는 기능이 무기한으로 유지 될 것으로 기 대해서는 안됩니다. 이전 기능이 그대로 유지되면 더 이상 사용하지 않을 이유가 없습니다.

— 에릭 킹

17

이것은 사용자에게 어떤 종류의 안정성을 보장하고 사용자에게 얼마나 많은 고통을 주길 원하는지에 달려 있습니다.

이상적으로 API는 semver를 사용 하므로 주요 변경 사항으로 인해 주요 버전 번호가 증가합니다. 실제로이 작업은 거의 수행하지 않는 것이 좋습니다. API가 일부 패키지 관리자를 통해 설치된 경우 간단한 업그레이드로 인해 충돌이 발생하지 않도록 변경 후 새로운 패키지 이름을 만들 수 있습니다 (예 : myapi2 v2.123.4vs myapi3 v3.2.1). 패키지 관리자가 더 엄격한 버전 종속성 (예 :를 ~v2.120포함하지 않는 종속성 사양)을 지원하는 경우 불필요 할 수 v3.*있지만 서로 다른 패키지 이름은 호환되지 않는 버전을 아주 쉽게 사용할 수 있다는 장점이 있습니다. semver를 사용하는 경우에도 더 이상 사용되지 않는 기간이있을 수 있습니다.

Semver가 항상 적용 가능한 것은 아닙니다. 그런 다음 명확한 안정성 정책을 전달하는 것이 더 중요합니다. 예를 들면 다음과 같습니다.

실험 기능은 사전 통지없이 제거 될 수 있습니다.
보안상의 이유로 언제든지 기능이 제거 될 수 있습니다.
다른 기능은 제거됩니다
- … 출시 된 버전에서 더 이상 사용되지 않는 경우
- … 해당 버전이 최소 3 개월 이상인 경우
- … 그리고 메이저 버전에서 충돌로 표시 될 것입니다.

이러한 정책은 정식 릴리스가있을 때 특히 효과적이므로 사용 중단 기간 (예 : 1 년)이 명확합니다.

더 이상 사용되지 않는 것으로 API의 일부를 표시하는 것 외에도 더 이상 사용되지 않음을 널리 알려야합니다. 예를 들면 다음과 같습니다.

향후 지침 및 지원 중단에 대한 변경 내역 섹션을 변경 로그에 작성하십시오.
지원 중단을 수행하기 전에 지원 중단 의사를 알리고 커뮤니티에 귀를 기울여 실질적인 이의가 있는지 확인하십시오.
이러한 변경으로 인해 어떤 이점이 있을지 알려주십시오. 사용자 기반에 따라 뉴스 레터, 프리젠 테이션, 블로그 게시물 또는 보도 자료가 적절한 미디어 일 수 있습니다. 스핀을 가지고“우리는 멋진 새로운 기능을 만들고 있습니다! (이 널리 사용되는 오래된 기능을 제거해야 함)”은 컨텍스트없이 기능을 제거하는 것보다 조금 덜 실망 스럽습니다.

정확한 지원 중단 기간을 선택하려면 먼저 사용자와의 지원 계약을 준수해야하는지 확인하십시오. 이러한 계약은 일정 기간 동안 호환성을 유지해야 할 수도 있습니다. 그렇지 않은 경우 다운 스트림 영향을 고려하십시오. 다운 스트림 사용자보다 속도가 느리게 변경되어 더 이상 사용되지 않는주기를 거칠 수 있습니다. 다운 스트림 사용자는 변경 사항에 적응하는 데 약간의 시간이 걸리므로 사용 중단 기간이 한 달보다 짧아서는 안됩니다.

— 아몬
소스

3

이로 인해 하향 조정 :

Ideally, your API uses semver so that any breaking change causes the major version number to be incremented. In practice, it is desirable to do this almost never.

새로운 메이저 버전을 도입해서는 안된다고 말하면서 semver를 사용하여 변경 사항을 위반하는 것을 나타내는 요점은 무엇입니까?

— mrsmn

6

주요 변경 사항이있는 경우 패키지 이름을 바꾸는 것이 실제로 좋은 생각입니까? 그것이 버전 번호입니다. 나는 그들이 또한 그들을 이름을 바꿀 때 싫어, 그것은 실제로 Maven 의존성 관리를 망칩니다.

— AJPerez

@ AJPerez 이상적이지 않다는 것을 이해하지만 전이 종속성과 함께 큰 종속성 그래프에서 충돌을 방지 할 수 있습니다 : 나는 libconflict v1.2.3에 의존하는 libfoo에 의존하며 libconflict v2.3.4에 의존하는 libbar에 의존합니다. 그런 다음 libconflict와 libconflict2가 별개의 패키지가 아닌 한 모든 종속성을 만족하는 libconflict 버전을 선택할 수 없습니다. 특히 Java의 경우 이러한 이름 바꾸기는 성가신 b / c 모든 수입품을 변경해야합니다. 다행히 Java 9 (모듈)는 충돌 버전 사용을 지원합니다.

— amon

1

@mrsmn 주요 변경 사항은 성가 시지만 패키지 또는 이름을 지정하십시오. Semver는이 문제의 일부만 해결합니다. 업그레이드로 인해 문제가 발생하는지 여부를 알 수 있습니다. 그러나 중요한 변화가 있더라도 여전히이 변화를 수용하기 위해 노력해야합니다. 따라서 가능한 한 안정적으로 API를 시도하는 것이 좋습니다. 이상적으로는 이전 버전과의 호환성을 유지하면서 확장 할 수 있도록 설계되었습니다.

— amon

@AJPerez 네. 예, 좋습니다. 사람들은 항상 버전 관리를 망칩니다. 버그 수정 (xxx ++로 추정 됨)이 종종 깨집니다 (x ++. xx로 추정 됨). amon이 지적했듯이 (그리고 나는 의존성의 사용자 라는 것을 의미 합니다 ) 해결해야 할 문제가 있습니다. 내 코드가 foo 3.2.1에서 작동 한다는 것을 알고 있습니다 . foo 3.3.0에서 작동 할 수 있습니다. 내 코드가 foo와 작동한다는 것을 알고 있습니다 . foo-2와 작동 할 수 있습니다. 나는 인기가 있기 때문에 semver를 사용하고 그 자체로 상처를 입지 않지만 실제로 그것이 당신을 그렇게 많이 사 준다는 것이 분명하지 않습니다.

— Jared Smith

14

이상적으로는 더 이상 사용되지 않는 방법을 사용하지 않을 때까지 기다리는 것이 좋습니다. 퍼블릭 API를 사용하는 것을 고려하면 추적하기 쉽지만 시간이 오래 걸릴 수 있습니다.

2015 년 Google은 Android OS의 stlport API와 비슷한 문제를 겪었습니다. 그들은 더 이상 사용하지 않아 제거하고 싶었지만 수많은 앱이 여전히 사용하고있었습니다. 그들은 영리한 해결책을 찾았습니다.

본질적으로 개발자를 위해 적절한 로그 메시지와 함께 API를 사용한 앱을 부팅하는 동안 8 초 sleep ()을 추가했습니다. 한 달 후, 그들은 그것을 16 초로 두 배로 늘 렸습니다. 또 한 달 뒤 API 인터페이스를 사용하는 사람이 없기 때문에 API 인터페이스를 안전하게 제거 할 수있었습니다.

이것은 매우 효과적인 방법입니다. 유일한 문제는 API가 매우 오래되어 더 이상 적극적으로 지원되지 않는 소비자를 적극적으로 사용한 경우입니다. 불행히도, 아마도 그러한 소비자를 스스로 고칠 수는 없지만 그 시점에서 메소드를 삭제하고 소비자를 파괴하는 것 이상을 실제로 할 수는 없습니다.

— 은잘
소스

5

귀엽다. 매우 귀엽다.

— David Hammen

8

더 이상 사용되지 않는 메소드를 제공하는 최소 시간은 API를 사용하는 프로그램의 개발주기에 따라 다릅니다. 야구장으로서 1 년이면 충분합니다.

더 이상 사용되지 않는 메소드를 제거하기 전에 최대 시간에 대해서는 그런 것이 없다고 주장합니다. 얼마나 오래 기다리더라도 더 이상 사용되지 않는 메소드를 제거하면 항상 문제가 발생합니다. 더 이상 사용되지 않는 API를 사용하는 일부 프로그램은 적극적으로 유지 관리되지 않으며 호환성을 깨 뜨리면 해당 프로그램의 수명이 종료됩니다.

제거 에서 무언가 를 얻을 때 더 이상 사용되지 않는 메소드를 제거하는 것이 좋습니다 .

더 이상 사용되지 않는 메소드에 영향을주는 버그가 발견되었습니다.
코드를 리팩토링하려고하고 더 이상 사용되지 않는 메소드를 유지 보수하려면 상당한 노력이 필요합니다.
라이브러리의 내부 구조를 최적화하고 있으며 더 이상 사용되지 않는 메소드는 더 이상 적합하지 않습니다.

더 이상 사용되지 않는 메소드는 X 개월 / 년 동안 더 이상 사용되지 않거나 새로운 버전을 릴리스하기 때문에 정당한 이유없이 호환성을 임의로 손상시킵니다.

— 드미트리 그리고 리 예프
소스

7

먼저 더 이상 사용되지 않거나 사용하지 않을 것인지 고려해야합니다.

보안, 성능, 잘못된 결과 등 어떤 방식 으로든 위험한 방법에는 더 이상 사용되지 않습니다. 당신은 그것들을 상대적으로 빠르게 제거하고 싶어합니다. 심각한 문제가 발생할 경우 다음 부 버전에서 더 이상 사용되지 않을 수 있습니다.

더 이상 사용되지 않는 정보, 예를 들어 적은 정보를 반환하거나 제대로 작동하지 않거나 많은 옵션 등을 포함하지 않는 등 쓸모없는 것입니다. 이것들은 무기한으로 매달려있을 수 있지만 최소한 다음 주요 버전에서는 존재해야합니다.

— 즈 모레노
소스

잘못된 결과를 제공하거나 보안을 손상시키는 방법은 즉시 비활성화하거나 수정해야한다고 말하고 싶습니다. 성능이 좋지 않은 방법은 성능이 일부 사용자에게 허용되는 한 무기한으로 정지 될 수 있습니다.

— Dmitry Grigoryev

@DmitryGrigoryev : 하나의 부 버전은 거의 즉시 가깝습니다.

— jmoreno

4

대답은 고객에게 제공하는 서비스 종류에 따라 다릅니다.

극단적으로, Windows 3.1에서 Win 3.1 시대의 실수는 20 년 동안 전파되어 왔으며, 이는 Microsoft가 이전 버전과의 호환성을 매우 강력하게 믿었 기 때문입니다.

스펙트럼의 다른 쪽 끝에서 많은 웹 응용 프로그램은 사용 중단 경고를 제공하지 않고도 기능을 제거합니다.

고객의 소프트웨어 비용은 업무 라인과 마찬가지로 종종 중요합니다. 연구 과학자들은 일반적으로 은행이나 FAA보다 진척의 행진의 일부로 더 이상 사용되지 않을 것을 기꺼이 받아들입니다.

내부 용 소프트웨어를 개발하는 회사에서 근무했습니다. 몇 년 동안 많은 그룹을 지원했습니다. 한 그룹은 "모든 기능을 제거하지 마십시오"라는 사고 방식을 가지고있었습니다. 그들은 5-10 년 전에 파일로 되돌아 가서 개발자들이 기능을 다시 넣을 수 없을 정도로 빠른 시간에 파일을 분석 할 수있는 능력이 필요했습니다. 나중에 찾을 수 있습니다. " 가운데에는 "그룹을 제거하기 전에 사용하는 경우 인쇄 된 경고와 함께 버전이 1 이상 사용되지 않아야합니다."라는 규칙이있는 그룹이 하나 있습니다. 이 그룹에는 필요한 기능을 다루는 테스트 스위트가있었습니다. 새로운 버전을 출시 할 때마다 테스트 스위트를 신속하게 실행하여 더 이상 사용되지 않는 제품이 문제를 일으키는 지 확인했습니다.

— 코트 암몬
소스

4

공용 API를 유지 관리하고 메소드를 더 이상 사용하지 않아야합니다.

왜 이렇게해야합니까? 새로운 빛나는 방법이 있기 때문에 이전 방법은 권장되지 않지만 여전히 잘 작동합니까? 아니면 근본적으로 변화했기 때문에 기존 방법이 실제로 필요합니까?

기존의 방법은 실제 문제가 발생하지 않는 경우, 그리고 수 곁에, 그것은 할 수있다뿐만 아니라. 파손되지 않았다면 고치지 마십시오. 정말로 제거해야합니까? 어쩌면 그것을 쓸모없는 것으로 표시하고 문서에 다른 방법이 더 효율적이거나 무엇이든 할 수있는 메모를 포함 시키십시오. 그러나 그것을 그대로 두는 것이 좋습니다.
이전 방법이 실제로 필요하다면 유지 관리 문제가 발생하거나 다른 변경으로 인해 더 이상 의미가 없기 때문에 사용법을 모니터링하고 사용 중단을 고객에게 명확하게 전달하십시오. 방법이 제거 된 후 명확한 날짜를 제공하십시오. (사실,이 날짜에 실제로 즉시 제거하지 마십시오. 실제로 제거하기 전에 아무도 사용하지 않을 때까지 기다리십시오. 실제로 문제가 발생하는 경우 더 빨리 진행해야하지만 최소한 사용이 중단 될 때까지 기다려야 할 수도 있습니다. 작은.)
이전 방법으로 보안 문제가 발생하는 경우 경고보다 빨리 제거해야 할 수도 있습니다. 경고없이 제거 할 수도 있지만이 변경 사항을 눈에 잘 띄는 곳에 기록하고 이전 방법을 사용하려는 클라이언트에게 합리적인 메시지를 반환해야합니다.

(두 번째 글 머리 기호는 다른 답변에서 잘 설명되어 있지만 첫 번째 글 머리 기호는 새로운 것 같습니다.)

— 삼각
소스

1

공개 프로젝트의 경우 필요한 경우 에만 제거하십시오 .

불필요한 API 제거를 수행하면 비용이 많이 드는 이탈로 인해 계산할 수없는 방식으로 회사와 계약자에게 비용이 많이 듭니다.

회사와 독립 프로그래머가 프로젝트 사용을 중단하고 싶습니까? 중요하지 않은 시간에 충분한 시간을 허비하면 즉시 보트에 올라갑니다.

deprecation != eventual_removal. API가 위험한 경우 제거합니다. 오래 된 경우 그대로두고 교체 내용을 기록하십시오.

— kayleeFrye_onDeck
소스