Neden Laravel Yerine Saf PHP? (Bağımlılığı Azaltmak)

Her Şeyin Hazır Olduğu Bir Dünyada, Kendi Yolunu Çizmek

Manavgat’ın o kavurucu yaz sıcaklarında, klima sesinin bilgisayar fanına karıştığı ofisimde otururken bazen aklıma 2005 yılı geliyor. O zamanlar internet bu kadar "paketlenmiş" değildi. Bir şey yapmak istiyorsak, oturur yazardık. index.php dosyasını oluşturup <?php etiketini açtığımda hissettiğim o sonsuz özgürlük hissi, bugün hala beni bu mesleğe bağlayan en temel duygu.

Bugünlerde sektörde sıkça duyduğum, hatta bazen stajyer arkadaşlardan veya yeni müşterilerden gelen bir soru var: "Neden Laravel kullanmıyoruz? Herkes onu kullanıyor."

Haklılar. Laravel muazzam bir araç. Ekosistemi harika, topluluğu devasa. Ama bir mühendis olarak, Pixel Lab® mutfağında her zaman sorguladığım bir şey var: İhtiyacımız olan gerçekten bu mu, yoksa sadece kolaya mı kaçıyoruz?

Doğada kamp yaparken yanıma aldığım çantamı düşünün. Eğer sadece günübirlik bir yürüyüş yapacaksam, yanıma 80 litrelik devasa bir kamp çantası, üç günlük erzak, çadır ve uyku tulumu almam. Bu beni yavaşlatır, yorar ve doğanın tadını çıkarmamı engeller. Yanıma sadece su, çakı ve belki bir elma alırım. Yazılımda da durum benim için tam olarak bu. Laravel veya Symfony gibi devasa framework’ler, o 80 litrelik çanta gibi. İçinde her şey var ama çoğuna ihtiyacınız yok.

Framework Bağımlılığı: Konforlu Bir Hapishane

Framework’ler, yazılımcıları şımartan, onlara hız kazandıran ama aynı zamanda onları "nasıl çalıştığını bilmediği" bir yapıya hapseden araçlardır. Bugün birçok genç geliştirici, Laravel'in Auth::user() fonksiyonunu kullanıyor ama arka planda session'ın nasıl yönetildiğini, cookie'nin nasıl set edildiğini veya veritabanı sorgusunun ham halini bilmiyor. Bu, benim "sihirbazlık sendromu" dediğim bir durum.

Kodun "sihirli" bir şekilde çalışması hoşunuza gidebilir, ta ki o sihir bozulana kadar. Bir hata aldığınızda, sorunun kaynağı sizin yazdığınız üç satırlık kodda mı, yoksa vendor klasörünün derinliklerinde, adını bile duymadığınız bir kütüphanenin uyumsuzluğunda mı? Bunu çözmek bazen sıfırdan yazmaktan daha uzun sürüyor.

Bağımlılık (dependency) dediğimiz şey, aslında projenizin geleceğini başkalarının ellerine bırakmaktır. Bir paket güncellenmediğinde veya güvenlik açığı çıktığında, tüm projeniz risk altına girer. Ben, Manavgat ormanlarında bisiklet sürerken nasıl gidonun hakimiyetinin tamamen bende olmasını istiyorsam, yazdığım projede de hakimiyetin bende olmasını isterim.

Mühendislik Bakış Açısı: Neden "Saf" (Native) PHP?

Burada bahsettiğim şey "spagetti kod" yazmak değil. Lütfen yanlış anlaşılmasın. 2005'te değiliz, modern PHP (özellikle 8.0 ve sonrası) artık çok güçlü, tip güvenli ve nesne yönelimli bir dil. Framework kullanmamak, kuralsız kod yazmak demek değildir. Aksine, kendi kurallarınızı, projenin ihtiyaçlarına en uygun mimariyi inşa etmek demektir.

1. Performans ve Hız

Pixel Lab®'da geliştirdiğimiz bazı özel CRM sistemlerinde, framework kullanmadan yazdığımız yapıların, framework kullanan muadillerine göre katbekat hızlı çalıştığını defalarca test ettik. Neden mi?

Basit bir "Merhaba Dünya" sayfası için bile bir framework yüzlerce dosyayı include eder, onlarca servisi başlatır, event listener'ları dinlemeye başlar. Oysa saf PHP ile yazdığınızda, sadece ihtiyaç duyduğunuz dosyalar çalışır. İşlemciyi ve belleği yormazsınız. Bu, trafiği yüksek projelerde sunucu maliyetlerini doğrudan etkileyen bir faktördür.

2. Yönetilebilir Karmaşıklık

Bir framework projesini açtığınızda, proje dosyalarının %90'ı sizin yazdığınız kodlar değildir. Sizin kodunuz, devasa bir yapının içindeki küçük adacıklardır. Saf PHP ile (tabii ki modern bir yapı, örneğin MVC mimarisi ve Composer ile) geliştirdiğinizde, projedeki her satırın neden orada olduğunu bilirsiniz.

Benim için iyi bir yazılım mimarisi, doğadaki ekosistem gibidir. Her parçanın bir görevi vardır ve gereksiz hiçbir şey barındırmaz. Bir kartalın kanatları ne kadar büyükse o kadar gereklidir, fazlası değil. Yazılımda da router'ınız sadece URL'i parçalasın, veritabanı sınıfınız sadece sorguyu çalıştırsın. Binlerce özellik barındıran bir "ORM" yerine, kendi yazdığınız veya çok hafif bir veritabanı sarmalayıcısı (wrapper) kullanmak, size SQL üzerinde tam kontrol sağlar.

3. Güncelleme Korkusu Olmadan Yaşamak

composer update komutunu yazarken eli titreyen geliştiriciler tanıyorum. "Acaba hangi paket patlayacak?", "Acaba hangi fonksiyon deprecate oldu?" korkusu. Kendi yazdığınız, bağımlılığı minimize edilmiş bir sistemde bu korkuyu yaşamazsınız. PHP sürümü güncellendiğinde, sadece kendi kodunuzu gözden geçirmeniz yeterlidir. Üçüncü parti bir kütüphanenin yazarının güncelleme yapmasını beklemek zorunda kalmazsınız.

Kendi Tekerleğini İcat Etmek: Ne Zaman Mantıklı?

Yazılım dünyasında "Tekerleği yeniden icat etme" diye bir klişe vardır. Bu söz, genellikle framework savunucularının en büyük kalkanıdır. "Neden oturum yönetimi (session management) yazasın ki? Laravel'de hazırı var."

Ben buna katılmıyorum. Eğer bir yarış arabası yapıyorsanız, marketten aldığınız standart bir tekerleği kullanamazsınız. O arabanın aerodinamiğine, ağırlığına ve pistin durumuna göre özel bir tekerlek tasarlamanız gerekir.

Eğer basit bir blog sitesi yapıyorsanız, evet, WordPress veya Laravel kullanın. Ama binlerce kullanıcının aynı anda veri işlediği, milisaniyelerin önemli olduğu, iş mantığının çok spesifik olduğu bir kurumsal uygulama geliştiriyorsanız, o standart tekerlek sizi yolda bırakır. Kendi router'ınızı yazmak, kendi veritabanı sınıfınızı oluşturmak size şu avantajları sağlar:

• Tam Hakimiyet: Kodun her satırına hakimsiniz. Bir bug çıktığında nereye bakacağınızı bilirsiniz.
• Öğrenme Derinliği: Bir router'ın nasıl çalıştığını yazmadan öğrenemezsiniz. HTTP protokolünü, request/response döngüsünü gerçekten anlamak için bunları en az bir kez kendiniz yazmalısınız.
• Uzun Ömürlülük: Framework'ler gelir geçer. CodeIgniter modaydı, sonra Laravel geldi, yarın başkası gelecek. Ama PHP'nin çekirdek mantığı ve sizin yazdığınız temiz kod, dil desteği sürdüğü sürece yaşar.

Modern PHP ile "Frameworksüz" Yapı Nasıl Kurulur?

Framework kullanmamak, her şeyi sıfırdan yazmak demek değildir. Composer hala bizim en iyi dostumuz. Ancak burada strateji, "her şeyi yapan dev kütüphaneler" yerine, "tek bir işi iyi yapan küçük kütüphaneler" kullanmak veya bunları kendimiz yazmaktır.

Örneğin, şablon motoru (template engine) olarak devasa Twig veya Blade sistemlerini projeye dahil etmek yerine, PHP'nin kendi sözdizimini kullanan basit bir görünüm (view) sınıfı yazabilirsiniz. Veya PSR standartlarına (PSR-4, PSR-7) sadık kalarak, kendi hafif yapınızı kurabilirsiniz.

// Basit, anlaşılır ve saf bir Router mantığı örneği
$path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);

$routes = [
    '/' => 'HomeController@index',
    '/hakkimda' => 'PageController@about',
    '/iletisim' => 'ContactController@index',
];

if (array_key_exists($path, $routes)) {
    // Controller ve Action'ı çağır
    // Burada sihir yok, sadece mantık var.
}

Bu yaklaşım, doğada çektiğim belgesel kurgularına benziyor. Ham görüntüyü alıyorum, gereksiz her şeyi kesip atıyorum. Sadece hikayeyi anlatan, izleyiciye duyguyu geçiren kareler kalıyor. Yazılımda da "code bloat" dediğimiz o şişkinlikten kurtulup, sadece işi yapan koda odaklanmak, mühendislik tatmini açısından paha biçilemez.

Güvenlik Miti: Frameworksüz Kod Güvensiz midir?

En büyük yanılgılardan biri de budur: "Framework kullanmazsan SQL Injection yersin." Hayır, eğer PDO kullanmayı bilmiyorsan, prepared statements mantığını kavramadıysan framework kullansan da hata yapabilirsin. Güvenlik, kullandığınız araçta değil, sizin bilginizdedir.

SQL Injection'a karşı savunma hattı bellidir. XSS saldırılarına karşı output escaping bellidir. CSRF token mantığı bellidir. Bunları framework sizin yerinize "otomatik" yaptığında, siz güvenlik uzmanı olmuyorsunuz, sadece korunan bir kullanıcı oluyorsunuz. Ama bu yapıları kendiniz kurduğunuzda, saldırı vektörlerini de öğrenmiş oluyorsunuz. Pixel Lab®'da güvenliği bir eklenti olarak değil, kodun DNA'sı olarak görüyoruz.

Sadeliğin Gücü

Aslan burcunun getirdiği o liderlik ve kontrol etme dürtüsü müdür bilinmez, ben projelerimde iplerin elimde olmasını seviyorum. Bir ormanda yürürken bastığım toprağı hissetmek gibi, yazdığım kodun da sunucuda nasıl çalıştığını hissetmek istiyorum.

Büyük kütüphaneler ve popüler framework'ler, modern yazılım dünyasının fast-food zincirleri gibidir. Hızlıdır, standarttır, karnınızı doyurur. Ama evde, kendi seçtiğiniz taze malzemelerle, özenerek hazırladığınız bir yemeğin tadını asla veremezler. Üstelik o yemeğin içinde tam olarak ne olduğunu sadece siz bilirsiniz.

Eğer gerçekten yazılım "mühendisi" olmak istiyorsanız, arada sırada o konforlu framework koltuğundan kalkıp, saf PHP'nin o vahşi ve özgür dünyasına adım atın. Belki biraz daha fazla kod yazarsınız, belki biraz daha fazla yorulursunuz ama günün sonunda ortaya çıkan eser tamamen size ait olur. Ve inanın bana, kendi inşa ettiğiniz bir yapının sorunsuz çalıştığını görmek, doğada ateş başında yıldızları izlemek kadar huzur vericidir.