Şema ile model bir­bi­rin­den uzak­laş­tı­ğında

Bazı hatalar büyüktür, çünkü nedenleri büyüktür. Bazıları ise nedenleri küçücük olduğu hâlde büyüktür — ve asıl öğretici olanlar bunlardır. Bu hikâye böyle bir hatayı anlatıyor. Bilinçli olarak genel tutuldu — proje, kişi ve tarih belirtilmeden.

Durum

Birden fazla ekibin çalıştığı büyük bir girişimde bir hata inatla sürdü. Ortaya çıkıyor ama kolayca yakalanamıyordu ve sonradan yapılan açıklamanın düşündüreceğinden çok daha uzun süre aramaya direndi. Aynı sistem üzerinde pek çok el çalışıyordu ve hata, birkaç kişinin dokunduğu bir alanı etkiliyordu.

Başlangıç varsayımları

Büyük bir sistemdeki inatçı bir hata, büyük bir neden beklentisi uyandırır: derin bir tasarım hatası, ince bir etkileşim, zor yakalanan bir koşul. Arayış da buna göre şekillenir — belirti karmaşık göründüğü için karmaşık olanı ararsınız. Bu beklenti, ilk başta asıl nedenin yanından geçip gitmemize yol açtı.

Sorun

Neden küçüktü. Veritabanı şeması değişmişti, ancak koddaki eşleme — modelin veritabanını nesnelere çevirdiği yer — bu değişikliğe ayak uydurmamıştı. Veritabanı ve model aynı şey hakkında artık aynı şeyi söylemiyordu. Bu küçücük uyumsuzluktan, asıl yerinden çok uzakta kendini gösteren ve bu yüzden yerini tespit etmek zor olan bir hata doğdu. Sorun nedenin büyüklüğü değil, neden ile sonuç arasındaki mesafeydi.

Neden

Daha derindeki neden, bir değişikliğin iki yerde yapılması gerekirken yalnızca birinde yapılmış olmasıydı. Şema ve eşleme, aynı gerçeğin iki temsilidir; biri değişirse diğeri de onu izlemek zorundadır. Bu bağımlılığın görünür olmadığı ve güvence altına alınmadığı yerde — ve çok elin çalıştığı büyük bir projede bu nadiren kendiliğinden olur — biri yer değiştirirken diğeri yerinde kalabilir. İkisi birbirinden uzaklaştı ve kimse o anı fark etmedi.

Karar

Hata bulunduktan sonraki karar, bu tek hatayı düzeltmekten çok — bu hızla yapıldı — bu tür hataların bütün sınıfını daha az olası kılmaktı: Şema ile eşlemenin uyumunu tesadüfe ve tek tek kişilerin dikkatine bırakmamak, onu görünür ve denetlenebilir kılmak.

Uygulama

Bu, veritabanı ile model arasındaki bağımlılığı göze çarpacağı yere taşımak anlamına geliyordu: Şema ile eşleme arasındaki bir sapma geç ve gizemli bir belirti olarak değil, erken ve yüksek sesle görünür olmalıydı. Herkesin bir şema değişikliğinde eşlemeyi de güncelleyeceğine güvenmek yerine, birbirinden uzaklaşmanın kendisi sistemin fark ettiği bir şeye dönüştü — sonuca uzak değil, nedene yakın bir yerde.

Avantajlar ve sınırlamalar

Bu güvencenin bir bedeli var: Bakım isteyen bir kontrol ekler ve bir şema değişikliği anını biraz daha hantal hâle getirir, çünkü artık ilerlemeden önce ikisinin birbirine uyması gerekir. Bu bedel karşılığında, küçücük bir uzaklaşmanın artık uzun, ekipler arası bir hata arayışına dönüşmemesi satın alınır. Tek bir kişinin şemayı ve modeli zahmetsizce takip edebildiği çok küçük bir sistemde farklı karar verirdik — orada ek kontrol, sağladığı korumadan çok zahmet getirir.

Ne öğrendik

Veritabanı ile model arasındaki küçük uyumsuzluklar orantısız büyük sorunlar yaratır, çünkü sonuç nedenden çok uzakta kendini gösterir. Bir hata arayışının maliyeti nedenin büyüklüğüyle değil, neden ile belirti arasındaki mesafeyle ölçülür — ve yerinden kaymış bir eşleme, büyük mesafeli küçücük bir nedendir. Bu yüzden özellikle sessiz bağımlılıkları görünür kılmaya değer: Aynı şeyin iki temsilinin birbirine uyması gereken ama birbirinden bağımsız değiştirilebildiği yerleri.

Bu deneyim Batunet'i nasıl değiştirdi

O zamandan beri şema ile modelin uyumunu herkesin aklında tutması gereken bir şey olarak değil, sistemin kendisinin gözetmesi gereken bir şey olarak ele alıyoruz. Sessiz bağımlılıkları — birlikte değiştirilmesi gereken çiftleri — bilinçli olarak arıyor ve bir uzaklaşmayı erken görünür kılıyoruz. “Birinin bunu düşünmesi gerekirdi” yerini “sistem bize söylüyor”a bıraktı.

İleri okuma

• Rehber: Kesintisiz veritabanı migrasyonları — şema değişikliklerini bilinçli ve güvence altında yapmak.
• Rehber: İş mantığı controller'a ait değildir — veritabanı ile domain arasındaki çeviriyi bilinçli tasarlamak.
• Rehber: Observability bir mimari meselesidir — bir nedenin neden sonucuna yakın yerde görünür olması gerektiği.
• Karar: PostgreSQL: JSONB ve tablolar — verinin biçiminin kodla bağımlılığı nasıl şekillendirdiği.

Temeli Batunet Engineering Method'tur: sessiz bağımlılıkları görünür kılmak, hataları nedenlerine yakın yerde göstermek, yalnızca dikkate güvenmemek.

Bir hatanın büyüklüğü, nedeninin büyüklüğü hakkında hiçbir şey söylemez. En pahalı olanlar, etkisi kaynağından çok uzakta kendini gösteren küçücük uyumsuzluklardır.