YAZILIM MIMARISI
Yazılım Mimarının 5 Yanlışı
Yazılım Sektöründe 20 yıla yakın farklı sektörlerde, farklı büyüklükteki projelerde, yazılım geliştirme ekiplerinde bulundum. İlk projemden itibaren mimari yapıyı oluşturma kısımlarında hep yer aldım. Bu yazıda mimari ortaya çıkarırken yaptığımız 5 yanlıştan bahsetmek istiyorum.
Bu yazının temeli denge üzerine olacak. Yazılım Mimarının kurması gereken denge. Aşağıda bahsedeceğim konularda bu denge kavramının çok önemli olduğunu sizlerde göreceksiniz;
- Fonksiyonel ve Fonksiyonel Olmayan Gereksinimlerin Gerçekleştirimi,
- Gereksinimleri ve Sorunları Doğru Teknik Alanlarda Çözmek,
- Değişime ve Yeni İsteklere Karşı Dirençli Olma Konusunu, Doğru Anlama,
- Her Türlü Problemi Çözebilecek Mimari Oluşturma Çabasının Sınırlarını ve Maliyetlerini Anlama,
- Mimarın yaptığı geliştirmeleri Ekibe AktarMaması.
1. Fonksiyonel ve Fonksiyonel Olmayan Gereksinimleri Doğru Şekilde İlerletmemek
Fonksiyonel gereksinimler bir sistemin nasıl davranacağı, iş kurallarını, akışı için gereksinimleri tanımlarken,
Örneğin: Kullanıcı sisteme kullanıcı adı ve şifresini girerek giriş yapabilecektir.
Fonksiyonel olmayan gereksinimler ise sistemin bu davranışları nasıl gerçekleştirdiği ile ilgilenir.
Örneğin: Kullanıcı şifresi her ortamda encrpyt ederek taşıyacak ve saklayacaktır. (Güvenlik Gereksinimi)
Özetle Fonksiyonel olmayan gereksinimler,
- sistemin davranışının,
- yeteneklerinin,
- genel karakteristiklerinin
kullanıcı deneyimi üzerindeki etkisidir.
Örneğin: Portability, Security ,Maintainability, Reliability, Scalability, Performance, Reusability, Flexibility, Accessibility, vb.
Bu tarz fonksiyonel olmayan gereksinimlerin ölçümlemesi , test edilmesi diğer fonksiyonel gereksimler den çok daha zordur. Geneli ilgilendirdiği için tüm sistem özellikleri bu genel yetenekleri de etkileyecektir.
Örneğin bir denetim uygulaması geliştiriyorsunuz. Bu denetim uygulaması belli ofislere gidip denetleme yapacak mobil bir uygulama olsun. Eğer ki bu denetlemeyi yapacak personelin yaşı büyük olduğu ve gözlerinin çok iyi görmediği ve düğmelere iyi basamadığını analiz etmiş iseniz. Fontların ve Düğmelerin Boyutları her ekran için etkilenecektir. Gördüğünüz gibi fonksiyonel olmayan gereksinimleri ele almak oldukça zordur.
FG=Fonksiyonel Gereksinim
FOG=Fonksiyonel Olmayan Gereksinim
- Bu durumda yukarıdaki görseldekine benzer bir ilerleme en doğrusu olacaktır. Fonksiyonel gereksinimlerde biraz ilerlemek çünkü FG biraz ilerlemeden FOG için gereksinimleri tam olarak anlayamazssınız. Öncelikle biraz sistem davranışını anlıyor olmanız lazım.
- Sürekli fonksiyonel gereksinimleri geliştirirseniz. İşin sonuna geldiğinizde riskli olan ve sistem davranışlarının tüm yapısına etkileyecek olan FOG uygulama ve denemede geç kalmış olursunuz. FOG düşündüğünüz şekilde yolunda gitmeyen durumların etkisini tüm önceden geliştirdiğiniz fonksiyonel gereksinimlere uygulamanız gerekir.
2.Gereksimimleri ve Sorunları Doğru Alanlarda Çözmemek
Yazılım mimari sorunları deneyiminin fazla olduğu alanlarda çözmeye çalışır. Çünkü bu yöntem ile kendisini daha güvende hisseder. Sorunu hangi alanda, hangi araçlara göre çözeceğiz ?
Örneğin
- Yazılım mimarı geçmişte veritabanı uzmanlığı ile geçmiş ise, sorunları veritabanı sorguları ve ara tabloları, tetikleme mekanizmaları, SQL stored procedures ile çözmeye çalışır.
- Yazılım mimarının geçmişte frontend uzmanı ise, olabildiğince backend ve diğer yapıları çok az kullanarak tüm veriyi client(istemciye) aktarıp sorunlarını tarayıcı ve UI üzerinden çözmeye çalışır.
- Yazılım mimarının geçmişte backend uzmanı ise, olabildiğince backend düşüncesiyle hareket eder.
- Yazılım mimarının geçmişte sistem ve DevOps ile uğraşmış ise bu yapıyı sistemler üzerinden dağıtık bir şekilde nasıl yapacağını düşünür ?
- Proje analizi, gereksinim analizi, proje yönetimi ile uğraşmış ise müşteri üzerinden sorunları veya yapıları tanımlaya çalışır.
Burada önemli olan yazılım mimarı dediğimiz kişi veya kişilerin geçmişte bu alanlarda deneyimi olup, sistemin gereklerini doğru alanlara eşleştirmek olmalıdır.
- Müşteri, Frontend, Backend, DevOps, DB, Cloud ile donanım, yazılım ve bunların iletişimlerini doğru bir şekilde parçalayabilme kabiliyetine sahip olmalıdır.
3.Değişime ve Yeni İsteklere Karşı Mimariniz, Ufak Yamalar ile Projenizi Ne Kadar Ayakta Tutabilirsiniz ?
Projelerin büyük bir çoğunluğunda baştan düşünülen, kağıt üzerinde yazılan ve tasarlanan ile sonuçta ortaya çıkan ürün arasında fark olur. Bunun farklı farklı nedenleri olabilir,
- Teknoloji değişmiştir,
- Müşteri konuya o anda çok hakim değildir,
- Sistem gereksinimlerini belirleyen yeni kişiler konuya dahil olmuştur,
- vb..
Hangi nedenden dolayı kaynaklanırsa kaynaklansın, mimari yapı ve bunun üzerinde tutulan veri model yapısı oturmaya başladıktan sonra sistem üzerindeki değişiklik yapmak zorlaşacaktır.
Burada mimarinizi bozmayacak yamalar veya ufak değişiklikler ile ilerlemeye ve bu istekleri sisteminize katmaya çalışırsınız. Ama belli bir aşamadan sonra katılamayacak durumada gelebilir. Eğer bu kısımda açık olmazsanız. Bu mimari bu istekleri karşılamaz şeklinde geribildirimlerde bulunmazsanız, müşteri ve ürün yöneticisi daha fazla istemeye devam edecek ve zaman içerisinde mimari kalmayacaktır. Daha sonrasında sistem her tarafından yavaş yavaş patlaklar ve hatalar verir.
Genelde son aşamaya kadar gerekli uyarıları vermeyen mimar rolündeki kişiler, gereksinim baskısı ve sistemin dağılması kısmını yönetemedikleri için istifa yöntemine veya o ortamdan çıkış yolu bulma yoluna gideceklerdir.
Diğer bir alternatif ise gerekli yerde yeni isteklere dur diyebilmektir. Bu mimarinin bu istekleri kaldırmayacağını belirterek, mimariyi baştan oluşturma veya yeniden kurgulama maliyetini dile getirmek ve yönetimi bu konuda ikna etmek gerekir.
Not: Bahsettiğim durum mimari bir takım ciddi değişiklikler de bile sistemin yeni gereksinimleri karşılamadığı durumdur.
4.Her Türlü Yeni Gereksinim İhtiyacınıza Karşı Mimarinizi Generic (Dinamik) Tasarlamanın Maliyeti
Bazı yazılımlar ihtiyaçtan dolayı dinamik ve genel tasarlanması gerekir.
Örneğin:
Oyun Level Tasarımı : Normalda bir oyun motoru yazılır ve bu oyun motorunun kendisine verilen level (bölüm) içerisindeki karakterleri oluşturmak için oyun editörleri bulunur. Bu oyun editörlerine bu eşyaları ve karakterleri koyduktan sonra bir senaryo koşulmasını ve bu karakterlerin davranışlarının tanımlanması gerekir. İşte burada bir Scripting yazılması gerekir. Oyun geliştirmede genellikle Lua ve Python scripting dillerden faydalanır.
Sigorta ve Bankacılık Skorlama ve Risk Sermaye Koşulları: Günümüz o kadar hızlı değişiyor ki sigorta ve bankacılık için risk ve sermaye koşulları sürekli değişir. Ekonomi, Afet, Deprem gibi konulardan etkilenir. Bu değişikliklerin skorlama ve risk durumlarına alan uzmanları tarafından yansıtılması gerekir. İşte burada kredilendirme ve skorlama araçları ve yapının üzerinde çalıştığı kural motorlarından oluşmuş altyapılar devreye giriyor. Bu sayede arka planda bu yapılara göre dinamik kod mekanizmaları çalıştırılıyor.. (Kampanya Sistemleride bu duruma benzer yapılardır)
AdHoc Araçları, Business Intelligence , Karar Destek Sistemleri : Şirket yöneticilerinin işletme hakkında sağlıklı kararlar alabilmesi için raporları dinamik oluşturabilmeliler. Özelleşmiş dinamik dashboard bu grafikleri ekleyerek bunlar üzerinden gösterim yapabilmeliler. Bunun için, verinin doğru şekilde çekilmesinden , birleştirilmesinden ve doğru görsel ve çizelgeler ile dashboard gösterilmesi ile yapılabilir. Bu tip mekanizmalar arka planda bir takım dinamik altyapısı ile mümkündür.
Uygulama Geliştirmek için No-Code, Low-Code Araçları : Bu tip araçlar sizin uygulama bileşenleri ve bunlar arasındaki ilişki ve bağlantılarını tanımlayarak dinamik bir takım scriptler yazarak bir uygulama oluşturmanızı sağlar.
BDD için Test Araçları : Bazı uygulamaların End-to-End testlerini statik kodlamak sürekli kırılgan olmasına ve sürekli bakıma neden olabilir. Birde Testi ilgili İş alanının uzmanlarının bu testleri yazması daha doğru olacaktır. Bu tarz yapıların kurulması için Cucumber vb… test araçları bulunur ve bu araçlar arka planda dinamik olarak test kodlarının çalıştırılmasını sağlar..
Ama bu tarz mimarilerde uygulamanın sınırları çok iyi tanımlanmalıdır. Dinamiklik içerisinde bile sınırlar bulunur.
Bu dinamik sistemleri yönetmesi, başkalarına anlatarak eğitmesi, sistemi ayakta tutması(maintain) etmesi diğer projelere göre oldukça zor olacaktır. mimar rolündeki kişi bunları bilip aşağıdaki konulara çok fazla değer ve yatırım yapması gerektiğini biliyor olmalı
- Monitoring (Sistemi Takip Etme)
- Debugging (Kuvvetli Debug Mekanizmaları Kurma)
- Maintainance (Bakım ve Veri Model versiyonları arasında Geçişi Kontrol)
- Education (Bu sistem üzerinde geliştirme yapacak kişileri eğitim)
5.Mimariyi Tüm Proje Ekibine Yaymazsanız Limitlerini ve Kullanımını Anlatmazsanız Sonuçları Nasıl Olur?
Son olarak mimar rolündeki kişi veya kişiler ortaya çıkardıkları mimariyi sürekli proje ekibine anlatmalı, onların sorularını, geribildirimlerini dikkate alarak bunları cevaplamalıdır. Tüm paydaşlar bu sistem üzerinde nasıl yazılım geliştirileceğini biliyor, sınırlarını ve gücünü anlıyor olmalıki bu mimariyi doğru şekilde kullansınlar.
Aynı zamanda bu sistem üzerinde geliştirmeler yapılırken bu geliştirmeler üst seviye doğru mu, iletişim yapıları ve yöntemleri mimariye uygun mu şeklinde sürekli bir kontrol mekanizması kurup, bu yapının dışına çıkan işleri engellemeli veya mimariyi bu yeni istekler doğrultusunda güncelleyerek, tüm sistemin mimariye uygun işlediğinden emin olmalıdır.
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
