Hataya neden olan değişiklikler

  • Makale

Bir .NET kitaplığının mevcut kullanıcılar için kararlılık ve gelecek için yenilikler arasında bir denge bulması önemlidir. Kitaplık yazarları, kodu mükemmel olana kadar yeniden düzenlemeye ve yeniden düşünmeye odaklanır, ancak mevcut kullanıcılarınızı bozmak özellikle düşük düzeyli kitaplıklar için olumsuz bir etkiye sahiptir.

Proje türleri ve hataya neden olan değişiklikler

Kitaplığın .NET topluluğu tarafından nasıl kullanıldığı, hataya neden olan değişikliklerin son kullanıcı geliştiricileri üzerindeki etkisini değiştirir.

  • Seri hale getirici, HTML ayrıştırıcısı, veritabanı nesnesi ilişkisel eşleyici veya web çerçevesi gibi düşük ve orta düzey kitaplıklar , hataya neden olan değişikliklerden en çok etkilenen kitaplıklardır.

    Yapı taşı paketleri, son kullanıcı geliştiricileri tarafından uygulama oluşturmak için ve diğer kitaplıklar tarafından NuGet bağımlılıkları olarak kullanılır. Örneğin, bir uygulama oluşturuyorsunuz ve bir web hizmetini çağırmak için açık kaynak istemci kullanıyorsunuz. İstemcinin kullandığı bir bağımlılıkta hataya neden olan güncelleştirme, düzeltebileceğiniz bir şey değildir. Değiştirilmesi gereken açık kaynak istemcidir ve bu istemci üzerinde hiçbir denetiminiz yoktur. Kitaplıkların uyumlu sürümlerini bulmanız veya istemci kitaplığına bir düzeltme göndermeniz ve yeni bir sürüm beklemeniz gerekir. En kötü durum, üçüncü bir kitaplığın karşılıklı uyumsuz sürümlerine bağlı iki kitaplık kullanmak istemenizdir.

  • Kullanıcı arabirimi denetimleri paketi gibi üst düzey kitaplıklar , hataya neden olan değişikliklere daha az duyarlıdır.

    Üst düzey kitaplıklara bir son kullanıcı uygulamasında doğrudan başvurulur. Hataya neden olan değişiklikler oluşursa, geliştirici en son sürüme güncelleştirmeyi seçebilir veya hataya neden olan değişiklikle çalışmak için uygulamasını değiştirebilir.

✔️ Kitaplığınızın nasıl kullanılacağını düşünün. Hataya neden olan değişikliklerin bunu kullanan uygulamalar ve kitaplıklar üzerindeki etkisi nedir?

✔️ DO, alt düzey bir .NET kitaplığı geliştirirken hataya neden olan değişiklikleri en aza indirin.

✔️ Kitaplığın büyük bir yeniden yazılmasını yeni bir NuGet paketi olarak yayımlamayı GÖZ ÖNÜNDE BULUNDURUN.

Hataya neden olan değişiklik türleri

Hataya neden olan değişiklikler farklı kategorilere ayrılır ve eşit düzeyde etkili olmaz.

Kaynak hataya neden olan değişiklik

Kaynak hataya neden olan bir değişiklik program yürütmesini etkilemez, ancak uygulama bir sonraki yeniden derlendiğinde derleme hatalarıyla sonuçlanır. Örneğin, yeni bir aşırı yükleme daha önce belirsiz olan yöntem çağrılarında bir belirsizlik oluşturabilir veya yeniden adlandırılan bir parametre adlandırılmış parametreleri kullanan çağıranları bozar.

public class Task
{
    // Adding a type called Task could conflict with System.Threading.Tasks.Task at compilation
}

Kaynak hataya neden olan bir değişiklik yalnızca geliştiriciler uygulamalarını yeniden derlediğinde zararlı olduğundan, en az kesintiye neden olan değişikliktir. Geliştiriciler kendi bozuk kaynak kodlarını kolayca düzeltebilir.

Davranış hataya neden olan değişiklik

Davranış değişiklikleri en yaygın hataya neden olan değişiklik türüdür: Davranıştaki hemen her değişiklik tüketici için mantıksal bir hataya neden olabilir. Yöntem imzaları, özel durumlar, giriş veya çıkış veri biçimleri gibi kitaplığınızdaki değişikliklerin tümü kitaplık tüketicilerinizi olumsuz etkileyebilir. Kullanıcılar daha önce bozuk davranışa bağlıysa hata düzeltmesi bile hataya neden olan bir değişiklik olarak nitelenebilir.

Özellik eklemek ve kötü davranışları iyileştirmek iyi bir şeydir, ancak dikkatli olmadan mevcut kullanıcıların yükseltmesini çok zorlaştırabilir. Geliştiricilerin davranış hatalarına neden olan değişikliklerle başa çıkmalarına yardımcı olma yaklaşımlarından biri, bunları ayarların arkasına gizlemektir. Ayarlar geliştiricilerin kitaplığınızın en son sürümüne güncelleştirmesine izin verirken aynı zamanda hataya neden olan değişiklikleri kabul etme veya geri çevirme seçeneğini belirleyin. Bu strateji, geliştiricilerin zaman içinde kod kullanmalarına izin verirken güncel kalmasını sağlar.

Örneğin, ASP.NET Core MVC üzerinde etkinleştirilen ve devre dışı bırakılan özellikleri değiştiren bir uyumluluk sürümü kavramına MvcOptionssahiptir.

✔️ Mevcut kullanıcıları etkiliyorsa ve geliştiricilerin bu özelliği bir ayar ile kabul etmesine izin verirse, yeni özellikleri varsayılan olarak kapalı bırakmayı göz önünde bulundurun.

.NET API'lerindeki davranış bozulması değişiklikleri hakkında daha fazla bilgi için bkz . .NET davranış değişiklikleri uyumluluğu.

İkili hataya neden olan değişiklik

Kitaplığınızın genel API'sini değiştirdiğinizde ikili hataya neden olan bir değişiklik gerçekleşir, böylece kitaplığınızın eski sürümlerine göre derlenen derlemeler artık API'yi çağıramaz. Örneğin, yeni bir parametre ekleyerek bir yöntemin imzasını değiştirmek, kitaplığın eski sürümünde derlenen derlemelerin oluşturmasına MissingMethodExceptionneden olur.

İkili hataya neden olan bir değişiklik tüm derlemeyi de bozabilir. ile AssemblyName bir derlemenin yeniden adlandırılması, derlemenin güçlü adlandırma anahtarını ekleme, kaldırma veya değiştirme gibi derlemenin kimliğini değiştirir. Bir derlemenin kimliğinin değiştirilmesi, onu kullanan tüm derlenmiş kodu bozar.

❌ Derleme adını DEĞİşTİrMEYİN.

❌ Güçlü adlandırma anahtarını EKLEMEYİ, kaldırmayı veya değiştirmeyiN.

✔️ Arabirimler yerine soyut temel sınıflar kullanmayı GÖZ ÖNÜNDE BULUNDURUN.

Arabirime herhangi bir şey eklemek, bunu uygulayan mevcut türlerin başarısız olmasına neden olur. Soyut bir temel sınıf, varsayılan bir sanal uygulama eklemenize olanak tanır.

✔️ kaldırmak istediğiniz türleri ve üyeleri yerleştirmeyi ObsoleteAttribute GÖZ ÖNÜNDE BULUNDURUN. Özniteliğin artık eski API'yi kullanmamak için kodu güncelleştirme yönergeleri olmalıdır.

ile ObsoleteAttribute türleri ve yöntemleri çağıran kod, özniteliğine sağlanan iletiyle bir derleme uyarısı oluşturur. Uyarılar, eski API'yi kullanan kişilere geçiş için yüzey süresi verir, böylece eski API kaldırıldığında çoğu artık bunu kullanmaz.

public class Document
{
    [Obsolete("LoadDocument(string) is obsolete. Use LoadDocument(Uri) instead.")]
    public static Document LoadDocument(string uri)
    {
        return LoadDocument(new Uri(uri));
    }

    public static Document LoadDocument(Uri uri)
    {
        // Load the document
    }
}

✔️ Türleri ve yöntemleri ObsoleteAttribute süresiz olarak düşük ve orta düzey kitaplıklarda tutmayı göz önünde bulundurun.

API'lerin kaldırılması ikili hataya neden olan bir değişikliktir. Bakımlarının düşük maliyetli olması ve kitaplığınıza çok fazla teknik borç eklememesi durumunda eski türleri ve yöntemleri göz önünde bulundurmayı göz önünde bulundurun. Türlerin ve yöntemlerin kaldırılmaması, yukarıda belirtilen en kötü durum senaryolarından kaçınmaya yardımcı olabilir.

Hangi .NET API değişikliklerinin ikili uyumluluğu bozanları hakkında daha fazla bilgi için bkz . .NET genel sözleşme uyumluluğu.

Ayrıca bkz.

Geri