emrahday

  • 110
  • 2
  • 1
  • 0
  • geçen hafta

immutable

yazılım mühendisliğinde bir değerin değiştirilemez olması demektir. peki böyle bir değere neden gerek vardır ? ilk planda verinin korunması amacıyla böyle bir şeye ihtiyaç varmış gibi duruyor ama aslında bunun çok önemli bir mimari karşılığı var ve büyük bir uygulama geliştiriyorsanız “immutable” kavramı ile içli dişli olmanız çok olası. ayrıca fonksiyonel programlamanın ne demek olduğunu kavramak ve object oriented programlamadan farkını daha iyi idrak etmek için en önemli konu budur.

bu kavram ile aslında farkında olmadan birçok yerde karşılaşıyoruz. ben daha iyi anlaşılması için soyut yazılım mühendisliği yerine daha somut olan otomotiv sanayisi üzerinden ifade edeyim durumu.

bir tane araba firması düşününün, ürettiği arabaları belli standartlara göre üretiyor ve aracı satılması için dağıtım ağına gönderiyor. örneğin alman bmw firmasının ürettiği aracı, türkiye'de ana firmadan farklı borusan firması ithal ediyor ve türkiye’deki aracın satışı, bakimi gibi islerle bu yerel firma ilgileniyor. sonra bu yerel ithalatçı firma da bu aracı türkiye’nin birçok yerinde farklı araba showroomlarina, galerilere satıyor. bu satılan arabalar almanya’dan nasıl çıktıysa büyük oranda müşterinin eline kadar değişmeden geliyor.

peki durum farklı olsaydı nasıl olurdu? araçlar almanya’dan çıktıktan sonra örneğin ithalatçı firma araçların lastiklerini kendi anlaşmalı olduğu firmanın lastikleri ile değiştirse, lokal satış galerileri aracı büyük oranda değiştirip öyle satışa sunarsa son kullanıcının elindeki araç ilk üreten firmanın ürününden büyük oranda farklı olurdu. üreticiden çıkan araç üretim ağının herhangi bir noktasında bir önceki veya bir sonraki halinden çok çok farklı özelliklere ama en önemlisi farklı problemlere sahip olurdu. bu da bu problemleri analiz etmeyi ve problemlerin çözümünü zorlaştırırdı.

mesela bmw müşterileri aracın frenlediğinde yeterince iyi durmadığı şikâyeti ile geldiğinde bu problemin nedeni değişen lastikler, ya da değişine fren balata sisteminden olabilir, ve asla aracın gerçekten ilk çıktığı zamanda da bu probleme sahip olup olmadığına emin olamazdık. kimse problemin kaynağını tam olarak tespit edemezdi. hele problem tek bir noktadan kaynaklı değil de örneğin o lastik ile o balatanın hiç bilinmez şekilde uyumsuz olması ve problemin tek bir kaynaktan değil de birçok farklı kaynaktan gelen durumun sonucu olursa ne üretici firma ne ithalatçı ne de son satan firma isin içinden çıkamazdı.

işte bu noktada ilk çıkan urun belli oranda değişmez “immutable” olur ise bir problemle karşılaşır isek bu problemin kaynağına iner, orada gerekli incelemeyi yapar, problemi çözer ve kendimizden emin şekilde urunu dağıtabiliriz. yani araç hatası ile doğrusu ile ilk çıktığı gibi olur.

iste yazılım mimarisi de ayni bu duruma sahip. bir veri bir kaynaktan çıktıktan sonra birçok farklı sitem üzerinden geçer, her sistem bu verinin bir noktasını kullanır ve bir başka sisteme devreder. örneğin databaseden çıkan bir veri bir programlama dili üzerinde ilk haline gelir daha sonra çeşitli “pipeline” üzerinde gerekli “stack” ve “queue” larda tutulur, sonra farklı “thread” ler veriyi kullanır, çeşitli “message queue” lar veriyi farklı lokasyonlarda çalışan sunuculardaki “microservices” lere gönderir, onlar da verinin içinden bir şeyleri kullanır ve veri bir noktada seyahatini bitirir. ama bu seyahat sırasında birçok farklı kod parçası bu veriyi islemek için yarışır ve kimi önce kimi daha sonra bu veriye erişir ve isler.

iste karmaşanın asil nedeni budur, bu veri immutable olmaz ise, yani veriyi her bir kod parçası kullanırken kendine gerekli kısımı kullandığı gibi bir yandan da bu veriyi değiştirir ise verinin tüm seyahati sırasında olası problemlere hazır olmamız gerekir. örneğin çalışan bir kodun ihtiyacı olduğu bir şeyi bir başka kod siler ise ne olur. belki hiçbir şey olmaz çünkü çalışan ilk kod o veriyi kullanır ve bir diğeri o veriyi aldığında o veri kullanılmış olduğu için silebilir. belki milyon denemede bile hiçbir problemle karşılaşılmaz. ama gün gelir de çalışan ilk kod çok farklı nedenlerden dolayı birkaç milisaniye geç çalışsa ve diğer ikinci kod o veriyi daha önce ele alıp gerekli değeri silerse iste o anda problemle karşılaşmamız olası.

bu durumun tespiti de o kadar karmaşık ki. bu durum belki geliştirme yapılan, veya testlerin yapıldığı cihazdaki donanımdan veya yükten dolayı oluşmamış olabilir ama belki de sadece gerçek sunucuda bu durumla karşılaşıyor olabiliriz. ya da belki de sunucu da anlık yüklenmeye göre belli bir sure bu durumla karşılaşıyor ama daha sonra bu problem önümüze çıkmamış olabilir. ya da ilk çalışan kodda eklediğimiz yeni bir özellik kodu birkaç milisaniye geciktirmiş olabilir. yani bir problemin oluşması birçok farklı durumun kombinasyonu olabilir ve bu kombinasyon o kadar büyük olabilir ki problemin üzerinde gerekli testleri yapmak ve çözmek imkânsız olabilir.

yani özetle değişebilen “mutable” bir veri ve bu veri birçok farklı kod parçası “thread” tarafından isleniyor ve hatta birkaç farklı cihazda çalışan “microservices” bu veriyi isliyor ise o zaman yazılan kodun ne zaman bozulacağına asla emin olamayız ve her zaman kodumuza kâğıttan yapılmış ve her an yıkılmak üzere olan bir kule edasıyla yaklaşmamız gerekir. bunun en kökten çözümü ise mümkün olduğunca “immutable” veri tipi ile çalışmaktır.

devamını okuyayım »