AGILE Devrimi

AGILE, Dünya üzerinde kabul görmüş bir yaklaşımdır. Birçok şirket bünyesinde bu yaklaşımı hayata geçirmeyi sürdürüyor. AGILE’ı bu kadar cazibeli yapan parametreler Çeviklik ve şeffaflık üzerinde yoğunlaşıyor.

CIO Update Dergisi 2019 Aralık sayısında bu yazım “AGILE Devrimi” yayınlanmıştır.

AGILE’ı bir metodoloji olarak ele alırsak eğer, bu metodoloji’nin ortaya çıkmasında rol oynayan sebepleri incelemek gerekir. 1980’li yıllarda bir ekip ile iş geliştirmek çok zordu. Ekip üyelerinin sayılarının artması ve müşteriden gelen taleplerin yığılması stresi de beraberinde getirmekteydi. Bir yazılım tasarımı ortaya çıkarabilmenin maliyeti çok yüksekti bunun sebebi ise gereksiz çok zaman harcanmasıydı. Memnuniyetsizlik, başarısız sonuçlar, kestirilemeyen problemler gibi birçok sebepten dolayı İş Geliştirme Yöntemi önemli bir konu haline geldi. Firmalar Zaman/Maliyet hesaplamalarını Gantt şeması üzerinden planlıyor ve  WaterFall yöntemi ile iş akışlarını belirleyip projeye start veriyordu. Bende meslek hayatımın ilk yıllarında birkaç kez Gantt şemasını kullanan firmalarda görev almıştım fakat başarıyı tam yakalama gibi bir durum söz konusu olmadı.

Talep edilen bir geliştirmenin birkaç ay gibi bir süre sonunda müşteriye henüz gösterilmemiş olması hem müşterinin hem de proje ekibinin motivasyon kaybına sebep olabilir. Müşterinin talep ettiği geliştirmeleri bir yöntem uygulamadan geliştirme sürecine dahil etmek de yığılma sorunları ve hata çözümleme süreçlerinin iflas etmesine sebep olabilir.

AGILE tamda bu noktada devreye giriyor. AGILE Yaklaşımı projenin başarılı bir şekilde tamamlanması veya yürütülmesi için yöntemler sunuyor. Taleplerin hızlı bir şekilde çözümlenmesi ve müşteriye sunulması AGILE’ın en önemli çıktısıdır.

AGILE’ı  diğer tüm yaklaşımlardan ayıran özellik Iteration’dır. Iteration bir görevi defalarca kez bir yöntem üzerinden uygulamayı gösterir. Projenin ufak parçalara bölünmesi ve her bir parçayı development sürecine dahil ederek Planlama, Tasarım, Test ve Onay gibi adımlardan geçip bir başka Iteration’un tamamlanmasını beklemek, parçaların çevik bir şekilde tamamlanmasını sağlamaktadır.

Scrum Yaklaşımı

Scrum, AGILE’ın bir framework’üdür.  AGILE temelde benzer yapılara sahip olduğu alt kollara sahiptir. Scrum’da bu kollardan biridir. Scrum Süreç olarak 3 temel prensip üzerine kuruludur. Bunlar;

  • Şeffaf Olmak
  • Kontrol Etmek
  • Değişime Açıklık

Proje sürecinin, problemlerin, geliştirmelerin açık ve net olarak herkes tarafından görülebilir olması gerekir. Scrum’ın en belirgin çıktısı şeffaf olarak yürütülen süreç içerisinde oluşan aksaklıkların net bir şekilde açığa çıkmasıdır. Bir problem var ise anında o noktaya çözüm uygulanıp sürecin kesintiye uğramasına engel olur ve süreci sürekli olarak iyileştirme yönünde takımın motivesini sağlar.

Proje, geliştirme süresince sürekli bir değişim talebi alabilir. Projenin sonunda dahi değişiklik talebi kabul edilebilir olmaktadır. Bir bütün olarak çözüme gidilmediği için küçük parçalar halinde çevik bir şekilde çözüm sağlanmaktadır. Alınan talepler küçük parçalara bölünerek bir sıralama mekanizmasına eklenir ve burada planlama aşamasını bekler.

Proje geliştirme sürecinde ekip içerisinde kopukluklar en aza indirilir. Günlük Scrum Event’ı ekibin sürekli iletişim halinde kalmasını sağlar.  Scrum Event’larının süresi yapılan araştırmalar sonucunda 10-15  dakika olarak tavsiye edilmektedir. Nedeni ise ekip içi iletişimi sağlamlaştırmak isterken, bir anda tam tersi bir durumla karşılaşmamanız. Bu süre deneyleyerek belirlenebilir. Ekip içi yapılan Event’lar ile projenin takvim üzerinde nerede olduğunu, hangi noktalarda tıkanıklığın olduğunu ve çözümün daha başarılı sonuçlar ile geldiğini görebilmekteyiz.

Scrum Takımı; Geliştirme Takımı, Ürün Sahibi ve Scrum Master’dan oluşmaktadır. Yöntemsel olarak farklı ekiplerin işleyişine müdahale edilmesi mümkün olmamaktadır. Scrum Takımı işleri başarılı çözüme ulaştırmak için yöntemleri kendi aralarında kararlaştırabilirler.  Ürünün İterasyon ile parça parça tamamlanması yani “Done” olması, hali hazırda bekleyen başarılı ve onaylanmış teslim edilebilir ve feedback alınabilir hale gelmesini sağlamaktadır.

Ürün Sahibi yani Product Owner ürünün değerini yüksek tutmakla sorumludur. Geliştirme takımı da Product Owner dışında kimseden iş alamaz/talep edemez/kabul edemez. Ürün listesi Product Backlog listesinde Product Owner tarafından yönetilir.

Geliştirme Takımına ürünü teknik olarak nasıl geliştireceğini hiç kimse söyleyemez. Geliştirme takımı profesyonellerden oluşmaktadır. Ürünleri geliştirmek için gereken tüm becerilere sahiptir. Scrum, Geliştirme Takımı içerisinde geliştiriciden başka hiçbir unvanı tanımaz. Takım Lideri/Teknik Lider ancak bir geliştirici üye olarak dahil olabilir.

Sprint,  Scrum sürecinin en temel yapı taşıdır.  Tüm süreç aktiviteleri Sprint içerisinde gerçekleşir. Scrum süreci 1 ayı geçmeksizin birbirini ardı ardına takip eden Sprint’lerden oluşmaktadır.  Scrum planlama event’larında belirlenen işleri ekiplerin tamamlaması için küçük parçalar halinde ekip üyelerine aktarılır ve Sprint süresi boyunca bu işlerin takibi yapılır.

Çoğunlukla 2 haftalık Sprint’ler planlanmaktadır. Sprint öncesi, sonrası ve ortasında farklı event’lar yapılması Sprint’in başarılı bir şekilde tamamlanmasını olumlu yönde etkilemektedir.

Sprintler; Sprint Planning, Sprint Review, Sprint Retrospective, Daily Scrum’dan oluşmaktadır.

Sprint boyunca, hedefi tehlikeye sokacak değişiklikler sürece dahil edilmez, değişiklikler bazı event’lar yapılarak enjekte edilebilir fakat bunun dikkatli bir çalışma ile yapılması gerekmektedir.

Scrum Master, takımına süreç boyunca destek vermelidir. Sprint’in günlük 8 saatle sınırlı planlaması yapılır ve bu sürenin aşılmaması konusunda ekip üyelerine bilgi aktarılır.

Sprint Review, Sprint tamamlandıktan sonra gerçekleşecek olan bu event’ın ana konusu; sorun var ise bunu anlamak ve çözüm için bir sonraki Sprint’e bilinçli yaklaşmak, takım içi iş birliğinin güçlendirilmesi olarak düşünülebilir.

Sprint Review’a Product Owner, Paydaşlar ve Scrum Takımı katılır. Bu ritüelin öncesinde bir Daily Scrum ile hangi noktada olunduğu görülebilir.  Done ve UnDone PBI(Product Backlog Item)’lar belirlenerek Sprint Review sunumu hazırlanır. Sprint süresine göre event’ın süresi de ortaya çıkabilmektedir. 2 haftalık bir Sprint için maksimum 2 saat tavsiye edilir.

Sprint Planning, Bir sonraki Sprint için yapılan planlar bu event içerisinde belirlenir. Sprint içerisinde çözülecek işlerin miktarını geliştirme takımı belirler ve bu işler planlamaya alındıktan sonra Sprint Backlog’ta tutulur.

Sprint Retrospective,Sprint süresince ve ya iş akışı üzerinden takım içi ilişkiler, kişiler, kısaca bir çok etken üzerinden değerlendirme yapılan, daha iyiye ulaşmak için sorunların ve çözümlerin tartışıldığı event’dır. Herşeyin iyi gitmesi ve sorunsuz bir süreç yakalamak yeterli gibi görünse de sürekli geliştir ve her zaman daha iyiye git kuralını unutmamak gerekiyor. Bu kurala Kaizen denilmektedir.

Daily Scrum, Günlük yapılan Scrum event’ları genellikle ekip içi sorulara cevap aramak/iş hakkında bilgi paylaşımı için yapılır. 15 dakika bu event için tavsiye edilen süredir.

Günlük yapılan event’lar takımın Sprint hedefini gerçekleştirme ihtimalini olumlu yönde etkiler. Çünkü her gün işler üzerinde ki pürüzler var ise tartışılır ve o pürüzleri ortadan kaldırmak üzere aksiyon alınır. Bu şekilde ilerlemenin önü kesilmemiş olur.

  • Dün ne yaptım?
  • Bugün ne yapacağım?
  • Takıldığım bir nokta var mı?

Kaizen, japoncada “Kai” ve “Zen” kelimelerini birleşmesi ile bir anlam ifade etmektedir. Değişim ve Daha İyi kelime öbeğini barındıran bu ifade “Sürekli İyileştirme” anlamına gelir. Sonuçların daha iyi olabilmesi için Takım elemanları Kaizen için süreç içerisinde çok  önemli bir noktadadır. Bu nedenle takım işleyişi çok önemlidir ve sürekli iyileştirilmesi gereken bir yapıdır.

Sorunların çözümü için farklı görevler üstlenen ekipler kurarak  temelden çözümlerin üretilmesi hedeflenmiştir.  Kaizen’in temelinde süreç odaklı iyileştirme olduğu için sonuca bakılmaksızın sürekli sürecin iyileştirilmesi başarı getirmektedir.

Sürekli iyileştirme kavramının temelinde, her gün bir önceki günden daha iyi olma hedefi yatmaktadır. Kaizen, istek ve potansiyel enerji ile başlayan projelerin motivasyon kaybı, erteleme ve vazgeçme gibi durumlara karşı gelişen bir felsefe olduğu için, ufak adımlarla geniş çaplı değişimleri hedeflemektedir. Ufak adımlar takım’ın alışkanlıklara karşı göstermiş olduğu direnci ortadan kaldırmaktadır.

KANBAN

Kanban, 1940’larda iş akışlarını daha iyi hale getirmek için geliştirilmiştir. Japonca’da Kanban kelimesi, Tahta ve tabela gibi anlamlara gelmektedir. Kanban kaynakları daha verimli ve daha yönetilebilir halde kullanabilmek için çözümler sunmaktadır. Kanban’ında Scrum gibi özünde çeviklik ve şeffaflık vardır.

Önceden planlanan ritüel’leri bulunmamakla beraber alınan aksiyonlar gelişmelere göre şekillenmektedir. Lead Time ve Cycle Time terimleri ifade edilen planlamalar yapılabilmektedir. Bir talep geldiği andan itibaren çözülüp tamamlanma sürecine kadar geçen süreye Lead Time denilmektedir. Örnek olarak, canlı ortamda bir hatanın farkına varılmasıyla başlayan sürecin o hatanın çözüldüğü zamana kadar geçen süre olarak düşünebiliriz.

Lead Time daha çok müşteri tarafını ilgilendiren bir durum olarak karşımıza çıkmaktadır. Cycle Time ise talebin geliştirme aşamasından itibaren sürecin başlamasıdır. Geliştirme aşaması Cycle Time ile başlamaktadır.  Geliştirme tamamlandığında Lead Time ve Cycle Time tamamlanmış olur.

Kanban’ın hedeflerinden birisi ise Lead Time’ı düşürmektir. Bu şekilde daha çevik dönüşler yapılabilmektedir.

Kanban temelde prensipleri Sınırlandırmak ve Görselleştirmek üzere iki ana madde üzerinden çalışmaktadır. İşlerin görselleştirilmesi bir Board üzerinde takip edilebilir olmasıdır. Board üzerinde Taleplerin başlama adımı ile tamamlanma adımları arasında bir süreç takip edilir. Bu süreç New, ToDo, In Progress, Test, Done olarak düşünülebilir. İşler bu board üzerinde soldan sağa doğru ilerlemektedir.

Sınırlandırma ise süreç içerisinde bulunan adımların paralelde maksimum kaç iş barındırılabileceğidir. Kanban buna WIP(Work in Process) adını vermiştir.  Geliştirici sayısı ve bekleyen iş sayısı WIP sayısını belirleyebilir. WIP’in Lead Time’ın düşmesinde etkisi büyüktür. İşlerin daha kaliteli çıktılar vermesi muhtemel sonuçlardan birisi olarak görülebilir.

Scrum ile Kanban’ın bazı farklılıkları bulunmaktadır. Scrum, geliştirme için bir zaman limiti uygular, yani geliştirme Sprint içerisinde devam eder ve tamamlandığında yeni bir Sprint planlanarak yeniden başlanır. Kanban’da ise geliştirme sürekli olarak devam eder. İş geldikçe çözülüp tamamlanır. Limit belirlemek opsiyonel olarak kullanılabilir bir yöntemdir.

Kanban’da Event’lar bulunmamaktadır. Aksiyon’lar süreç içerisinde ki gelişmeler göre alınır. Scrum’da ise Sprint Planlama, Sprint Retrospective gibi Event’lar bulunmaktadır. Bu şekilde tüm süreç takip edilerek aksiyon planlamaları yapılmaktadır.

Scrum’da iş maddelerinin küçük parçalara bölünmesi kuralı bulunmaktadır. Bu sayede çeviklik sağlanır. Kanban’da ise bunun bir kısıtlaması bulunmamaktadır. Yapılacak işlerin büyüklüğü veya küçüklüğü opsiyonel bırakılmıştır.

Scrum için bazı Roller bulunmaktadır. Product Owner, Scrum Master, Geliştirme Takımı gibi, Kanban’da bu roller belirlenmemiştir.

Kanban Board müsait oldukça yeni işler eklenebilir. Geliştirme ekibi sürekli board üzerinde bekleyen iş görebilir. Geliştirme sürekli devam eder ve işlerin akışının kesilmemesi sağlanır. Scrum’da ise Sprint’e yeni bir iş eklenemez. Bunun nedeni, Scrum Takımı sürekli olarak kısa hedefler koyar. Her hedefe ulaştığında bir inceleme yapar ve daha iyi sonuçlar elde etmek için kararlar alır. Kanban’da kısa vadede konulan hedefler yoktur.

Scrum Board’ı her Sprint’te yeniden düzenlenir. Kanban Board ise kalıcı olarak sürecine devam eder. İşler sürekli akış içerisindedir.

Tabi bunun yanı sıra bazı benzerlikleride bulunmaktadır. Scrum ve Kanban’ın temelinde çeviklik vardır. Her ikisinde de bazı kısıtlamalar vardır. Scrum bunu Sprint ile yapıyor, Kanban ise WIP(Work in Process).

Perspektif Açıdan MicroService

Microservice, günümüzde çok popüler bir konu olarak karşımıza çıkmaktadır. Popülarite kazanmasını sağlayacak bir çok sebep bulunuyor. Her projenin Microservice Mimarisinde geliştirilmesi gerektiğini söyleyemeyiz. Avantaj ve dezavantajlarını değerlendirerek uygulamak en mantıklı çözüm yolu olarak görünüyor. O halde Ne, Neden, Ne Zaman sorularına cevap bulmaya başlayabiliriz. 

Microservice Mimarisini incelemeden önce Monolithic olarak geliştirilmiş bir proje hangi konularda dezavantaj oluşturduğuna değinmek daha sağlıklı olacaktır.

Monolithic Mimarisi, Self-Contained olarak tasarlanan projelere denilmektedir. Bu tip projeler genellikle birbirine bağımlı olarak tasarlanmış olması dikkat çekmektedir. Öncelikle dezavantajlarından bahsetmek gerekirse;

  • Component’lerin aynı framework üzerinde geliştirilmiş olması gerekir. Bu başlarda sorun gibi görünmese bile projenin ilerleyen süreçlerinde sorun haline dönüşecektir.
  • Ekiplerin birbiri ile çalışması git gide zorlaşır.
  • Versiyonlam sorunları artmaya başlar.
  • CI & CD aşamalarının zorlaşır
  • Scaling

Monolithic olarak tasarlanan projeler başarılı olamaz gibi bir cümle kurmak mantıklı olmayacaktır. Avantaj ve dezavantajlar değerlendirilerek projeyi geliştirmek daha mantıklı bir hareket olacaktır. Monolithic Mimari üzerine tasarlanan projeler tabii ki başarılı olabilir fakat yükselen internet kullanımı ile yük altında çalışabilen uygulamalar sınıfına dahil olması biraz zor görünüyor. Bunun en büyük sebebi ölçeklendirme şeklidir. Monolithic tasarlanan uygulamalar Scale Up dediğimiz Dikey Ölçeklendirme ile yük altında çalışabilir hale geliyor. Bu maliyetli bir yöntemdir ve yönetilmesi zamanla zorlaşmaya başlar. Kaynak tüketen uygulamanız için sürekli Ram yükseltmek veya CPU arttırmak çözüm gibi görünse bile zamanla bağımlılığınız daha fazla artmaya başlayacak ve upgrade sorunları yaşamanıza sebep olacaktır.   

MicroService ise bir bütün olan uygulamanızı en ufak fonksiyonel parçalar halinde modüler bir biçimde ayrışmasıyla ortaya çıkıyor. Her bağımsız modülün birbirinin çalışmasına engel olmayacak şekilde izole olması tüm sistemin daha sağlıklı çalışmasını sağlıyor. Her bir modülü, yalnızca bir göreve odaklanıp sadece o göreve ait işleri yürüten mekanizmalar olarak tanımlayabiliriz. Bu şekilde her bir modülü farklı bir teknoloji ile geliştirebilirsiniz. Her bir modül için farklı database seçeneklerini değerlendirmeniz mümkün görünmekte.

MicroService, modüler yapıya sahip olması nedeniyle “Loosely Coupled” oldukça bağımsız çalışabilir ve deploy edilebilir. Herhangi bir modülünüzün yeni versiyonunu deploy etmeniz bir diğer modülünüzü etkilemez. Bu şekilde tüm uygulamanızı deploy etmek yerine sadece değişiklik yaptığınız modülü deploy etmeniz yeterli olacaktır. Bu şekilde ekipler birbirinden bağımsız çalışabilir ve hızlı bir şekilde geliştirme ve test süreçlerini tamamlayabilir. Aralık 2019 “AGILE Devrimi” yazımda ekibin Lead Time ve Cycle Time sürelerinin yönetimsel olarak nasıl düşürülebileceğine değinmiştik. Cycle Time, geliştirme sürecinin performansına göre seyir eden bir zaman dilimiydi. MicroService mimarisi bu noktada çözüm önerisi gibi görünmektedir. MicroService Mimarisinin tercih sebeplerinden birisi ise Scale Out(Yatay Ölçeklendirme) kolaylığı. Scale Out her geçen gün daha fazla önem kazanan bir konu haline geldi. Yatay olarak ölçeklendirilen sistemler kolaylıkla yönetilebilir durumdadır. Yük altında çalışan uygulamalar hızlı manevralar ile başarılı sonuçlara ulaştırılabilir.

MicroService Mimarisinin artı yönlerinin çok fazla olduğu ortaya çıkarken eksi yönlerinide incelemekte fayda var. Projeniz için mimari kararı vermeden önce artı ve eksileri mutlaka göz önünde bulundurmalısınız.

Bağımsızlık, Microservice için en önemli konudur. Microservice Mimarisi kararını aldıktan sonra bağımsız servisler kurgulayarak ilerleyemezseniz eğer Microservice Mimarisi bozulmaya ve Monolithic yapıya doğru bir yol almaya başlayacaktır. Bu performans kaybı, ölçeklendirilememe, çalışma zorluğu, okunulabilirlik gibi bir çok konuda sisteminizin puan kaybedeceğini gösterir. Microservice Mimarisi fikri ile başlayıp sistemi teknik olarak daha karmaşık hallere getirebileceğinizi de göz önünde bulundurmanız ve karar vermeniz gerekir.

Test süreçlerinin uygulanmasında zorluklar Microservice’de genellikle yaşanan bir sorundur. Farklı teknolojiler ve farklı veritabanı kullanımları sistemin dağıtık olması test senaryoları geliştirmenizi zorlayacaktır. Bu konuda test süreçlerini iyi planlamanız gerekmektedir. Yine aynı şekilde yönetim ve metrikleri takip etmeniz zorlaşabilir. Dağıtık sistemlerde uygulamanın metriklerini farklı farklı servisler için bağımsız bir şekilde takip etmeniz gerekecektir. Bunun için her teknoloji ve ya servis için birbirinden bağımsız tool’lar kullanmanız ve bu tool’ların yönetimini sağlamanız gerekecek.

Deployment çok dikkat edilmesi gereken bir adımdır. Dağıtık sistemlerde deployment’lar her bir servis için ayrı ayrı birbirinden bağımsız şekilde yönetilmeli. Bu durumda deployment’lar arasında versiyon farklılıkları ortaya çıkacaktır. Bu sürecin profesyonelce yönetilmesi ve takip edilmesi gerekiyor.

Microservice, Monolithic Mimariye göre daha yüksek başarıya sahip olsa da, operasyonel olarak fazla karmaşık bir yapıdadır. Yönetimi tam yapılamadığı zaman daha büyük sorunlar ortaya çıkarabilecek bir yapıya sahiptir.

Büyük sorunların ve yük altında çalışan uygulamaların Microservice Mimarisine geçişiyle firmalarda da büyük kültür değişimleri oldu. Değişime açık, bağımsız uygulama geliştirme konusunda çok fazla tecrübe kazanıldı. Netflix, Amazon gibi büyük firmaların 700’den fazla servis ile uygulamalarını Microservice Mimarisine geçirdiklerini biliyoruz.

Performans için Struct ve Class Kavramları

Performanslı Web Uygulamaları geliştirirken dikkat edilmesi gereken bir çok nokta bulunmaktadır. Biz Struct ve Class kavramlarını inceleyeceğiz.

Struct ve Class Traffic
Hanny Naibaho‘nun “The Tunnel” isimli fotoğrafı Unsplash’ten alınmıştır.

Struct ve Class’lar birbirlerine benzer özellikler içermektedir. En önemli farklılıkları Memory üzerindeki davranışlarıdır. Struct bir Value Type, Class ise Reference Type’tır. Bu çok önemli bir detay.

Reference Type ve Value Type ile ilgili yazıma bu linkten ulaşabilirsiniz.

Struct ve Class arasında Constructor farklılıkları da bulunmaktadır. Struct için Default Constructor oluşturulduğunda Derleyici Hatası alınır. Fakat parametrik bir Constructor tanımlaması yapılabilir. Class için Default Constructor engellemesi yoktur.

Class’lar kalıtım yolu ile başka bir sınıftan türetilebilirler. Struct’ta ise böyle birşey yapılamaz. Fakat Struct yapınıza Polymorphism uygulayabilirsiniz. Bu konularla ilgili paylaşacağım bazı forum tartışmaları bulunmaktadır.

https://stackoverflow.com/questions/2310103/why-c-sharp-structs-cannot-be-inherited

https://stackoverflow.com/questions/1222935/why-dont-structs-support-inheritance


New anahtar sözcüğü kullanılarak oluşturulan bir Struct nasıl bir çalışma sergiler örnekle inceleyelim.

Bu şekilde StructSample’ın instance’ı alındığında içerisinde bulunan property’lerin default değerleri atanmış olacaktır. Eğer New anahtar sözcüğü kullanılmasaydı, “Use of possibly unassigned field” hatası alacaktık.

Class’larda olduğu gibi instance alma zorunluluğu yok ama Struct’larda property’leri kullanabilmek için default değerleri tanımlanması gerekiyor.

Struct ve Class Ne Zaman Kullanılmalıdır?

Büyük boyutlara sahip datalarınız için Class kullanmanız daha mantıklıdır. Bunun nedeni Memory yönetimidir. Büyük boyutlu dataların Struct ile Stack’te tutulması performans kaybına yol açacaktır. Aynı şekilde Küçük boyutlara sahip datalarınız için Class kullanırsanız gereksiz yere Heap’i şişirmiş olursunuz. Bu performans açısından büyük bir etkendir.

Çok beğendiğim bir yazıyı paylaşıyorum incelemenizde fayda var.

http://clarkkromenaker.com/post/csharp-structs/

Sonuç

Bu basit görünen seçim bazen size çok fazla hafızaya mâl olabilir, bu yüzden akıllıca seçin!

Object reference not set to an instance of an object

Uygulama geliştirirken en çok karşılaşılan hatalardan birisi hakkında kaçınılması gereken bazı davranışlardan bahsedeceğim.

Hata aslında çözümü kendi içerisinde bahsediyor. Bunu görebilmek/anlayabilmek çok zor ve mutlaka tecrübe gerektiriyor. Basit bir dil ile bu hatanın açıklaması Null olan Referans tipinde bir nesne kullanmaya çalışıyorsun

Reference Type ve Value Type

C#, Value Type ve Reference Type olmak üzere iki tür veri tipine sahiptir. Value Type, veriyi taşıyan ve bellek üzerinde taşıdığı veri kadar alan kaplayan bir tiptir. Reference Type ise bellekte sadece verinin tutulduğu adres bilgisini tutar.

Reference Type

  • String
  • Object
  • Class
  • Interface
  • Pointer

Value Type

  • Int
  • Float
  • Double
  • Decimal
  • Char
  • Bool
  • Enum
  • Struct

Liste alt kırılımlara daha da detaylandırılabilir fakat “Object reference not set to an instance of an object” hatasının sebebini kavramak için bu kadar yeterli.

Örnek vermek gerekirse, ilk değer atamasız Integer ve ya Double bir tanımlama yaptığınızda. Belleğin Stack bölümünde bir alan açılıyor ve değeri buraya hemen taşınıyor. Type’ları incelerseniz eğer Integer örneğin “0” olarak atanır. Bu nedenle ilk ataması yapılmayan bir Value Type sizi çok sıkıntıya sokmaz.

Reference Type, ilk ataması yapılmaz ise bellek için bir şey ifade etmez. “Not Reference(Referans Yok)” statüsündedir. Bu nedenle yeni bir instance alınmadan bu tipi kullanmak istediğinizde “Object reference not set to an instance of an object” hatasını alırsınız.