Neden Laravel kullanmıyorum

Yaptığım projelerde, süreçleri, işlemleri birbiri ile güzelce anlaşabilecek şekilde yapmaya gayret ederim. Birbirleri ile tam bir otomasyon ile anlaşamayan her bir süreç ileride sorun çıkarıp, projenin aksamasına sebep olabilir. Bununla birlikte her çıkan sorun bir geriye dönük ilgi gerektirerek ek maliyet çıkardığı istenmeyen bir durum oluşturur.

Bu yüzden projeleri kodlarken kullandığım araçları seçerken biraz “kıl” davranırım.

Kullanılan araç bana hız kazandırıyor mu ? Yeni bir versiyonu çıktığında geçmişe yönelik desteği nasıl ? Bir sorun çıktığında bu sorunu google araması ile çözüme ulaşabiliyor muyum ? Kim tarafından geliştiriliyor ? canı istediği zaman commit yapan birisi tarafından mı geliştiriliyor.

Mevzu teknoloji ve yazılım ise, “daha iyisi” olmayacağını bilecek kadardır bu işi yapıyorum, Hani framework daha iyi ? sorusunun cevabı bence yoktur, Hangi bilgisayar daha iyi sorusunun cevabı bence spesifik değildir, En iyi programlama dili hangisi sorusuna cevap aramak vakit kaybıdır benim için.

“İhtiyacımı görecek en iyisi hangisi ?” sorusunu sormak bizi daha çabuk çözüme ulaştırır diye düşünüyorum,

En iyi programlama dili hangisi yerine “linux ortamında konsol işlemleri yapacağım hangi dil kendini bu konuda geliştirmiş ?”

Web tarafında api isteklerine cevap verecek bir proje yapacağım, hangi dil bu konuda gelişmiş ? diye sormak bence en iyisi.

Firma olarak Windows Ce kullanan el terminali yazılımından , Facebook uygulamasına kadar bir çok sektöre çözüm üretiyoruz. Kullanacağımız araçları, “bu platform için en verimli araçlar hangileri ?” sorusunu sorarak seçiyoruz.

En iyi dil PHP’dir diye diretseydik, windows ce kullanan bir el terminaline kod yazamayacaktık. Yada en iyi dil .net’dir deseydik, Linux sunucusunda Bash script ile çözebileceğimiz bir başka sorun için .net ile çözüm aramaya çalışacaktık.( çözüm bulamayacaktık.)

Yazılım geliştirme içerisinde Fanatikçe karar almanın faydadan çok zarar getireceğini düşünüyorum.

Çok yakın bir tarihe kadar PHP ‘nin en büyük sorunlarından birisi gelişmiş ve genele yayılmış bir paket yöneticisinin olmaması idi,



her ne kadar resmi olarak çıkmasa da çok yakın bir geçmişte composer oluşturularak, php’nin bu eksiği çok büyük ölçüde giderildi.

Bu işte sözü geçen büyük firmalar bile kendini composer içerisine eklediği için topluluğun composer konusunda ciddi olduğunu da görmüş olduk.

Composer sayesinde artık proje içerisinde kullanacağımız repolara çok daha kolay şekilde ulaşıyoruz. Tek bir dosya üzerinden repoları yönetip projemize dahil edebiliyoruz.

Composer ile popüler olan bir çok repo, bir kişinin geliştirmekte olduğu “şeylerden” uzaklaşıp farklı sorunlar ile karşılaşan insanların pull requestleri ile birlikte gelişip büyüyor. Bu sayede kendi içinde bir hata takip ve dokümantasyon sistemi oturmuş oluyor.

Yani kullandığınız araçların sorunlarına ve çözümlerine direk o araçların github sayfalarından ulaşabiliyoruz.

bununla birlikte, composer bize php’nin oop gücünü daha iyi kullanmamızı sağlıyor, kullandığı autoload mimarisi sayesinde gerçek bir mvc deneyimi yaşayabiliyoruz.

Bu işe başladığımda ve devamında etrafımda hep kaliteli yazılımcılar olduğundan ötürü,

“OOP dediğin şey çok kullanılan fonksiyonların, sınıf dosyaları içine konulup lazım olunca çağrılması değil mi canım”

fikrinden kurtulmak çok uzun sürmedi benim için.

Bu yüzden Kendi Frameworkümü kendim yazdım dediğim dönemler sadece 1-2 proje ile sınırlı kaldı :)

Konunun en başına dönecek olursak,

Yaptığınız proje çevre şartları değişmediği sürece sorunsuz şekilde çalışmalıdır, “Kitap gibi çalışıyor” deyiminin hakkını vermelidir.

Daha önceki bir yazımda, Müşteriye göre şekillenmek konusuna değinmiştim.

İsteklere göre şekillenmek için çok esnek bir yapıya sahip olmanız gerekiyor. Projenizin, sonradan gelen isteklere göre şekillendirirken kırılmaması çok önemli bir faktör olarak ilk sıraya çıkıyor.

Kullandığınız her bir aracı bir lego parçası gibi düşünebilirsiniz,

ne kadar ufak parçalar ile çalışırsanız, o kadar esnek projeler üretebilirsiniz ve projenin alacağı şekil, sizin hayal gücünüze kalacağı için ortaya muazzam işler çıkabilir.

İşte bu yüzden composer çıktığından bu yana, tek bir framework’e bağlı kalmak yerine, frameworklerin güzel tarafları ile daha esnek araçlar üretebileceğini düşünüyorum.

Gelelim bu durumda Laravel’i neden kullanmadığıma,

1- Sadece ben, hep ben, ben olmuşum laravel !

Laravel Tek ADAM projesi, bunu ben değil Laravel’i yazan arkadaş diyor,

https://twitter.com/taylorotwell/status/420577120188768257

Laravel asla bir community projesi olarak başlamadı.

Tek bir geliştiricinin “Php ile Ruby gibi yazsak nasıl olur ?” fikri üzerine, yine benim az önce bahsettiğim şekilde ufak araçların composer ile bir araya getirmesinden ibaret.

CodeIgniter’ın geliştirilmesinin durdurulmasının ardından, ortaya çıkan, “basit, günü kurtaran bir framework” ihtiyacını karşılayabilecek yetkinlikte bir framework laravel.

Yani beni, geçmişe yönelik destek ilgilendirmiyor, günü kurtarmak için yazılım yapıyorum laravel ile yapıp geçeceğim diyorsanız Laravel tam size göre.

2- Biz bir aileyiz ama kararları ben veririm!

Opensource topluluğuna göz kırpan bir projeyi temelden ilgilendiren kararları tek adam tarafından alınması sonucu ortaya çıkan sonuçları geçmişte gördük,

Mesela Pardus’un sonunun başlangıcı, topluluk redmine istediği halde jira’da direten proje başları sayesinde olmuştu,

Yine Ubuntu’da , pencere butonlarının topluluğun istememesine rağmen sağda değilde solda diretilmesi örnek olarak verilebilir, Söz ubuntu’dan açılmışken, ubuntu firmasının unity’den tutunda arama bilgilerinizin başkaları ile paylaşılmasına kadar olan bir yelpaze bile ortaya çıkan şey Open Source olsa bile kararı biz vereceğiz! diretmesinden başka bir şey değil.

Ubuntuyu birinci işletim sistemi olarak kullanmayı bırakmama sebepte bu tutumlarıdır. Benim gibi bir çok kişi var.

hal böyle olunca,

projeye gelen pull request’leri bile merge etmek yerine kendisi copy paste ile sisteme ekleyen bir adam’a ne kadar güvenebilirim ?

https://github.com/laravel/framework/graphs/contributors bu linkten de görebileceğiniz gibi laravel’in büyük bir kısmı @taylorotwell tarafından yazılmış gözüküyor.

adam fırsat bulduğu her platformda “Ehe naber ? laraveli ben yaptım, benim bu proje” demekten kendini alamıyor.

3- Versiyonlama sorunları.

Can alıcı kısım bu aslında. Laravel Semantic Versiyonlama ile yazılmıyor, örnek verecek olursak,

bir yazılımın 1.2.4 versiyonu ile 1.2.5 versiyonu arasında çok büyük değişiklikler olmaz, yani siz bu aracı kullanırken 1.2.4 versiyonunu 1.2.5 versiyonuna yükselttiğinizde projenizin çalışmasına devam etmesini beklersiniz.

Laravel’de durum böyle değil, 1.2.4 versiyonunda desteklediği bir kütüphaneyi yada metodu, 1.2.5 versiyonunda komple kaldırmış ve yerine bambaşka bir metod eklemiş olabiliyor. Böyle olunca bu gün yazdığınız kod, laravel güncellendikten sonra tamamen çalışmaz hale gelebiliyor.

Mesela, Python 2 varken ve halen geliştirme süreci devam ediyorken, Python 3 çıkmasının ve onunda geliştirilmesinin sebebi budur,

yada Opencart 1.5.5.6 sürümü varken Opencart 2.0.0.0 ‘ın çıkmasındaki sebep budur,

köklü değişiklikler olduğunda sizin ürününüzü kullananların “mağdur” olmaması için bu tarz versiyonlama sistemi kullanılır. Bu her şeyden önce “saygı” sorunudur.

Temel amacımız sorunsuz çalışan bir sistem ise, bu şekilde “ya ruby’de şu özellik var, laravelde neden yok demesin millet, bende bunu ekleyeyim o zaman” diyerek kafasına göre versiyonlama yapan bir adamın ortaya çıkardığı üründen ne kadar fayda bekleyebiliriz ?

4- Kullanıcıların sorun çıktığında çözüme ulaşmasının önünü tıkamak.

Geçtiğimiz günlerde Laravel, github üzerindeki issüeleri sildi ve artık sorunları forumlardan sorulmasını istedi.

Hem kafana göre versiyonlama ile işler yapacaksın, hem sorun çıktığında “buralar çok karışık oluyor” gerekçesi ile çözüm yollarını tıkayacaksın.

Benim hızlıca çözüme ulaşma kriterim de burada çuvallıyor, üstelik “Laravel Auth Problem”, “Laravel Orm Problem” gibi çok genel aramalarda çıkan sonuçların içinde bir de hangi versiyon olduğunu aramak zorundayım.

5- Standart üretme çabası ile saçmalama.

Php ‘de interface olarak kullanılan şeyleri alıp, bunların adına Contracts diyor.

Php’nin adı çıkmış bir kere, Çok dağınık, düzensiz kod yazılmasına izin veriyor, hali hazırdaki interafece özelliğinin adını değiştirip yeni ve ayrı bir sistem gibi sunalım gibi bir düşünce hakim.

Bu hem kısa hem de uzun vadede çok daha büyük sorunlara gebe kalacak bir düşünce, topluluk desteğini hiçe sayıp her şey “benden” geçecek dedikten sonra, kullandığınız her aracın contratsını yazacaksınız demek tutarsızlık.

Laravel ile kodlama yaparken yine kör dövüşü yapıp, ben contracts yazmam diyorsanız Laravel kullanmanın anlamı ne o zaman ?

Hali hazırda Composer paketleri içerisinde görüp beğenip kullanmak istediğiniz bir aracın kendi interface’i, bundle’ı yada provider’i varken neden laravel’de contracts yazayım ? (yoksa)

Ben composer ile çekip $repo = new repoClass(); diye her yerden ulaşabileceğim bir aracı, neden sadece laravel içerisinde çalışacak bir hale sokmak isteyeyim ?

“Kırk Küp Kırkınında Kulpu Kırık Küp” gibi bir metni, “kirk-kup-kirkininda-kulpu-kirik-kup” şeklinde url formatına çevirecek bir araç kullanmak için, composer.json’a tek bir satır ekleyerek istediğim yerden çağırıp kullanmak yerine neden sadece laravel’de çalışan bir şeye dönüştüreyim ?

Hızlı sonuç alma fikri nerede kaldı ?

Yine aynı şekilde, $nesne = new Nesne(); demek varken, neden make gibi bir metod ile ide dostu olmayan bir yöntem kullanayım ?

6- Kalıplara sokarken özgünlüğünü yitirme.

Projeyi parçalara ayırarak oluşturmayı legolara benzetmiştim,

Laravel’de aslında parçalara ayrılmış repolardan oluşuyor ancak yukarıda saydığım şeylerden ötürü her bir parça kendi özgürlüğünü bırakıp laravel’in diretmelerine maruz kalıyor.

Siz güncel paketleri bir araya getirdiğinizde ortaya çıkan şey şu olurken :



Aynı işi laravel yaptığında ise ortaya şöyle bir şey çıkıyor :



Laravel’de size lego sunuyor ama sunduğu parçalar Laravel’in baştan düşündüğü şeylerin dışına çıkamıyor. Böyle olunca da Laravel Programcısı oluyorsunuz, Php ile alakanız kalmıyor, Laravel’in ürettiği çözümlerin dışına dahi çıkamıyorsunuz.

Senelerdir Visual Studio illetine mahkum kalan .net tayfası için aynı şeyleri söylemedik mi ? (kendim de visual studio kullanıyorum, windows ce ‘ye sadece VS2008 ile yazılım üretebiliyorsunuz :’( )

7- Destek, Destek, Destek.

Zend Framework 1 , ilk olarak 2007 yılında yazıldı, zamanla üzerine yeni versiyonlar eklendi, semantik bir versiyonlama kullandığı için ilk versiyonda yazılan (2007 yılında) bir yazılım bugün bile sorunsuz çalışabiliyor,

üstelik Zend Framework 2 adında yep yeni bir sürüm çıkmasına rağmen hala Zend Framework 1 için güncellemeler yapılıyor.

Bir diğer Framework olan Symfony, bir kaç gün önce LTS sürümünü duyurdu.

Ama laravel’in kendi sitesinde bile 4. sürümünden öncesi için dokümantasyon bile yok.

8 - Taklitler aslını yaşatır.

Ruby ‘den esinlenerek tek bir adamın inisiyatifinde olan Ruby çakması bir yapı kullanacağınıza, aynı basitlikte ve gerçekten topluluk tarafından geliştirilen Ruby’e geçmeniz daha faydalı olacaktır, üstelik MVC nedir sorusuna verecek az çok cevabınız varsa Ruby’nin öğrenme süresi size çok ama çok basit gelecektir.

Sonuç olarak ;

Yazdığım kodun ileride de sorunsuz çalışmasını istediğim için,

Günü kurtarmak için kod yazmadığım için,

Kullandığım araçları “Herkes bunu kullanıyor, demek ki en iyisi bu” gibi bir argüman ile seçmediğim için,

Benim yazacağım kodun standardını bir topluluk değil de keyfe keder kararlar alan birisinin belirmesinden rahatsız olduğum için,

İstediğim zaman istediğim yeni araçları ekleyebilmek istediğim için Laravel Kullanmıyorum.

Peki ya çözüm önerisi:

Elbette var,

ilk tavsiyem, kendini ispat etmiş, bu işe yatırım yapmış frameworkleri kullanın (Yii, Zend, Symfony gibi) , framework seçerken “en hızlısı buymuş” diye seçmeyin, Hız değişkeni en son dikkat etmeniz gereken faktör.

Diğer tavsiyem, yine kendini ispat etmiş toplulukların desteklediği paketleri ihtiyacınıza göre birleştirin. Girin Github’a bakın, Php’nin yüksek versiyonları ile geliştirilen projelerde neler kullanılmış inceleyin.

Mesela firma olarak kullandığımız yöntemden örnek vereyim,

Zend FW 1’in route yapısını sevmiyorum, bunun yanında view olarak Zend Framework 1’in harika olduğunu düşünüyorum,

Database katmanında ORM kullanma taraftarıyım, çünkü projesini yürüttüğüm firma 2 gün sonra bir şirket kararı olarak bundan sonra “Mysql yerine Mssql” kullanmak istiyoruz dediğinde oturup tüm sorguları elden geçirmek istemiyorum,

hatta yıl olmuş 2015 neden hala sql kodu ile uğraşayım ki ? Bu yüzden Doctrine kullanmak istiyorum,

Symfony’nin Route yapısı harika, kendim route katmanı oluşturana kadar bu iş için yine symfony tayfasının yaptığı Silex adında micro framework var onu kullanırım. Üstelik Silex için hemen hemen tüm çevre birimler için (redis, elastic search, doctrine vs vs) provider mevcut.

Bu anlattığım yapı için başka bir blog yazısı yazacağım.

İyi kodlamalar.

Ekleme 1 : (02.04.2015)

Bu yazıya bir ekleme yapmak istemiyordum, İçerisinde küfür geçmeyen tüm yorumları yayınlama gibi bir kuralım vardır. Ama artık, yazıyı okumadan sadece yazının başını ve sonunu okuyarak yorum yapan üstelik bu yorumlarında da yazı içerisinde söylediğim şeyleri bana sanki söylememişim gibi sav olarak sunan yorumları artık onaylamayacağım. Okuma yazma bilmeyen insanların yorumları, bu yazıya ve konuya bir şey kazandırmayacaktır.

Teşekkürler.