Framework Nedir? Kütüphane ve Uygulama Çatısından Farkı

Framework, hazır koddan daha fazlasını nasıl sağlar?

Framework; bir uygulama geliştirirken kullanılabilecek kurallar, klasörleme yaklaşımı, yapılandırma seçenekleri, API'ler ve hazır bileşenlerden oluşan bir yazılım çatısıdır. Buradaki 'çatı' benzetmesi önemlidir: Framework, uygulamanın bütün ayrıntılarını sizin yerinize yazmaz; fakat uygulamanın üzerine kurulacağı yapıyı ve bazı ortak işleyişleri önceden tanımlar.

Örneğin bir web framework'ü, gelen HTTP isteğinin hangi kod tarafından karşılanacağını, isteğin hangi adrese yönlendirileceğini ve cevabın nasıl üretileceğini düzenleyebilir. Geliştirici ise bu yapının içinde ürünün kendine özgü iş mantığını yazar. Benzer biçimde masaüstü uygulamalarında pencere ve olay yönetimi, mobil geliştirmede platformlar arası yapı veya sunucu tarafında istek-cevap döngüsü framework tarafından desteklenebilir.

Framework kullanmak, geliştiricinin hiçbir karar vermediği anlamına gelmez. Veritabanı modeli, kullanıcı deneyimi, yetkilendirme kuralları ve uygulamanın alan bilgisi yine projeye göre tasarlanır. Framework yalnızca bu kararların kod içinde düzenli biçimde uygulanacağı zemini hazırlar. Bu yüzden bir framework'ün sağladığı özellikleri değerlendirirken 'kaç hazır fonksiyon var?' sorusu kadar 'uygulamanın akışını ve mimarisini nasıl etkiliyor?' sorusu da sorulmalıdır.

Kontrolün tersine çevrilmesi: Kodunuzu kim çağırır?

Framework'leri kütüphanelerden ayıran en öğretici kavramlardan biri kontrolün tersine çevrilmesidir (Inversion of Control, IoC). Geleneksel bir programda geliştirici, programın akışını kendisi kurar ve gerektiğinde kütüphanedeki bir fonksiyonu çağırır. Örneğin bir hesaplama kütüphanesindeki fonksiyonun ne zaman çalışacağına geliştirici karar verir.

Framework tabanlı bir uygulamada ise framework, kendi yaşam döngüsünü yürütür. Bir web isteği geldiğinde yönlendirme mekanizmasını çalıştırır, uygun işleyiciyi bulur ve geliştiricinin yazdığı kodu belirli bir aşamada çağırır. Bu durumda geliştirici, framework'ün belirlediği giriş noktalarına ve kurallara uymalıdır. Kısa karar kuralı şöyledir: Kütüphaneyi genellikle siz çağırırsınız; framework ise uygun zamanda sizin kodunuzu çağırır.

Bu özellik, framework'ün güçlü yanı olduğu kadar sınırlamasıdır. Uygulama standart bir akışa uyuyorsa geliştirme hızlanır ve ekip üyeleri benzer bir yapı üzerinde çalışır. Ancak alışılmadık bir akış gerekiyorsa framework'ün yaşam döngüsüyle çatışma yaşanabilir. IoC, 'framework her şeyi otomatik yapar' demek değildir; kontrolün bir bölümünün uygulama kodundan çatının çalışma modeline taşınması demektir.

Framework ile kütüphaneyi ayıran pratik test

Kütüphane, belirli bir ihtiyacı çözmek için çağrılabilen yeniden kullanılabilir kodlar topluluğudur. Bir tarih, görüntü, ağ veya veri işleme kütüphanesini uygulamanızın uygun gördüğü anında çağırabilirsiniz. Kütüphane, çoğunlukla mevcut program akışınıza eklenir.

Framework ise daha geniş kapsamlıdır. Genellikle uygulamanın başlangıcını, yapılandırmasını, modüller arasındaki ilişkiyi ve yaşam döngüsünü etkiler. Bu nedenle framework kullanırken yalnızca bir fonksiyon öğrenilmez; dosya düzeni, yönlendirme, bileşenlerin sorumlulukları ve yapılandırma biçimi de öğrenilir.

Sınır her projede tamamen keskin değildir. Bazı araçlar farklı kaynaklarda framework, kütüphane veya framework ekosisteminin bir parçası olarak adlandırılabilir. React bunun bilinen bir örneğidir; çoğu kullanımda kullanıcı arayüzü kütüphanesi olarak anılsa da geniş bir araç ekosistemiyle birlikte kullanılabilir. Bu nedenle adlandırmadan çok şu soruya bakmak daha doğrudur: Araç, uygulamanın genel kontrol akışını ve mimarisini zorunlu biçimde yönlendiriyor mu, yoksa uygulama onu ihtiyaç duyduğu yerde mi çağırıyor?

Bu ayrımı sınav veya mülakat sorusunda kullanmak için 'kütüphane işlev sağlar, framework çalışma iskeleti ve kontrol akışı sağlar' cümlesi yeterli bir başlangıçtır; ancak IoC kavramını da gerekçeye eklemek cevabı güçlendirir.

Backend, frontend ve mobil çatılar aynı işi mi yapar?

Framework'ün görevleri kullanım alanına göre değişir. Backend framework'leri sunucu tarafındaki istekleri, yönlendirmeyi, uygulama mantığını ve bazı ortak servisleri düzenlemek için kullanılır. Kaynakta verilen Django ve Flask Python ekosisteminde; Laravel PHP tarafında; Ruby on Rails Ruby tarafında; Express.js ise Node.js ekosisteminde anılan backend örnekleridir. Bu araçların her biri aynı özelliklere veya aynı mimari kurallara sahip değildir; yalnızca benzer bir geliştirme alanında kullanılırlar.

Frontend tarafında framework veya framework olarak anılan araçlar, kullanıcının tarayıcıda gördüğü ve etkileştiği arayüzün oluşturulmasına yardımcı olur. React, Angular ve Vue.js bu alanda verilen örneklerdir. Arayüzün görsel yapısında HTML, görünüm kurallarında CSS, etkileşim ve davranışta ise JavaScript önemli rol oynar. Bu araçlar HTML ve CSS'nin yerine geçen sihirli katmanlar olarak değil, arayüzü bileşenlere ve etkileşimli yapılara ayırmaya yardımcı olan araçlar olarak düşünülmelidir.

Mobil tarafta Flutter, React Native ve Xamarin mobil geliştirme framework'leri veya framework tabanlı çözümlerdir. Dart, Flutter'da; JavaScript ise React Native'de kullanılan programlama dilleridir. Xamarin, desteği 1 Mayıs 2024'te sona ermiş eski bir çözümdür. Güncel .NET tabanlı çapraz platform mobil geliştirme için .NET MAUI örnek olarak verilebilir. Bu tür çözümlerin amacı, tek bir kod tabanıyla iOS ve Android gibi birden fazla platforma yönelik geliştirme yapabilme olanağı sunmaktır. Bu, her durumda aynı performansın veya aynı kullanıcı deneyiminin garanti edildiği anlamına gelmez; platforma özgü gereksinimler ayrıca incelenmelidir.

Masaüstünde .NET Framework, Windows'a özgü eski nesil ve büyük ölçüde legacy bir framework olarak özellikle Windows uygulamalarıyla ilişkilendirilebilir. Güncel çapraz platform geliştirmede ise modern .NET kullanılır; Electron da çapraz platform uygulama geliştirme seçeneği olarak verilebilir. Dolayısıyla framework seçerken önce 'frontend mi, backend mi, mobil mi, masaüstü mü?' sorusu cevaplanmalı; ardından dil, platform ve projenin gereksinimleri karşılaştırılmalıdır.

Framework seçerken hız vaadine değil, projenin sınırlarına bakın

Framework'lerin başlıca faydası, tekrarlanan altyapı işlerini azaltarak geliştiricinin uygulamanın özgün işlevlerine odaklanmasına yardımcı olmalarıdır. Bunun yanında ortak bir mimari ve kodlama yaklaşımı sunmaları, ekip içinde tutarlılığı artırabilir. Önceden geliştirilmiş bileşenlerin kullanılması da aynı işlevin her projede yeniden yazılmasından doğabilecek bazı hataları azaltabilir.

Güvenlik konusunda dikkatli bir ifade kullanılmalıdır. Popüler bir framework'ün güvenlik güncellemeleri ve topluluk desteği olabilir; fakat framework kullanmak uygulamayı kendiliğinden güvenli yapmaz. Güncel olmayan bağımlılıklar, yanlış yapılandırma, hatalı yetkilendirme ve geliştiricinin yazdığı güvensiz kod yine risk oluşturabilir. Güvenlik avantajı ancak güncelleme, doğru yapılandırma ve güvenli geliştirme uygulamalarıyla birlikte anlamlıdır.

Seçim yaparken şu sırayı izlemek pratiktir:

1. Uygulamanın alanını belirleyin: web, mobil veya masaüstü.
2. Kullanılacak programlama dili ve mevcut ekip bilgisini değerlendirin.
3. Framework'ün uygulamanın ihtiyaç duyduğu yönlendirme, bileşen, veri erişimi veya platform desteğini sağlayıp sağlamadığını inceleyin.
4. Öğrenme maliyetini ve projenin gerektirdiği mimari kısıtları karşılaştırın.
5. Güncelleme, dokümantasyon ve topluluk desteğini kontrol edin.

Küçük ve kısa ömürlü bir betik için kapsamlı bir framework eklemek gereksiz yapılandırma yükü oluşturabilir. Buna karşılık birden fazla geliştiricinin çalıştığı, büyümesi beklenen ve ortak bir uygulama akışına ihtiyaç duyan projelerde framework daha anlamlı olabilir. Bu, 'büyük projede mutlaka framework gerekir' şeklinde mutlak bir kural değil; bakım, ekip uyumu ve tekrar eden işlerin miktarıyla ilgili bir değerlendirmedir.

Çözümlü örnek: Basit bir web uygulaması için çatıyı konumlandırma

Verilenler: Bir ekip, kullanıcıların tarayıcıdan istek gönderdiği bir web uygulaması geliştirecek. Ekip Python kullanmak istiyor ve backend tarafında Django ile Flask seçeneklerini değerlendiriyor.

Çözüm adımları:

1. Uygulama alanını ayırın. Kullanıcının tarayıcıda gördüğü arayüz frontend; sunucunun istekleri karşılayıp uygulama mantığını yürüttüğü bölüm backend'dir. Bu örnekte seçilecek araç backend framework'ü olacaktır.
2. Dil koşulunu uygulayın. Ekip Python kullanmak istediği için PHP, Ruby veya JavaScript ekosistemindeki örnekler ilk değerlendirme grubunda değildir. Bu, onların teknik olarak hiçbir koşulda kullanılamayacağı değil, verilen koşulla doğrudan eşleşmedikleri anlamına gelir.
3. Framework'ün rolünü belirleyin. Django veya Flask, uygulamanın istek-cevap akışını ve backend kodunun düzenlenmesini destekler; uygulamanın kendine özgü iş kurallarını ekip yine yazmalıdır.
4. Gereksinimlerle karşılaştırın. Projenin ihtiyaç duyduğu hazır özellikler, ekipteki Python bilgisi, öğrenme süresi ve tercih edilen mimari incelenmelidir. Kaynakta Django ve Flask'ın Python için backend örnekleri olduğu belirtilir; ancak hangi seçeneğin bu özel proje için daha iyi olduğu, ayrıntılı gereksinim verilmeden kesinleştirilemez.

Sonuç: Bu koşullarda Django veya Flask, Python tabanlı backend framework'ü adayıdır. Karar yalnızca 'hangisi daha popüler?' sorusuyla değil, projenin ihtiyaçları ve ekibin çalışma biçimiyle verilmelidir. Tarayıcıdaki görsel arayüz için ayrıca HTML, CSS ve JavaScript ya da bunlarla birlikte kullanılan frontend araçları değerlendirilir.

Çözümlü örnek: Framework mü, yalnızca kütüphane mi?

Verilenler: Geliştirici, uygulamasında tarih hesaplaması yapan bir kod parçasına ihtiyaç duyuyor. Ayrıca uygulamanın genel akışını yönetecek bir yapı seçmesi gerekiyor.

Çözüm adımları:

1. İhtiyacı ikiye ayırın. Tarih hesaplamak tek bir teknik görevi çözmeye yöneliktir; bu tür bir ihtiyaç için kütüphane kullanılabilir.
2. Çağırma yönünü sorun. Geliştirici tarih işlevini programın uygun gördüğü yerde çağırıyorsa kontrol geliştiricidedir. Bu, kütüphane kullanımına işaret eder.
3. Genel akışı inceleyin. Uygulamanın başlatılması, isteklerin karşılanması, ilgili kodun çağrılması ve yaşam döngüsünün yönetilmesi için önceden tanımlanmış bir yapı kullanılıyorsa bu bölüm framework'ün rolüne girer.
4. İki aracı birlikte düşünün. Bir proje aynı anda framework ve kütüphane kullanabilir. Framework uygulamanın iskeletini ve kontrol akışını yönetirken, kütüphane belirli bir görevi yerine getirmek için bu iskeletin içinden çağrılabilir.

Sonuç: Tek bir işlev için kullanılan kod topluluğu kütüphane; uygulamanın genel akışını ve mimarisini yönlendiren yapı framework'tür. Bu iki seçenek birbirinin alternatifi olmak zorunda değildir.

Sık yapılan hatalar ve sınır durumları

Framework ile ilgili en yaygın yanlışlar şunlardır:

• 'Framework kullanınca kod yazmaya gerek kalmaz.' Framework yalnızca ortak altyapı ve kurallar sunar. İş mantığı, veri modeli, arayüz kararları ve proje gereksinimleri için geliştirici kod yazmaya devam eder.
• 'Her framework kütüphanedir.' Kütüphane ile framework arasındaki ayırıcı nokta kapsamdan çok kontrol akışıdır. Kütüphane çoğunlukla uygulama tarafından çağrılır; framework uygulamanın belirli aşamalarında geliştirici kodunu çağırır.
• 'Framework uygulamayı otomatik olarak güvenli yapar.' Güncel olmayan sürüm, hatalı yapılandırma veya yanlış yazılmış kod güvenlik sorunu oluşturabilir. Framework desteği bir güvenlik garantisi değil, doğru kullanıldığında yardımcı bir altyapıdır.
• 'Bir dilin yalnızca tek framework'ü vardır.' Kaynakta Python için hem Django hem Flask örneklenir. Aynı dil veya platform içinde farklı amaçlara ve çalışma yaklaşımlarına sahip birden fazla seçenek bulunabilir.
• 'Frontend araçları HTML, CSS ve JavaScript'i ortadan kaldırır.' Web arayüzü araçları bu teknolojilerle birlikte çalışabilir; arayüzün yapı, görünüm ve davranış katmanlarını anlamak framework öğrenimini kolaylaştırır.
• 'En popüler araç her proje için doğrudur.' Framework seçimi proje türü, dil, platform, ölçek, performans gereksinimi, ekip deneyimi ve topluluk desteğiyle birlikte değerlendirilmelidir.
• 'Framework kullanmak zorunludur.' Çok küçük veya özel gereksinimli bir projede ek yapılandırma maliyeti faydadan ağır basabilir. Bu karar, projenin kapsamına ve bakım ihtiyacına göre verilmelidir.

Ayrıca framework ile çalışma ortamı da karıştırılmamalıdır. IDE, kod yazmayı, hata ayıklamayı ve proje dosyalarını yönetmeyi kolaylaştıran geliştirme ortamıdır; framework ise uygulamanın geliştirme ve çalışma yapısını sağlayan yazılım çatısıdır.