Küçük bölgeler ve özel kodlar: verinin sınır örnekleri

Küçük bölgeler ve özel kodlar, ülke listelerinin en çok atlanan ama en çok hata üreten kısmıdır. Bu yerler toplam kayıtların çok küçük bir bölümünü oluşturur; bu yüzden test kümelerine nadiren girer, üretimde ise tam olarak o küçük bölümde tuhaf sonuçlar çıkar. Sorun, bu yerlerin istisna olması değil, istisna olduklarının yazılı olmamasıdır. Bu yazıda hangi yerlerin veri içinde zorlandığını, kod bulunmayan durumları ve eksik değerin nasıl kaydedileceğini ele alıyoruz.

Küçük bölgeler neden veri içinde daha çok zorlanır?

Bu yerlerin ortak özelliği, tanımlarının büyük ülkeler kadar kesin olmamasıdır. Bir anakara ülkesi için sınır, başkent ve alt bölüm yapısı genellikle tartışmasızdır; küçük bir bölgede ise bu üç bilginin her biri ayrı ayrı sorgulanabilir. Veri kümesi bu belirsizliği taşımıyorsa, belirsizliği kullanan katman kendi varsayımını üretir.

İkinci özellik, bu yerlerin sayıca az ama çeşit olarak geniş olmasıdır. Birbirine benzemeyen onlarca küçük yer, tek bir kuralın altına sığmaz. Kural yazarken en büyük ülkeyi örnek almak kolaydır; ama bu kural, küçük yerlerin çoğunda yanlış sonuç verir.

Üçüncü özellik, değişimin düzenli olmamasıdır. Küçük bölgelerin statüsü, idari yapılarından daha sık değişir. Bu değişiklikler büyük bir olay olarak duyurulmaz; yalnızca kayıtların bir kısmında görünür hale gelir.

Bu tablo, küçük bölgelerin neden ayrı bir test başlığı hak ettiğini gösterir. Genel ülke testleri bu yerlerin hiçbirine dokunmaz; çünkü bu testler en yaygın kayıtlar üzerinden kurulur. En yaygın kayıtlar ise tam olarak sorunun görünmediği kayıtlardır.

Her bölgenin kendine ait iki harfli kodu var mı?

Hayır; bu, en yaygın yanlış varsayımdır. Kod listeleri dünyadaki her yerleşim yerini değil, belirli bir siyasi ve idari düzeyi kapsar. Listeye girmeyen bir yer, geçersiz olduğu için değil, o düzeyde tanımlı olmadığı için dışarıda kalır.

Bu durumun pratik sonucu şudur: her kaydın kendi kodu olacağını varsayarak yazılmış bir akış, kod bulamayan kayıtlarda çöker. Kod yerine bir yer tutucu üretmek daha kötüdür; çünkü üretilen değer geçerli bir kod gibi görünür ve listenin dışında bir yer işgal eder.

Doğru yaklaşım, kod alanını zorunlu değil, koşullu tutmaktır. Kod varsa yazılır; yoksa alan boş bırakılır ve bu boşluğun neden boş olduğu kaydın kendi bilgisinden anlaşılır. Kod yokluğu, bir hata durumu değil, veri modelinin tanıdığı bir durumdur.

Kod yerine kullanılabilecek geçici çözümler de vardır: bir üst bölgeye bağlamak ya da kaydı serbest metinle tanımlamak. Her iki çözüm de bazı alanlarda çalışır ama hiçbiri kodun yerini tam tutmaz. Bu yüzden hangi alanın hangi çözümle çalıştığını alan bazında yazmak gerekir.

Kod atamalarının üzerinde duran zorlukları ülke ve alt bölüm kodları yazısında ayrıntılı olarak ele alıyoruz.

Tarihsel kodlar neden silinmemeli?

Kod listeleri yalnızca bugünü tanımlamaz; zaman içinde bazı kodlar kullanımdan kalkar, bazıları ise yeni bir anlam kazanır. Kullanımdan kalkmış bir kod, geçmişte üretilmiş kayıtlarda hâlâ durur. Bu kodları listeden tamamen çıkarmak, geçmiş kayıtları çözümsüz bırakır.

Bu nedenle kod kümesini iki katmanlı düşünmek gerekir: bugün üretilebilecek kodlar ve geçmişte üretilmiş kodlar. İlk katman kullanıcıya sunulur; ikinci katman ise yalnızca çözümleme sırasında tanınır. İki katmanı ayırmak, eski kaydı bozmadan yeni kaydı doğru üretmeyi mümkün kılar.

Bazı kodlar ise hiçbir zaman bir yere atanmamış olarak ayrılmıştır. Bu ayrılmış değerler bir kayıtta görünüyorsa, bu genellikle verinin dışarıdan geldiği ve kaynağın kendi kuralını uyguladığı anlamına gelir. Kaynağı suçlamak yerine, bu değerin nasıl yorumlanacağını yazmak gerekir.

Üçüncü grup, geçiş döneminde iki farklı biçimin birlikte kullanılmasıdır. Aynı yer, bir süre boyunca hem eski hem yeni değerle karşımıza çıkar. Bu dönemde iki değeri tek kayda indirmek veri kaybına yol açar; ikisini de tanıyıp aynı yere bağlamak gerekir.

Ayrıca, girişte eski adlar ve kullanımdan kalkmış yazımlar da görünebilir; bu tür girdilerin nasıl ele alınacağını, ad eşleştirme ve takma adlar konusuna bırakıyoruz.

Eksik değeri tek bir işaretle geçmek neden yanlış?

Bu ayrım, veri modelinin en ince noktasıdır ve tek bir işaretle geçildiğinde sonuçları geri döndürülemez biçimde bozulur.

Bir alanın boş olması üç farklı şey anlatabilir. Birincisi, o alan bu yer için gerçekten geçerli değildir. İkincisi, alan geçerlidir ama değeri henüz bilinmemektedir. Üçüncüsü, alan geçerlidir, değer bilinmektedir ama toplanmamıştır. Bu üç durumu aynı boş değerle kaydetmek, ileride hangisinin hangisi olduğunu ayırt etmeyi imkânsız kılar.

Sonuç, raporların yanlış okunmasıdır. Kapsam eksikliği, “bu alan burada yok” sanılır; bilinmeyen bir değer ise “tamamlanmış” sayılır. Bu tür karışıklıklar, veriyi düzeltmeye çalışan ekibi yanlış yere yönlendirir.

Ayrımı kurmak için üç ayrı işaret gerekir: uygulanamaz, bilinmiyor ve eksik. Her işaret ayrı bir anlam taşır ve ayrı davranış üretir. Uygulanamaz bir alan doğrulamaya hiç girmez; bilinmeyen bir alan girip geçebilir; eksik bir alan ise doldurulmayı bekler.

Bu ayrımın bir bedeli vardır: alan sayısı ve kontrol sayısı artar. Karşılığında, veri kümesi hakkında sorulabilecek sorular cevaplanabilir hale gelir. Aksi halde her rapor, verinin gerçekte ne söylediğine değil, ekibin hatırladığına dayanır.

Teslimat desteği olmaması bir biçim sorunu mudur?

Değildir; ama pratikte en sık bu iki durum karıştırılır. Desteğin bulunmaması bir ürün kararıdır: gönderi oraya gitmez. Biçim sorunu ise verinin kuralla uyuşmamasıdır: gönderi gidebilir ama girilen değer kuralı tutmaz.

İki durumun kullanıcıya söylenme biçimi de farklı olmalıdır. Destek yokluğunda kullanıcının düzeltebileceği bir şey yoktur; doğru davranış, durumu açıkça söylemek ve varsa başka bir yol göstermektir. Biçim sorununda ise kullanıcı değeri düzeltebilir; mesaj hangi alanın neden reddedildiğini göstermelidir.

Bu ayrımın testi de ayrı yapılmalıdır. Desteklenmeyen bir bölgenin seçilmesi ile geçerli bir bölgede geçersiz bir değerin girilmesi iki ayrı senaryodur. İki senaryonun beklenen sonucu ayrı yazılmazsa, geliştirici ikisini tek bir hata yolunda birleştirir ve kullanıcı yapamayacağı bir düzeltmeyi dener.

Üçüncü bir durum daha vardır: bölge desteklenmektedir ama alanlardan biri o bölgede bulunmaz. Bu durumda doğru davranış, alanı hiç sormamaktır. Sorulmayan alan için uyarı üretmek, kullanıcıyı olmayan bir sorunu çözmeye iter.

Geliştiriciler için: küçük bölgeler için sabit bir örnek kümesi tutmak

Üretimde nadiren görünen kayıtlar, ancak elle kurulmuş küçük bir örnek kümesiyle test edilebilir. Bu küme, büyük ülkelerden değil, yalnızca kural dışı davranan yerlerden oluşmalıdır.

Kümedeki her kayıt için beklenen davranışı ayrı yazın: hangi alan doğrulanır, hangisi sorulmaz, hangi alan boş kalır ve hangi değer hangi işareti taşır. Bu beklentiler yazılı olduğunda, doğrulama katmanındaki bir değişiklik küçük bölgeleri sessizce bozamaz.

Örnek kümesini küçük tutun ama çeşitliliği koruyun. Aynı davranışı gösteren yerleri tek bir örnekle temsil etmek yeterlidir; ama farklı davranan her yer için en az bir örnek bulunmalıdır. Kümenin amacı kapsamak değil, ayrımları yakalamaktır.

Son olarak, bu kümeyi üretim verisinden türetmeyin. Üretimde bu kayıtların sayısı az olduğu için, türetilen bir küme çoğu zaman boş ya da eksik kalır. Küçük bölgelerin testi, bilinçli bir seçimle kurulur.

Sonraki adımlar

Küçük bölgelerin hangi kurallara uyduğunu anlamak için önce test verisi için ülke seçmek yazısına, bu yerlerin sipariş akışlarında nasıl davrandığını görmek için ise sınır ötesi adres senaryoları yazısına bakabilirsiniz. Alanların hangi ülkelerde bulunduğunu karşılaştırmak için sitemizdeki ülke ve bölge dizini sayfasını kullanabilirsiniz.

Bu yazıdaki bölge adları, kod değerleri ve statü açıklamaları yalnızca davranış farkını göstermek için kurulmuş örneklerdir; herhangi bir gerçek bölgeye atanmış bir kod ya da resmî bir statü anlamına gelmez.