• 28-05-2018, 21:44:21
    #37
    Birşeyler geliştirmeye ilk başladığım zamanlar hazır kütüphaneleri olabildiğince kullanmazdım, onları kendi kodum olarak görmez, içeriğini bilmediğimden yeterince hakim olunamayacağını düşünürdüm. Geliştirdiğim her uygulama ile beraber kullandığım kodları parçalarını kendimce bi mimari kurup her kısmı ayrı ayrı geliştirmeye çalışırdım. Fakat şunu fark ettim, bilgi birikimim pek gelişmiş olmadığından yazdığım "kütüphane"yi ikinci kez kullanamazdım çünkü her seferinde sistemdeki açıkları keşfedip daha iyisini geliştirmeye çalışırdım. Bu süreçten sonuç olarak ne kazandım? Kurulacak bir mimari tasarımında nelere dikkat etmem gerektiği, ilişkiler kurmadaki tecrübe, yeni teklonojiler öğrenip onlar hakkında araştırma yapma, birşeylerin nasıl "YAPILMAMASI" gerektiği vesaire... Eksileri neydi ? Yetersiz bilgi ile geliştirilmiş kütüphanelerdeki optimizasyon sorunları, hatalar, güvenlik açıkları ve aynı kodu tekrar kullanamadığım için büyük zaman kayıpları.

    İnsanların temelleri öğrenip, onlar üzerinde geliştirme yapabilmesi, yapılar kurabilmesi ve dolayısıyla var olan yapılara geliştirme ve ekleme yapabilmesi gerçekten önemli. Hatta önemliden de öte bir şart. Konuda birçok kişi framework kullanmanın daha az performanslı olduğunu bahsetmiş, evet haklılar fakat kaçırdıklar nokta frameworklerin büyük çoğunluğu daha iyi performans için zaten geliştirilmiyor. Siz bir güvenlik önlemi almak istiyorsanız bu bir maliyet, siz MVC patterinini uygulamak istiyorsanız bu bir maliyet, sorguları tekrar tekrar yazmayıp veritabanı bağlantılarını tekrar tekrar oluşturmayıp bir dataaccess layer oluşturmak istiyorsanız buda bir maliyet. Frameworkler bu ve benzeri binlerce işlemin daha kolay ve daha hızlı geliştirilebilmesi için oluşturulan kütüphaneler bunun yanı sıra MVC gibi bir düzen oluşturmak için gerekli standartları belirlerler, bir ekibiniz olduğunda veya firmanıza bir eleman aldığınızda iş sürecine daha hızlı dahil olabilmesi için oluşturulan kalıplar. Frameworkler sizin işinizi kolaylaştırmak için varlar.

    aliarbak adlı üyeden alıntı: mesajı görüntüle
    Riskli bir konu olmuş.
    Eğer architecture dizaynı yapabilecek, katmanları soyutlayabilip tüm sürecin yağ gibi akmasını sağlayabilecek bilgi birikiminiz ve şirket içi standartlar oluşturmaya, sahip olduğunuz standartları ekibinize yeni dahil olan kişilere öğretebilmek için vakte; bunlarla birlikte production ortamında hali hazırda kullanmakta olduğunuz mimari yapınızı güncelleyebilecek iş gücüne sahipseniz, elbette "hazır" frameworkleri kullanmayabilirsiniz. Tabi ki, sizin de standartlarını belirlediğiniz bir frameworkünüz nihayetinde olabilir.

    Kim bilir şuan neleri bilmiyoruz. İşin daha da kötüsü: kim bilir şuan neleri bilmediğimizi dahi bilmiyoruz
    @aliarbak; 'a kesinlikle katılıyorum. Tek başına geliştirebileceğiniz frameworku ne kadar sürede bitirebilirsiniz,? Ekip arkadaşlarınızı ne kadar sürede eğitebilirsiniz ? En önemlisi geliştirdiğiniz frameworkun eksiklerini fark ettiğinizde veya yeni birşeyler implemente etmeye çalıştığınızda, sisteminizin temel mimarisinin bu işlemler için yetersiz veya eksik olduğunu fark edip tekrardan yeni bir iskelet oluşturmanız gerektiğinde bu işlemleri kaç kere tekrarlayabilirsiniz? Bir framework geliştirmek kısa sürede yapılacak birşey değil, özellikle tek kişi iseniz.

    Yönelttiğiniz mantıkla, php verimsiz kalıyor herşeyi C ile yazalım, yok c bizi kısıtlıyor assembly, hayır hayır bu şekilde bilgisayarı yeterince anlamıyoruz biz direk 1'ler ve 0'larla çalışalım gibi bir sonuca çıkabilirsiniz. Evet yeterli zaman ve yeterli bilgi birikiminiz varsa bunların hepsini yapabilirsiniz. Unutmayın ki web projesi geliştiriyorsunuz dili geliştirdiniz fakat daha apache gibi bir http serverda yazmalısınız. Eğer en dibe inmeye çalışırsak, dallanan teklonojiler bizi tamamen boğacaktır. Buraya kadar yazdıklarımı kesinlikle yanlış anlamayın, bende sizin gibi her geliştiricinin kullandığı teklonojinin detaylarını yada en azından çalışma şeklini bilmesini isterim fakat birçok kez bahsettiğim gibi bu işlemler çok maliyetli(zaman ve dolayısıyla para açısından).

    Ne yapmalıyız? Geliştirilecek projeye göre kullanacağımız teklonojileri iyi seçmeliyiz. Bir teklonojiyi kullanırken sadece bu performanssız demek yerine teklonoji ile ilgili yapılacak optimizasyonlarda haberdar olmalı yada bu konulardan destek almalıyız. Eğer bir framework geliştireceksek, rakip frameworklerin bir çoğunu iyice bilmeli ve onların hatalarından ders çıkarmalıyız. PETABYTE'larca veri aktarımı olan bir sunucuda yükü azaltmak için veri işlemlerini bir apiye ayırıp daha iyi çalışması için redis(vb.) cache yapıları kullanmayı, sunum katmanındaki yükü azaltmak veya yok etmek için angular (vb.) yapılar kullanmayı düşünmeliyiz.

    Daha "performans"lı gelecek için aynı bizden öncekilerin yaptığı gibi yeni çağa uygun, isteklere cevap veren frameworkler, kütüphaneler, kısaca üzerinde tekrar geliştirme yapılabilir veya incelenelip üzerinden tecrübe kazanılabilir teklonojiler oluşturmalıyız. Bu sebele kesinlikle imkanınız varsa kendi frameworkleri geliştirmenizi, çağın şartlarına göre onu geliştirmenizi isterim, çalışmalarınızda başarılar dilerim!
  • 28-05-2018, 22:06:14
    #38
    MVC bilin uygulayın yapın, yanında class vs ihtiyaçlarımızda eklemeler yaparak çok temiz bir sistem olur.
  • 28-05-2018, 22:07:01
    #39
    bilgilendirme için teşekkürler hocam, dikkate alıcağım
  • 28-05-2018, 22:13:01
    #40
    hiç kullanmadım inş. boyun eğmem kullanmam kendi mvc hazır onun üzerinde gidiyorum
  • 28-05-2018, 22:33:46
    #41
    Bastan belirteyim cevaplari okumadan yaziyorum.

    Yazilan mantiga sakin itibar etmeyiniz.

    Okurken hayrete düstüm. Agzim acik kaldi.

    Uzun uzadiya yazmak yerine "hadi oradan canim" diyorum.

    Major release ler zaten degisiklik getirir bunu bilmiyor ve direk composer require ile versiyonsuz paket yüklüyorsan kesin hatali olan paket sahibidir.

    Elimde(calistigim sirkette, proje bende), suan büyük bir proje var (> 300k €) .
    Ajans degilim de fakat;
    - isi gücü birakip kendime Event-Dispatcher mi yazacagim?
    - yada Eloquentte ki Polymorphism olayini 0 dan $db->prepare(Yaz Allah Yaz)
    - ya routing? tabi vaktim cok. isi gücü birakir tekerlegi bastan icat ederim.

    Olay Laravel/Slim/Ci degil bunu Django(python), Rocker(rust), bla bla diye devam ettiririm.

    Senin mantigin ile bir cümle de ben kurayim.
    Apache seytan icadidir. Phpnin icine gömülü olan webserveri kullanin.
    Hatta isler büyür arama vs gerektirirse sakin elastic search kullanmayin pdo lu mysql'e ihanettir.
    Varnish vs zaten aktuel olmayan bilgiyi gösterdiginden yalancidir itibar etmeyiniz


    Desen ki ya arkadaslar olay Framework ögrenmek degil. Ortada bir sürü tasarim standardi var onlari ogrenin ve konuya hakim olduktan sonra sizi en verimli hale getirecek olan alt yapilari (düzeni bildikten sonra) kullanin ki bu kapitalist sistemde kalite /ücret ikilisini optimize etmis olun. He bu arada cokca adi anilmiyor PSR Standartlari da var da simdi girip iyice konuyu uzatmayayim.
  • 28-05-2018, 23:20:58
    #42
    alchalade adlı üyeden alıntı: mesajı görüntüle
    Apache seytan icadidir. Phpnin icine gömülü olan webserveri kullanin.
    Yorumumda bu satırada önem verecektim daha uzamasın diye yazmamıştım, aynışekilde katılıyorum hocam
  • 29-05-2018, 00:38:15
    #43
    alchalade adlı üyeden alıntı: mesajı görüntüle
    Bastan belirteyim cevaplari okumadan yaziyorum.

    Yazilan mantiga sakin itibar etmeyiniz.

    Okurken hayrete düstüm. Agzim acik kaldi.

    Uzun uzadiya yazmak yerine "hadi oradan canim" diyorum.

    Major release ler zaten degisiklik getirir bunu bilmiyor ve direk composer require ile versiyonsuz paket yüklüyorsan kesin hatali olan paket sahibidir.

    Elimde(calistigim sirkette, proje bende), suan büyük bir proje var (> 300k €) .
    Ajans degilim de fakat;
    - isi gücü birakip kendime Event-Dispatcher mi yazacagim?
    - yada Eloquentte ki Polymorphism olayini 0 dan $db->prepare(Yaz Allah Yaz)
    - ya routing? tabi vaktim cok. isi gücü birakir tekerlegi bastan icat ederim.

    Olay Laravel/Slim/Ci degil bunu Django(python), Rocker(rust), bla bla diye devam ettiririm.

    Senin mantigin ile bir cümle de ben kurayim.
    Apache seytan icadidir. Phpnin icine gömülü olan webserveri kullanin.
    Hatta isler büyür arama vs gerektirirse sakin elastic search kullanmayin pdo lu mysql'e ihanettir.
    Varnish vs zaten aktuel olmayan bilgiyi gösterdiginden yalancidir itibar etmeyiniz


    Desen ki ya arkadaslar olay Framework ögrenmek degil. Ortada bir sürü tasarim standardi var onlari ogrenin ve konuya hakim olduktan sonra sizi en verimli hale getirecek olan alt yapilari (düzeni bildikten sonra) kullanin ki bu kapitalist sistemde kalite /ücret ikilisini optimize etmis olun. He bu arada cokca adi anilmiyor PSR Standartlari da var da simdi girip iyice konuyu uzatmayayim.
    Anlamaz dostum, uğraşma tipik ergen işte. Birisinden kazığı yemiş, gelmiş burda iç acısını yaşıyor, bırak acısını yaşasın.
  • 29-05-2018, 00:45:05
    #44
  • 29-05-2018, 01:14:37
    #45
    Yıl 2018. Hala görüyorum ki tek ürün e-ticaret sitesini SALT PHP'yle kodlayıp, her şeyi yazabileceğini sananlar. Laravel'den bahsedilmiş. Laravel ve diğer PHP Frameworkler bir ihtiyaç sonucu ortaya çıkmış ve ihtiyaca göre kullanılması önerilmiştir. Laravel ve diğer Frameworkler, birden fazla yazılımcının aynı düzenle PHP proje üretebilmesini amaçlamaktadır. Size MVC, Template yapısını kullanmadan bir proje yazıyorsanız o da sizin ayıbınızdır artık. Eğer oturup baştan MVC, Template yapısını da yazıyorsanız, elinizden öperim.

    Ancak şu bir gerçek, büyük projeler büyük kütüphaneler ister. Test ortamı ister. Composer ister. Versiyon kontrolü ister. Fakat küçük projeler de tabii ki kullanmayın. Boşa altyapı gücü. Framework'ün nerede kullanacağımızı bilelim yeterli. Sevgili dostlarım. Öğrenin. Salt PHP'de öğrenin, Laraveli'de. Master olun. Tek bir yöntemde sıkışmayın. Gerektiğinde kullanın. Gerekmediğinde kullanmayın.