Yazılım Geliştirmede Soyutlama Seviyeleri ve Bunların Geliştiricilere Etkileri
Yazılımda farklı soyutlama seviyeleri bulunur Fonksiyon, Module, Kütüphane, Framework, Outsourcing/Freelance , NoCode gibi bunların geliştiriciler açısından etkilerine değerlendireceğim.
Her geçen gün yazılım geliştirme değişiyor ve gelişiyor. Tekrar tekrar aynı kodları yazıyoruz, bunun önüne geçmek için her gün yeni kütüphaneler, framework’ ler web dünyasında hiç durmadan sürekli duyuruluyor. Ben açıkçası bunların isimlerini ve versiyon yeniliklerini takip etmekten bile yoruldum. Hatta bunların birçoğu biz adını duymadan npm ve github hesaplarında yok olup gidiyor.
Bu durum kafa karışıklığı ve bilgi kirliliğinede neden oluyor. Evet yazılım geliştirirken yeni çıkan kütüphanelere bakacağız fakat bunlar bizim yönümüzü ve zamanımızı gereksiz yere almamaları gerekiyor.
Öncelikle soyutlama seviyelerinden bahsetmek istiyorum. Buna benzer bir konuya On Premise, IaaS, PaaS, ve SaaS konusunda da değinmiştim. Bulut teknolojilerinde hep aşağıdaki örneği verirdik.
Yani sorumlulukların ve bilginin On-Premise seviyesinde ne kadar fazla olduğu, SaaS ve Serverless doğru ne kadar azaldığından bahsettik. Fakat iş modelinizi doğru kurmadığınızda,
- SaaS ve Serverless ne kadar komplike ve maliyetli bağımlılıklar oluşturduğunu
- Enterprise ortamlara bunları taşımanın kolay olmadığını
- Soyutlanan kısımlarda çıkan hataları çözmek için ekstra danışmanlık ve araçlara ihtiyaç duyduğumuzu farkettik.
Tabiki bu soyutlama kötü değil ama bedava veya ucuz da değil. Her şeyin win-win olduğu çözümler bulmak zor.
Aynı durum şu anda yazılım geliştirme’ de karşımıza çıkıyor. Farklı seviyelerde soyutlama ile tekrar kullanabilirlik sağlayabiliriz.
- Function
- Module
- Library
- Framework
- Outsourcing/Freelancing
- NoCode
Soldan sağa doğru kazandığımız şeyler (Zaman, Quality, …) , kaybettiğimiz şeyler ise (Bağımlılık, Esneklik, …)
Eğer projenizde bunları doğru seviyelerde, doğru şekillerde seçmiyorsanız, bu seçimler size çok büyük maliyetlere, projenizin başarısız olmasına neden olacaktır.
Onun için projenizde doğru soyutlama seviyesini seçmek çok önemlidir. Bu seçimlerin maliyetlerini 2 uç örnekle açıklayayım.
1nci örnek : Yapacağınız örnek çok temel gereksinimlere sahip, CRUD işlem tabanlı form , table, chart gösterimi olan ekranlara sahip uygulamalar. Burada eğer projeyi en baştan kendim yazacağım diye hiç bir framework, kütüphane seçmeden ilerlerseniz tüm sorunları ve aşamaları kendi başınıza öğrenmeniz gerekeceği için çok fazla maliyet ve zaman kaybına neden olacak.
2nci örnek: Bir NoCode veya ileri Seviye Framework işinizi geliştirdiniz fakat işinizde kendiniz bir kısım yerleri değiştirmek istiyorsunuz işte burada o araç ve framework ile sınırlısınız demektir. Bundan sonra bu sınırlar içerisinde kalmak zorundasınız , o kodun derinlerine inip bir şeyleri değiştirmeniz veya NoCode platformundan bu değişiklikleri isteyip yaptırmanız oldukça zor.
Burada projenizin gereksinimlerini ve teknik isterlerini bilip doğru soyutlama katmanını seçmeyi anlatmaya çalıştım.
Benim burada durduğum yer genelde Library(Kütüphane) kullanımı üzerine Knowledge’lar biriktirmek. Ve bunları farklı projelere uygulamak, bunun ilgili projeye uygulanması tabiki bir maliyet çünkü
- Setup Platform uymayabiliyor: Vite, Next, Remix, Expo
- Dil uymayabiliyor: JS, TypeScript
- UI Kütüphanesi uymayabiliyor: Antd, Meterial UI, DraftUI, NextUI, …
- Network: Fetch, Axios, Graph
- vb… şeklinde ilerliyor.
Bir çok açıdan Knowledge ve Konseptleri ilgili projelere uygulamak bir maliyet gerektiriyor. Yeni projenin yapısını öğrenmek, konseptleri buralara aktarmak ve bunların kalıcı olmasını sağlamak gibi.
Fakat bu maliyetler yukarıda anlattığım 1nci örnek ve 2nci örnektekinden hem daha az riskli hemde uzun vadede daha avantajlı.
- Enterprise React Uygulamlar için Altyapı -1
- Enterprise React Uygulamlar için Altyapı -2
- Enterprise React Uygulamlar için Altyapı -3
- Enterprise React Uygulamlar için Altyapı-4
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
