Yeniden yazmadan gerçek zaman­lı­lık

Bazı gereksinimler yeni bir sistem istiyormuş gibi görünür; yakından bakıldığında ise yalnızca eskisinin içinden yeni bir yol ister. Bu hikâye böyle bir gereksinimi anlatıyor. Kasıtlı olarak genel tutuldu — sistem, kişi ve zaman belirtmeden.

Durum

Yıllar içinde büyümüş, eski bir framework sürümü üzerinde çalışan bir sistem, yapıldığı işi yapıyordu: Harici API'ler üzerinden veri çekiyor, bunları içe aktarıyor ve gösteriyordu. Sonra yeni bir gereksinim geldi — arayüz, bu içe aktarmalardan sonra bir sonraki sayfa açılışını beklemeden gerçek zamanlı güncellenmeliydi. Mimari hiçbir zaman gerçek zamanlılık için tasarlanmamıştı.

Başlangıç varsayımları

Akla ilk gelen düşünce, hiç gerçek zamanlılık için tasarlanmamış bir sistemin bunun için yeniden yazılması gerektiğiydi. Gerçek zamanlılık bütünün bir özelliği gibi hissettiriyordu — mevcut bir tasarıma sonradan öğretilen değil, en baştan planlanan bir şey. Bu varsayım altında yeniden yazım dürüst cevap gibi görünüyordu.

Sorun

Yeniden yazım, tek bir yeni gereksinimi karşılamak için yıllardır doğru çalışan iş mantığını çöpe atmak anlamına gelirdi. Pahalı ve riskli olur, bilinen şeyler bir kez daha inşa edilirken diğer her şeyi durdururdu. Bedel gereksinimle hiçbir şekilde orantılı değildi — bir pencere açmak için bütün bir evi yıkmak gibi olurdu.

Neden

Yakından bakıldığında gereksinim sistemin tamamını değil, tek bir yolu ilgilendiriyordu: içe aktarılan verilerin arayüze nasıl ulaştığını ve arayüzün bir değişiklikten nasıl haberdar olduğunu. “Gerçek zamanlılık yeni mimari demektir” varsayımı yerel bir ihtiyacı küresel bir yeniden yapılanmayla karıştırıyordu. Sistemin farklı olması gerekmiyordu — yalnızca içinden geçen bir yolun yeniden düşünülmesi gerekiyordu.

Karar

Yeniden yazmak yerine veri akışı ve arayüzün güncellenmesi hedefli olarak yeniden tasarlandı — tam olarak içe aktarmadan görüntülemeye giden yol — ve geri kalan her şeye dokunulmadı. Karar, gereksinimin gerçekten dokunduğu küçük şeyi değiştirmekti; yalnızca dokunuyormuş gibi göründüğü büyük şeyi değil.

Uygulama

Değişiklik bilinçli olarak dar kapsamlı tutuldu. İçe aktarılan verilerin sisteme hangi noktada girdiği belirlendi; oradan arayüzü değişikliklerden haberdar eden bir yol oluşturuldu; ve arayüz, güncellemeleri geldikleri anda alacak şekilde uyarlandı. Mevcut sistem yaptığı işi yapmaya devam etti — yalnızca güncelleme yolu yeniydi. Küçük, sınırlı, geri alınabilir.

Avantajlar ve sınırlamalar

Sonradan eklenen yol, boş bir sayfada gerçek zamanlılık için doğmuş bir sistem tasarlarken çizilecek en zarif yol değil; eski varsayımların yanında duruyor ve onların mirasından biraz taşıyor. Bu, gereksinimi yeniden yazımın maliyeti ve riski olmadan karşılamanın bilinçli bedeliydi. Gerçek zamanlılık sistemin tamamına yayılmış olsaydı ya da eski mimari her değişikliğe aktif olarak direnseydi farklı karar verirdik — o zaman daha derin bir yeniden yapılanma daha dürüst cevap olurdu.

Ne öğrendik

Modern bir gereksinim nadiren modern bir sistem gerektirir. “Mimari bunu yapamaz” reflekslerinin çoğu yerel bir yeteneği küresel bir yeniden yazımla karıştırır. İşe yarayan soru “sistem bunun için mi yapıldı?” değil, “hangi yolun gerçekten değişmesi gerekiyor?” sorusudur — ve bu yol neredeyse her zaman sistemden çok daha küçüktür. Sistemi mahkûm etmeden önce yolu arayan, çoğu zaman kat kat daha ucuz bir çözüm bulur.

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

O zamandan beri “mimari bunun için yapılmamıştı” cümlesine önce daha küçük bir soruyla yaklaşıyoruz: Gereksinim hangi tek akışa dokunuyor? Böylece yeniden yazım ilk tepki olmaktan çıkıp son seçenek hâline geldi. Bir şeyi eski ilan etmeden önce neyin gerçekten yeni olması gerektiğini inceliyoruz.

İleri okuma

• Rehber: Big bang olmadan legacy modernizasyonu — mevcut sistemi değiştirmek yerine neden küçük adımlarla geliştirmek gerektiği.
• Uygulama kılavuzu: Bir legacy monoliti modernize etmek — yeniden yazım yerine hedefli müdahaleler için izlenecek yol.
• Rehber: On yıl sonra hâlâ çalışan yazılım — değiştirilebilirliğin bir sistemin zaman içindeki değerini neden belirlediği.
• Karar: Başlangıç noktası olarak modüler monolit — yapıyı her yerde değil, bir sorunun gerektirdiği yerde değiştirmek.

Temelinde Batunet Engineering Method yer alır: kararı problemin özelliklerine göre vermek, küçük ve geri alınabilir adımlarla inşa etmek.

Bir sistemi yetersiz ilan etmeden önce daha küçük soruyu sormaya değer: İçinden geçen hangi tek yolun gerçekten değişmesi gerekiyor? Bu yol neredeyse her zaman yeniden yazıma giden yoldan daha kısadır.