Eski kodun kullanımdan kaldırılması için en iyi uygulamalar nelerdir?


9

Eski bir yöntemi aşamalı olarak kaldırmaya ihtiyacım var. Bu [Obsolete]özelliğin farkındayım . Microsoft'un bunu yapmak için önerilen en iyi uygulama kılavuzu var mı?

İşte benim mevcut planım:

C. Yeni bir montaj oluşturmak istemiyorum çünkü geliştiriciler projelerine yeni bir referans eklemek zorunda kalacaklar ve bunu yapmaları gerekiyorsa patronumdan ve iş arkadaşlarımdan çok fazla keder almayı umuyorum. Ayrıca, birden fazla montaj sürümü bulundurmuyoruz. Sadece en son sürümü kullanıyoruz. Bu uygulamanın değiştirilmesi, büyük bir sorun olan dağıtım sürecimizi değiştirmeyi gerektirecektir (insanlara FinalBuilder yerine TFS ile nasıl şeyler yapacaklarını öğretmek ve FinalBuilder'den vazgeçmelerini sağlamak)

B. Eski yöntemi kullanılmıyor olarak işaretleyin.

C. Uygulama değiştiği için (yöntem imzası değil), bir aşırı yükleme oluşturmak yerine yöntemi yeniden adlandırmam gerekiyor. Bu nedenle, kullanıcıları uygun yöntemden haberdar etmek için [Obsolete]özelliğe bir mesaj eklemeyi planlıyorum . Bu bölüm beni rahatsız ediyor, çünkü yaptığım tek değişiklik yöntemi bağlantı dizesinden ayırmak. Ancak, yeni bir meclis eklemediğim için, bunun etrafında bir yol göremiyorum.

Sonuç:

[Obsolete("Please don't use this anymore because it does not implement IMyDbProvider.  Use XXX instead.")];
        /// <summary>
        /// 
        /// </summary>
        /// <param name="settingName"></param>
        /// <returns></returns>
        public static Dictionary<string, Setting> ReadSettings(string settingName)
        {
            return ReadSettings(settingName, SomeGeneralClass.ConnectionString);
        }

        public Dictionary<string, Setting> ReadSettings2(string settingName)
        {
            return ReadSettings(settingName);// IMyDbProvider.ConnectionString private member added to class.  Probably have to make this an instance method.
        }

Yanıtlar:


5

Microsoft, [eski] niteliğini geliştiricilere yöntem, özellik veya sınıfın kullanımdan kaldırıldığını ve gelecekteki sürümlerde değiştirilebileceğini (veya hiç desteklenmeyeceğini) söylemek için kullanır .

Bu, API'nızı kullanıcılarına özelliklerinin "kullanımdan kaldırıldığını" bildirmek ve yazılımlarının gelecekteki sürümlerinde referansları kaldırmak için en az bir sürüm döngüsü sağlar.

Orijinal özelliği ne kadar süreyle bıraktığınız tamamen size bağlıdır. Geliştiricileri yeni özelliklerinizi eskileri üzerinde kullanmaları için "güçlü bir şekilde teşvik etmek" istiyorsanız, kaldırmak için yalnızca bir ek yayın döngüsüne ihtiyacınız vardır. Kalıcı olarak geriye dönük uyumluluk istiyorsanız, sonsuza kadar bırakabilirsiniz.

Brian'ın belirttiği gibi, yalnızca temel uygulamayı değiştiriyorsanız, ancak yöntem imzasını değiştirmiyorsanız, bunların hiçbirini yapmanız gerekmeyebilir.


Microsoft'un uygulaması genellikle bir sonraki büyük sürümde kullanımdan kaldırılmış bir şeyi kaldırmaktır. Buna karşılık, Java kullanımdan kaldırılan şeyleri hiçbir zaman kaldırmaz - bu yüzden size kalmış.
Scott C Wilson

Montajları uygulama seviyesinin ötesinde versiyonlamıyoruz (birçok çözüm içeren 1 dev uygulama). Bunu, herhangi bir montaja bağlı çözümlerin # sayısının tanımsız olması gerçeğiyle birleştirin. Bilmediğim bir uygulamayı test edemiyorum. Ancak, bilmediğim bir uygulamanın bozulmasına neden olan bir değişiklik yaparsam ... bu benim hatam. Bu yüzden yöntemi yeniden adlandırdım. Yani, şimdiye kadar okuduğumdan, bu konuda daha iyi bir yol yok.
P.Brian.Mackey

4

Uygulama değiştiğinden (yöntem imzası değil), bir aşırı yükleme oluşturmak yerine yöntemi yeniden adlandırmam gerekiyor.

Anlamıyorum. Uygulama değişiyor ancak imza değişmiyorsa, bunu neden yaptın? "Eski" yöntem yeni ve geliştirilmiş uygulamayı kullansın. Bu API'yı kullanan tüm geliştiriciler, aynı imzaya sahip bir yöntem ve mevcut yöntem çağrılarında kullanımdan kaldırma uyarıları gördüklerinde gözlerini yuvarlayacaktır. (Bunun bir API'da daha önce olduğu bir zamanı düşünebiliyor musunuz?)

Bu yöntemin temel uygulamasının değiştirilmesinin işe yarayıp yaramayacağından emin değilseniz, uygulamayı değiştirmeden önce ve sonra birim testleriyle ilgili davranışı doğrulayın.


Güzel bir ideal. Sorun şu ki, yerinde test koşumlarımız yok. Bu, çözülmeyi umduğum bir diğer konu. Dolayısıyla, entegrasyon testi olmadığından önerilerinizi yapamam. Denenmemiş çok sayıda henüz tanımlanmamış bağımlılıklar var.
P.Brian.Mackey

Testten bahsetmemin nedeni, API'nızı tüketenlerin testi yapması ve 2 arama arasındaki sorunları bulmanıza yardımcı olması için bunu açıkça yapmak istediniz. En iyi seçeneğiniz, kodunuzu kullanarak geliştiricileri ateşe atmak ve yeni uygulamayı kullanmalarını sağlamak ve kapsamlı KG yapmaları veya kendi testlerine sahip olmalarını ummak gibi görünüyor.
brian

Kendimi ateşe atıyorum. Gönderdiğim orijinal kodla kalmayı tercih ederim. Bu şekilde kimse sabah saat 3'te beni arama kodunun neden kırıldığını merak etmiyor. Daha sonra, geliştiricilere kod geçişlerini çözdüklerinde ve uyarı bayraklarını onardıklarında çözmeleri için bağımlı olun. Eğer bu noktada sabitlemezlerse, o zaman bağlantı telleri üzerlerinde arızalanmaya başladığında, uyarı bayraklarını tamir etmemedeki hataları ... benim değil.
P.Brian.Mackey

Her yeni kod yazdığınızda sorun ortaya çıkma riskiyle karşı karşıya kalırsınız. Testler, çok korkmadan yeniden düzenleme yapmanıza izin verecektir. Korku aklı öldürür. Ayrıca kaçınılmaz olanı geciktiriyorsunuz; begrudgingly şu anda birkaç yineleme çağrılarına bir "2" ekleyecek ve eğer işe yaramazsa aynı telefon görüşmesi alacaksınız.
brian
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.