Tek sistemde iki ekip üç yerde çarpışır: dağıtımlar, ortak veri ve bir şey bozulduğunda kimin aranacağı. Bu çarpışmalar insan sorunu değildir ve daha iyi iletişimle çözülmez. Sınır sorunudur ve sınırın, iki ekipten biri kod yazmadan önce kararlaştırılması gerekir.
İyi haber, kararların az sayıda ve teknik olarak zor olmamasıdır. Yalnızca genelde ertelenirler, çünkü mimarinin yanında ayrıntı gibi hissettirirler.
Önemli noktalar
- Koddan önce üç karar: Dağıtım bağımsızlığı, veri sahipliği ve arıza yönlendirmesi.
- Zarar veren bağ ortak koddur: Ortak tasarım kararları sorun değildir.
- Ortak olan her şeyin tek sahibi olmalı: İki sahip, sahipsizlik demektir.
- Sürekli değil kilometre taşlarında inceleyin: Sürekli inceleme, düzenin korumak için var olduğu kapasiteyi harcar.
Karar 1: Her ekip diğerinden bağımsız sürüm çıkarabiliyor mu
Düzenin işleyip işlemeyeceğine karar veren soru budur. Dış ekibin sürümü sizin hattınızı, onayınızı ya da dağıtım pencerenizi gerektiriyorsa, hızlarını sizin ekibinizin takvimi belirler ve tam olarak kaçınmaya çalıştığınız yönde bir bağımlılık yaratmış olursunuz.
Ayrı depolar, ayrı hatlar, ayrı ortamlar. İki sistem tanımlı bir arayüzde buluşur ve her taraf, o arayüzü değiştirmeyen her şeyi sormadan yayınlayabilir.
Arayüzün kendisi değişmesi gerektiğinde bu, önceden haber verilen ve iki tarafı ilgilendiren planlı bir olaydır. Bu da ikinci kararı getirir.
Karar 2: Her veri parçasının sahibi kim
Her tablonun, her varlığın, her durum bilgisinin tam olarak tek bir sahibi olur. Sahip onun biçimini değiştirebilir. Diğer herkes onu anlaşılmış bir yoldan okur ve ona yazmaz.
Hata biçimi, iki ekibin aynı kayıtlara, alanların ne anlama geldiğine dair farklı varsayımlarla yazmasıdır. Bu, haftalar sonra ortaya çıkan, tek bir değişikliğe kadar izlenemeyen ve çözülmesi pahalı olan veri bozulması üretir. İki ekip bir sistemi paylaştığında ters giden en kötü şey açık ara budur.
Pratikte:
- Çekirdek iş verisinin sahibi mevcut sisteminiz kalır. Yeni ürün onu bir API ya da kopya üzerinden okur.
- Yeni ürünün oluşturduğu verinin sahibi yeni üründür.
- Yeni ürünün çekirdek veriyi değiştirmesi gerekiyorsa bu, sizin ekibinizin sahip olduğu ve doğrulama yapan bir uç nokta üzerinden olur. Doğrudan yazım değil.
- İki taraftaki şema değişiklikleri önceden haber gerektirir. Ne kadar önceden olduğunu kararlaştırın.
Karar 3: Kim aranır ve ne için
Her sistem bozulan taraf olduğunda ne olacağını yazın. Yeni ürün çökerse kim aranır ve yanıt süresi nedir? Çekirdek sisteminiz çökerse ve bunun sonucu olarak yeni ürün çalışmazsa, yeni ürünün kullanıcılarına kim haber verir?
İnsanların unuttuğu durum kısmi arızadır: sisteminiz çökmemiş ama yavaştır, yeni ürün zaman aşımına uğrar ve iki ekip de sorunun diğerinde olduğuna inanır. Her tarafın kendi sağlığını nasıl raporlayacağını önceden kararlaştırın ki bu sorunun bir cevabı olsun, tartışması değil.
Neyi paylaşmalı, neyi paylaşmamalı
| Paylaşın | Paylaşmayın |
|---|---|
| Tasarım dili ve terminoloji | Kod tabanı |
| Tek sağlayıcı üzerinden kimlik doğrulama | Doğrudan veritabanı erişimi |
| Arayüz sözleşmesi, yazılı olarak | Dağıtım hatları |
| Arıza iletişim kanalları | Başlangıçta nöbet sıraları |
| Kilometre taşlarında mimari incelemeler | Günlük kod incelemesi |
Kalıp şu: altyapıyı değil kararları paylaşın. İki ekibin "müşteri"nin ne demek olduğunda anlaşması bir toplantıya mal olur ve aylar kazandırır. İki ekibin dağıtım hattını paylaşması her hafta ve sonsuza kadar bir şeye mal olur.
İnceleme sorusu
Mühendisleriniz çoğu zaman dış ekibin kodunu incelemek isteyecektir. Doğru cevabı belirlediği için önce sebebi anlayın.
Mesele kaliteyse, bir kilometre taşında tek seferlik bir mimari inceleme size güvencenin çoğunu zamanın küçük bir kısmına verir. Mesele kodun ileride onların sürdüreceği olmasıysa, çözülmesi gereken şey inceleme süreci değil devir planıdır; bunu yeni ürünün sahibi kim olur yazısında ele aldık.
Sürekli inceleme, bütün düzeni sessizce bozan seçenektir; çünkü kıdemli mühendislerinizi yeniden kritik yola koyar.
Ali Boran Gazel