Yazılımımız hangi teknolojiyle yazılmalı? Dil, framework ve veritabanı seçimi

Yeni bir projede teknoloji kararı çoğu zaman "hangi dil daha hızlı" tartışmasına dönüşür, oysa sonucu belirleyen sorular daha sıkıcıdır: bu sürüm ne zamana kadar güvenlik yaması alacak, bu teknolojiyi bilen birini bulmak ne kadar zor, karar yanlış çıkarsa geri dönmek ne kadar pahalı. Üçü de takvime ve bütçeye çevrilebilir. Dillerin arasındaki ham hız farkı ise sıradan bir iş uygulamasında veritabanı tasarımının yanında küçük kalır. Yani cevaplamanız gereken soru "en iyi teknoloji hangisi" değil, "bu sistemi önümüzdeki beş yıl kim, hangi maliyetle ayakta tutacak".

Her karar aynı ağırlıkta değil

Teknoloji seçimi tek bir karar değil, üst üste duran birkaç karardır ve geri dönüş maliyetleri birbirinden çok farklıdır. En altta veri modeli ve veritabanı durur; yıllar sonra taşınması en pahalı katman burasıdır, çünkü veriyi taşımak kodu taşımaktan zordur. Ortada uygulama framework'ü vardır: değiştirmek büyük iştir, ama sınırlı ve planlanabilir bir iştir. En üstte kütüphaneler durur, çoğu bir hafta içinde sökülüp yenisiyle değiştirilebilir.

Ekiplerin bir kütüphane tartışmasına iki hafta ayırıp veritabanı kararını toplantının son on dakikasında verdiğini sık görüyoruz. Tartışmaya ayırdığınız süreyi kararın geri dönüş maliyetine göre bölüştürün.

Destek takvimi bir mimari kısıttır

Seçtiğiniz sürümün ne zamana kadar güvenlik güncellemesi alacağı teknik bir ayrıntı değil, projenin takvimine giren bir kısıttır. Eylül 2026 itibarıyla tablo şöyle görünüyor. Node.js'in 20 sürümü güvenlik desteğini Nisan 2026'da yitirdi, 24 sürümünün aktif desteği Ekim 2026'da bitiyor, 22 sürümü Nisan 2027'ye kadar yalnızca güvenlik yaması alıyor. .NET tarafında her kasım bir sürüm çıkıyor ve LTS sürümler üç yıl destekleniyor; .NET 8 ile .NET 9 için son tarih 10 Kasım 2026, .NET 10 ise Kasım 2028'e kadar destekli. PHP 2024'te politikasını uzattı: iki yıl hata düzeltmesi, ardından iki yıl güvenlik yaması. Bu yüzden 8.3'ün aktif desteği Aralık 2025'te bitti, güvenlik yamaları Aralık 2027'ye kadar sürecek. PostgreSQL her ana sürümü çıkışından beş yıl sonra kapatıyor; 14 sürümü Kasım 2026'da listeden düşüyor.

Framework tarafında pencereler daha da dar. Django'nun LTS sürümleri üç yıl güvenlik yaması alıyor, 5.2 için bu Nisan 2028 demek. Laravel her yıl bir ana sürüm çıkarıyor ve sürüm başına 18 ay hata düzeltmesi, 2 yıl güvenlik desteği veriyor. Angular'da tempo daha sert: yaklaşık altı ayda bir ana sürüm ve sürüm başına toplam 18 ay destek (6 ay aktif, 12 ay uzun dönem). Spring Boot'un açık kaynak destek penceresi bir yılın biraz üzerinde, daha uzunu ticari abonelikle geliyor. Üç yıllık bir ürün planınız varsa bu iki uç aynı bakım yükünü üretmez ve bu farkı bütçeye baştan yazmak gerekir.

Yükseltme, projenin sabit giderlerinden biridir

"Şimdilik yükseltmeyiz" bir seçenek değil, faizi işleyen bir erteleme. Destek biten sürümde kalmanın pratikte neye mal olduğunu destek ömrü biten yazılım yazısında ayrıntılandırmıştık. Uygulaması ise basit üç alışkanlığa iner: yılda bir yükseltme penceresini takvime koyun, bağımlılıkları büyük sıçramalar yerine küçük ve sık adımlarla güncelleyin, yükseltmeyi gerçekten ucuzlatan tek şeye yatırım yapın. O tek şey test otomasyonu. Testi olmayan bir kod tabanında ana sürüm yükseltmesi, kapsamı önceden kestirilemeyen bir işe dönüşür.

Bir de sözleşme tarafı var. Yükseltmelerin kimin işi olduğu, bakım kapsamına girip girmediği ve nasıl faturalandığı yazılı olsun; bunu sonradan konuşmak her iki taraf için de zor olur. Modellerin farkını sabit fiyat mı, zaman-malzeme mi yazısında karşılaştırmıştık.

Bu teknolojiyi bilen kaç kişi var

Stack Overflow'un 2025 geliştirici anketinde en çok kullanılan diller JavaScript (%66), HTML/CSS (%61,9), SQL (%58,6) ve Python (%57,9) olarak sıralandı. Veritabanı tarafında PostgreSQL %55,6 ile açık ara önde, MySQL %40,5 ile onu izliyor. Bu bir kalite sıralaması değil, işe alım ve devir açısından "yerini doldurabileceğiniz" teknolojilerin listesi.

Niş bir dil seçmenin meşru sebepleri olabilir, gerçek zamanlı mesajlaşma gibi belirli bir yükte gerçekten fark yaratan seçimler var. Ama o durumda sorunun cevabını baştan verin: bu kodu yazan kişi ayrılırsa bakımı kim devralacak, devralacak firmayı bulmak ne kadar sürer? Kaynak kodun sizde olması bu sorunun yalnızca yarısını çözer, diğer yarısı devir disiplinidir ve onu kaynak kod mülkiyeti ve emanet yazısında ele almıştık.

İnovasyon jetonunu nereye harcıyorsunuz

Dan McKinley'nin 2015 tarihli "Choose Boring Technology" yazısındaki fikir basit ve hâlâ işliyor: her şirketin yaklaşık üç inovasyon jetonu vardır. Yeni ve heyecan verici her seçim bir jeton harcar, çünkü onunla birlikte kimsenin henüz bilmediği arıza biçimlerini de satın alırsınız.

Jetonu ürününüzü rakiplerinden ayıran yere harcayın. Sipariş yönetimi kuruyorsanız fark yaratacak yer büyük ihtimalle fiyatlandırma ya da planlama motorudur; oturum yönetimi, kuyruk ve veritabanı tarafında sıkıcı olan doğru olandır. Bilinen teknolojinin değeri özellik listesinde değil, arızalarının bilinmesinde: hangi sorgu neden yavaşlar, bağlantı havuzu dolunca ne olur, bunların cevabı zaten yazılmıştır. Nitekim tipik yavaşlama sebeplerini veritabanı darboğazları yazısında sayabilmemizin sebebi de bu.

Yerel entegrasyonlar listeyi daraltır

Türkiye'de çalışan bir iş uygulaması genelde aynı halkaya bağlanır: e-fatura ve e-arşiv entegratörü, ödeme sağlayıcısı ve 3D Secure akışı, banka sanal POS'u, kargo firmaları, SMS sağlayıcısı, e-imza ve mobil imza. Bu servislerin hazır istemci kütüphaneleri her dil için yayımlanmaz. Seçtiğiniz dil listede yoksa entegrasyonu sıfırdan yazarsınız, bakımı da sizde kalır. Bu, teklif aşamasında sorulacak somut bir sorudur: bu entegrasyonlar için sağlayıcının resmî kütüphanesi mi kullanılacak, yoksa kendi istemcinizi mi yazacaksınız? Ödeme tarafının asıl zor kısımlarını ödeme entegrasyonu yazısında anlatmıştık.

Güvenlik ölçütü: yama hızı ve varsayılanlar

Bir teknolojinin güvenlik profili iki yerde görünür. Birincisi süreç: yayımlanmış bir güvenlik bildirim kanalı var mı, bildirilen açıklar ne kadar sürede yamanıyor, eski sürümlere yama geliyor mu? İkincisi varsayılanlar: ORM parametreli sorgu üretiyor mu, şablon motoru çıktıyı kendiliğinden kaçırıyor mu, CSRF koruması yerleşik mi, oturum çerezi güvenli bayraklarla mı geliyor? Varsayılanı güvenli olan bir framework ekibinizin her gün vermesi gereken karar sayısını azaltır, bu da en ucuz güvenlik önlemidir.

Bağımlılık sayısı da bir ölçüt. Basit bir kurulumda yüzlerce paket çeken bir ekosistem saldırı yüzeyinizi aynı oranda büyütür; konunun tamamı yazılım tedarik zinciri güvenliği başlığı altında. Yamaların düzenli inmesi için gereken disiplini ise yama ve zafiyet yönetimi yazısında anlatmıştık.

Yönetilen servis iyi fikir, çıkış planı şart

Veritabanını, kuyruğu ya da kimlik doğrulamayı yönetilen bir servisten almak çoğu ekip için doğru karardır, işletme yükünün önemli bir kısmını devreder. Sorulacak soru servisi kullanıp kullanmamak değil, çıkışın nasıl olacağıdır: veriyi standart bir formatta dışarı alabiliyor musunuz, aynı arayüzü konuşan ikinci bir sağlayıcı var mı, uygulama sağlayıcıya özel bir API'ye mi yaslanıyor? Standart arayüzler (SQL, S3 uyumlu depolama, OCI konteyner imajları) geri dönüşü ucuz tutar. Konteyner tarafında dozu kaçırmamak için Kubernetes gerçekten gerekli mi, faturanın nasıl sessizce büyüdüğü için bulut maliyeti yazılarına bakabilirsiniz.

Teklif geldiğinde sorulacak yedi soru

1. Önerdiğiniz sürümün güvenlik desteği hangi tarihte bitiyor, bir sonraki LTS ne zaman çıkıyor?
2. Ana sürüm yükseltmeleri kimin işi ve sözleşmenin hangi maddesinde yazıyor?
3. Bu teknolojide çalışan bulmak zorlaşırsa bakımı kim devralabilir?
4. Kurulum kaç bağımlılık çekiyor, bunların kaçının son bir yıl içinde yeni sürümü çıkmış?
5. E-fatura, ödeme ve kargo entegrasyonları için resmî kütüphane mi kullanılacak, yoksa sıfırdan mı yazılacak?
6. Yönetilen servis kullanılacaksa veri hangi formatta ve ne kadar sürede dışarı alınabilir?
7. Bu kararın gerekçesini bir sayfalık yazılı bir not olarak alabilir miyiz?

Yedincisi bir nezaket sorusu değil. Gerekçesini yazamayan bir seçim, çoğu zaman teklifi veren ekibin elinde hazır bulunan şeydir. Bu kendi başına kötü bir sebep de değildir, sadece açıkça konuşulması gerekir.

Kararı bir sayfaya yazın

Mimari karar kaydı (ADR), Michael Nygard'ın Kasım 2011'deki yazısıyla yayıldı ve bugün Thoughtworks'ün Technology Radar'ında benimsenmesi önerilen uygulamalar arasında. Formatı kısadır: bağlam (hangi kısıtlar vardı), karar (ne seçildi), sonuçlar (bunun getirdikleri ve götürdükleri), değerlendirilen alternatifler ve neden elendikleri. Depoda docs/adr/0001-veritabani-secimi.md gibi numaralı dosyalar olarak durur, kod ile birlikte sürümlenir.

Faydası iki yıl sonra ortaya çıkar. Yeni katılan geliştirici "bu neden böyle" diye sorduğunda cevap dosyada durur; kısıtlar değiştiğinde kararın hangi varsayıma dayandığını görüp bilinçli biçimde değiştirebilirsiniz. Devralan ekip için yazabileceğiniz en ucuz dokümandır. Şartnamenin kendisi ayrı bir iştir, onun için yazılım şartnamesi nasıl yazılır yazısına bakın.

Bu haftaya sığan ilk adım

Mevcut sisteminizin dil, framework, veritabanı ve çalışma zamanı sürümlerini tek bir sayfaya çıkarın, her birinin güvenlik desteğinin biteceği tarihi yanına yazın (endoflife.date bu iş için yeterli). Önümüzdeki on iki ayda süresi dolacak kalemleri işaretleyin ve her birine bir yükseltme penceresi atayın. Yeni bir proje başlatıyorsanız ilk ADR'yi kod yazılmadan önce açın.

Elinizde farklı teknolojiler öneren iki teklif varsa ve hangisinin sizin ekibiniz için sürdürülebilir olduğuna karar veremiyorsanız, ikisini de aynı ölçütlerle değerlendirip bağımsız bir karşılaştırma çıkarabiliriz. Wedevit olarak belirli bir dil ya da satıcıyla ortaklığımız yok; değerlendirmeyi sizin ekibinizin bakım kapasitesine göre yapıyoruz.