Kullanımdan kaldırılan bir yöntemi silmeden önce ne kadar beklemeli? [kapalı]

Genel bir API tutuyorum ve bir yöntemi kullanımdan kaldırmam gerekiyor.

Silme işleminden önce kaç ay / yıl / sürüm kullanılacağı hakkında bir kural var mı?

En azından, yazarken açıkça anlaşılır görünen bunları kaldırmadan önce kullanımdan kaldırılmış yöntemleri bir sürümde tutmalısınız. Maksimum bir zaman olduğunu sanmıyorum ama onları gerçekten kaldırmadıysanız itiraz biraz anlamsızlaşıyor.

Başlıca sürüm sürümleri, kullanım dışı yöntemleri kaldırmak için iyi bir zamandır. Küçük sürümler tipik olarak kırılma değişiklikleri içermemelidir. CHao'nun yorumlarda belirttiği gibi, kullanımdan kaldırılma, nihai olarak kaldırılması gerektiği anlamına gelmez, bu nedenle kullanımdan kaldırıldıktan sonra bir şeyleri kaldırmayı planlıyorsanız, açıkça belirtmelisiniz ve zaman çizelgesi hakkında bazı bilgiler vermelisiniz.

Bu, yalnızca kullanıcılarınıza ne tür bir istikrar garantisi verdiğinize ve kullanıcılarınız için ne kadar acı çekmek istediğinize bağlıdır.

İdeal olarak, API'niz semver kullanır, böylece herhangi bir bozulma değişikliği ana sürüm numarasının artırılmasına neden olur. Uygulamada, bunu neredeyse hiç yapmamak istenir. API bazı paket yöneticisi ile yüklenmiş ise, (örneğin basit bir yükseltme çatışmalar nedeni değil böylece kırılma değişiklikten sonra yeni bir paket adı oluşturmak isteyebilirsiniz myapi2 v2.123.4vs myapi3 v3.2.1). Paket yöneticiniz daha sıkı sürüm bağımlılıklarını destekliyorsa (örneğin ~v2.120, buna benzer bir bağımlılık şartnamesi içermiyorsa v3.*), bu gereksiz olabilir , ancak farklı paket adlarının uyumsuz sürümlerin yan yana kolayca kullanılabilmesi avantajı vardır. Semver kullanırken bile, bir kullanımdan mahrum kalma süresine sahip olmak mantıklı olabilir.

Semver her zaman geçerli değildir. Öyleyse açık bir istikrar politikası oluşturmak daha önemlidir. Örneğin:

• Deneysel özellikler önceden bildirilmeksizin kaldırılabilir.
• Özellikler güvenlik nedeniyle herhangi bir zamanda kaldırılabilir.
• Diğer özellikler sadece kaldırılacak
  • … Serbest bırakılmış bir sürümde onaylandıktan sonra
  • … Bu sürümün en az üç aylık olduğu yer
  • … Ve ana versiyonda bir çarpma ile işaretlenecektir.

Bu tür politikalar, düzenli olarak yayınlandığında özellikle işe yarar, böylelikle bir yıl gibi net bir amortisman süresi söz konusudur.

API’nin herhangi bir bölümünü kullanımdan kaldırılmış olarak işaretlemenin yanı sıra, kullanımdan kaldırmayı yaygın şekilde bilinir hale getirmelisiniz. Örneğin:

• Değişiminizde gelecekteki yönler ve itirazlar hakkında bir bölüm var.
• İtirazda bulunmadan önce itiraz etme niyetinizi yayınlayın ve kayda değer itirazlar olup olmadığını görmek için toplumu dinleyin.
• Bu değişikliklerden ne gibi faydalar geleceğini söyleyin Kullanıcı tabanınıza bağlı olarak, haber bültenleri, sunumlar, blog yazıları veya basın bültenleri uygun medya olabilir. Döndürmek “müthiş bir yeni özellik yaratıyoruz! (bu yaygın olarak kullanılan eski özelliğin kaldırılmasını gerektirir) ”bağlamı olmayan bir özelliği kaldırmaktan biraz daha az sinir bozucu.

Seçeceğiniz tam kullanımdan çıkarma süresine gelince, öncelikle kullanıcılarınızla yapılan herhangi bir destek sözleşmesini onurlandırmanız gerekip gerekmediğine bakın. Bu tür sözleşmeler, bir süre uyumluluğun korunmasını gerektirebilir. Değilse, aşağı yönde bir etki düşünün. Alt kullanıcılardan daha az hızlı değişmeye çalışın, böylece kendi amortisman döngülerinden geçebilirler. Alt kullanıcılar, değişikliklerinize uyum sağlamak için biraz zaman alacaktır; bu nedenle, hiçbir zaman bir aydan kısa bir süre kullanımdan ayrılmamanız gerekir.

İdeal olarak, artık kimse kullanımdan kaldırılmış yöntemi kullanmayacak kadar beklemek istersiniz. Herkese açık bir API kullanıyorsanız, izlemesi kolay, ancak çok uzun bir süre beklemeniz gerekebilir.

2015’te Google’ın Android işletim sistemindeki stlport API’si ile benzer bir sorunu vardı. Kullanımdan kaldırıldı ve kaldırmak istedi, ancak tonlarca uygulama hala kullanıyordu. Akıllıca bir çözüm buldular:

Temel olarak, API'yi hala geliştiriciler için uygun bir günlük mesajı ile kullanan herhangi bir uygulamanın başlatılması sırasında 8 saniyelik bir uyku () eklediler. Bir ay sonra, onu 16 saniyeye çıkardılar. daha sonra bir ay sonra API arayüzünü güvenle kaldırabilirlerdi, çünkü kimse kullanmayacaktı.

Bu, bunu yapmanın çok etkili bir yolu olabilir. Tek gerçek sorun, eğer API’niz çok eskiyse ve artık aktif olarak desteklenmeyen tüketicileri aktif olarak kullandıysa. Maalesef, muhtemelen bu tüketicileri kendiniz tamir edemezsiniz, ancak bu noktada, yöntemi silmek ve tüketiciyi kırmaktan çok daha fazlasını yapamazsınız.

Kullanımdan kaldırılmış yöntemler sağlamak için minimum süre, API'nizi kullanan programların geliştirme döngülerine bağlıdır. Bir basketbol sahası figürü olarak, 1 yıl yeterli olmalıdır.

Kullanımdan kaldırılan yöntemleri kaldırmanız gerekmeden önce maksimum süre gelince, böyle bir şey olmadığını savunuyorum. Ne kadar beklerseniz bekleyin, kullanımdan kaldırılmış bir yöntemi kaldırmak her zaman bir şeyi bozacaktır. Kullanımdan kaldırılmış API'nizi kullanan bazı programlar aktif olarak korunmaz ve uyumluluğun kırılması bu tür programlar için ömrünün sonu anlamına gelir.

Kaldırmadan bir şey aldığınızda kullanımdan kaldırılmış yöntemleri kaldırmanızı öneririz :

• özellikle kullanımdan kaldırılmış yöntemleri etkileyen bir hata algılandı
• kodu yeniden düzenlemek üzeresiniz ve kullanımdan kaldırılmış yöntemleri kullanmak önemli bir çaba gerektiriyor
• kütüphanenizin iç yapısını optimize ediyorsunuz ve kullanımdan kaldırılmış yöntemler artık uymuyor.

Kullanımdan kaldırılan yöntemleri yalnızca X ay / yıl boyunca kullanımdan kaldırıldığından veya iyi bir neden olmadan keyfi bir şekilde uyumluluğa zarar vermek için yeni bir sürüm sürümü yayınladığınızdan kaldırmak.

İlk önce terkedilmiş mi yoksa eski mi istediğinizi düşünmelisiniz.

Onaylanmayan, bir şekilde zararlı olan yöntemler için kullanılmalıdır: güvenlik, performans, yanlış sonuçlar. Onlardan nispeten hızlı bir şekilde kurtulmak istiyorsunuz, en fazla 2 ana sürüm ve 3. sırayı geçtiniz. Yeterince önemli sorunlar için, kullanımdan kaldırılan sonraki küçük sürümde kaldırılmış olabilir.

Eski, bazı nedenlerden dolayı daha az kullanışlı olan şeyler içindir, örneğin daha az bilgi döndürür veya işe yaramadı, çok fazla seçenek içermez. Bunlar süresiz olarak takılabilir, ancak en azından bir sonraki ana sürümde bulunmalıdır.

Cevap, müşterilerinize ne tür bir hizmet verdiğinize bağlıdır.

Aşırılığın bir ucunda, Windows.h'da, Windows 3.1 döneminde, Microsoft'un geriye dönük uyumluluğa çok kuvvetli bir şekilde inandığı için, iki yıl boyunca yayılan hatalar var.

Spektrumun diğer ucunda, birçok web uygulaması, kullanımdan kaldırma uyarısı vermeden bile özellikleri kaldırır.

Müşterileriniz, yazılımınız için ne kadar para ödüyorlarsa, çalışma alanları da aynı şekilde önemli. Araştırma bilim adamları tipik olarak bankacılığa veya FAA'ya göre ilerleme sürecinin bir parçası olarak amortismanı kabul etmeye daha isteklidirler.

Dahili kullanım için yazılım geliştiren bir şirkette çalıştım. Yıllar boyunca birçok grubu destekledim. Bir grup "hiçbir özelliği kaldırma" zihniyetine sahipti. 5-10 yıl önce dosyalara geri dönme ve geliştiricilerin özellikleri yeniden yerleştirebilmeleri için çok hızlı bir şekilde zaman çizelgeleri üzerinde analiz yapabilmeleri gerekiyordu. onları daha sonra bulabilirim. " Ortada, "Özellikleri kaldırmadan önce kullanıyorlarsa, en az 1 versiyon için kullanımdan kaldırılmış olmalı" uyarısı olan bir grubumuz vardı. Bu grupta ihtiyaç duydukları özellikleri kapsayan bir test paketi vardı. Ne zaman yeni bir sürüm çıkarsak, hızlı bir şekilde amortismanlardan herhangi birinin sorun yaşamadığını görmek için test takımlarını buna karşı koştular.

Genel bir API tutuyorum ve bir yöntemi kullanımdan kaldırmam gerekiyor.

Bunu neden yapmanız gerekiyor? İşleri yapmanın yeni ve parlak bir yolu olduğu için, eski yöntem artık cesareti kırılmış, ancak yine de iyi çalışıyor mu? Yoksa eski yöntemin aslında gitmesi gerekiyor mu, çünkü işler temelde değişti mi?

• Eski yöntemi herhangi bir fiili sorunlara yol değilse ve olabilir ayrılmamak, o zaman olabilir de. Eğer kırılmadıysa, tamir etmeyin. Gerçekten çıkarman gerekiyor mu? Belki eski olarak işaretleyin ve belgelere başka bir yöntemin daha verimli olabileceğini veya her neyse olabileceğini not edin, ancak muhtemelen yerinde bırakmak iyidir.

• Eski yöntemin gerçekten uygulanması gerekiyorsa, bu sizi bakım baş ağrısına neden olduğu için veya diğer değişikliklerden dolayı artık bir anlam ifade etmiyorsa, kullanımını izler ve kullanımdan kaldırmayı açıkça müşterilere iletir. Onlara yöntemin kaldırılacağı süreye açık bir tarih verin. (İdeal olarak, bu tarihte derhal kaldırmayın: gerçekten kaldırmadan önce hiç kimse onu kullanmadan önce bekleyin. Gerçekten de sorunlara neden olursa, daha erken gitmesi gerekebilir, ancak en azından kullanımın bırakılmasını bekleyin biraz.)

• Eski yöntem güvenlik sorunlarına neden oluyorsa, uyarmadan bile kaldırarak bile bundan daha hızlı hareket etmeniz gerekebilir, ancak bu değişikliği çok görünür bir yerde belgelemelisiniz ve ayrıca eski yöntemi kullanmaya çalışan istemcilere anlamlı mesajlar döndürmelisiniz.

(İkinci iki kurşun noktası diğer cevaplarda iyi bir şekilde ele alınmıştır, ancak ilki yenidir.)

Halka açık bir proje için, sadece ve sadece ihtiyacınız olduğunda kaldırın .

Gereksiz API kaldırma işlemini yaptığınızda, şirketler ve müteahhitler için masraflı çalkalama nedeniyle bile hesaplayamayacağınız şekilde maliyet ödersiniz.

Şirketlerin ve bağımsız programcıların projenizi kullanmayı bırakmasını ister misiniz? Gerekli olmadığınızda eşyalarını yeterince kırın ve zamanla o tekneye çıkmayacaksınız.

deprecation != eventual_removal. Bir API tehlikeli ise, kaldırırsınız. Sadece eskiyse, bırakın ve değişimini belgeleyin.