Framework mü Saf PHP mi? Bağımlılık Kararı

Framework tartışması genellikle taraf tutmayla yürür, oysa karar ölçülebilir bir takasa dayanır. Framework başlangıç hızını artırır ve ortak sorunlara test edilmiş çözümler sunar. Karşılığında proje, o framework'ün sürüm takvimine ve tasarım kararlarına bağlanır.

Doğru soru hangisinin daha iyi olduğu değil, projenin ömrü boyunca hangi maliyetin daha katlanılabilir olduğudur.

Framework ne sağlar?

Bir web uygulamasında tekrar eden işlerin listesi bellidir: yönlendirme, istek ve yanıt yönetimi, oturum, doğrulama, veritabanı erişimi, şablon üretimi, günlük kaydı, göç yönetimi ve test altyapısı. Framework bunların tamamını hazır ve birbiriyle uyumlu biçimde verir.

Daha az görünen ama daha değerli katkısı güvenlik tarafındadır. Siteler arası istek sahteciliği koruması, çıktı kaçışı, parola özetleme ve oturum sağlamlaştırma gibi konular varsayılan olarak doğru yapılandırılmış gelir. Bunların her birini elle yazmak yalnızca zaman değil, hata riski de demektir.

Ekip açısından ise ortak bir dizin düzeni ve isimlendirme geleneği kurar. Yeni katılan geliştirici projeye değil, bildiği yapıya bakar.

Bağımlılığın maliyeti

• Ana sürüm yükseltmeleri planlı iş gerektirir; ertelendiğinde güvenlik yamalarından da mahrum kalınır.
• Framework'e özgü çözümler, koda o çerçevenin varsayımlarını yerleştirir.
• Katman sayısı arttıkça hata ayıklama, kendi kodunun dışına taşar.
• Küçük bir iş için gelen çerçeve, gereksiz büyüklükte bir bağımlılık ağacı getirebilir.

Bu maliyetlerin çoğu ilk aylarda görünmez. Proje üç yaşına geldiğinde ve iki ana sürüm geride kaldığında ortaya çıkar. Karar verirken bakılması gereken zaman ölçeği de budur.

Saf PHP'nin gerçek yükü

Framework kullanmamak bağımlılığı sıfırlamaz, yalnızca sorumluluğu değiştirir. Yönlendirme, oturum güvenliği, doğrulama ve göç yönetimi yine gerekir; farkı, bu parçaların bakımının proje ekibine ait olmasıdır.

Küçük projelerde bu yük hafiftir ve denetim kazancı ağır basar. Proje büyüdükçe yazılan yardımcı katman kendi framework'üne dönüşmeye başlar; ancak belgesi, testi ve topluluğu olmayan bir framework'e.

Ara yol: bileşen bazlı kullanım

Tam yığın framework ile sıfırdan yazmak arasında üçüncü bir yol vardır: yalnızca ihtiyaç duyulan bileşenleri almak. Yönlendirme, HTTP soyutlaması, günlük kaydı ve şablon motoru ayrı paketler olarak kurulabilir.

composer require nikic/fast-route
composer require monolog/monolog
composer require symfony/http-foundation

PSR standartları bu yaklaşımı mümkün kılar. Ortak arayüzler sayesinde bir günlük kütüphanesi diğeriyle değiştirilebilir ve uygulama kodu bundan etkilenmez. Bağımlılık arayüze verildiğinde, gerçekleştirimin değişmesi maliyet üretmez.

Karar ölçütleri

• Proje ömrü uzun ve ekip birden fazla kişiyse framework lehine ağırlık artar.
• İş mantığı basit, sayfa sayısı azsa saf PHP yeterlidir.
• Yoğun güvenlik gereksinimi varsa hazır ve test edilmiş çözümler tercih edilir.
• Bakımı devralacak taraf belirsizse yaygın bir çerçeve seçmek riski azaltır.
• Performansta son damlaya ihtiyaç duyulan özel işlerde bileşen bazlı yaklaşım daha esnektir.

Yeniden yazma tuzağı

Var olan bir uygulamayı başka bir yapıya taşıma kararı, çoğu zaman teknik gerekçeyle başlar ve tahmin edilenin iki katı sürer. Eski kodun içindeki yıllarca birikmiş özel durumlar yeniden yazımda kolayca gözden kaçar.

Daha güvenli yol, taşımayı parça parça yapmaktır. Yeni bölümler seçilen yapıda yazılır, eski bölümler çalışmaya devam eder ve zamanla devredilir. Bu yaklaşım hem riski dağıtır hem de kararın yanlış olduğu anlaşılırsa geri dönüşü mümkün kılar.

Kontrol listesi

• Karar, projenin ömrü ve ekip yapısına göre verilir.
• Framework kullanılıyorsa sürüm yükseltmesi takvime alınır.
• Saf PHP tercih edildiğinde güvenlik konuları listeye yazılır ve tek tek karşılanır.
• Bağımlılıklar arayüz üzerinden kullanılır.
• Yeniden yazma kararı, ölçülen bir sorun olmadan verilmez.

İlgili yazılar

• Monolit mi Mikroservis mi? Karar Kriterleri
• OOP: Sınıf, Arayüz ve Soyutlama