Neden Symfony?

Öncelikle Symfony bir PHP framework ünden öte bir felsefedir. Gözümde Symfony PHP camiasının rock starıdır. Community si olsun Contributers ekibi olsun yönetici ekibi olsun kaliteli ve profesyonel bir kitle. Bunu sağlayan büyük oranda profesyonel bir şirket olan SensioLabsın projenin takibini yürütmesi, özellikle Fabien Potencier gibi bir core developer ının olması. Fabien Potencier ı araştıranlar anlayacaktır neden bu kadar övdüğümü şuan PHP üzerine yapılan bir çok projenin, framework ün kullandığı compenent ler teknolojiler @fabpot un elinden çıkmadır. Aynı zamanda proje yönetimi konusundada oldukça efsanedir. Örnek projeleri;

Amaç

SensioLabs ‘ın genel düşüncesi reusable components yazmaktır , ki bir component farklı projelerde rahatlıkla kullanılabilsin. Misal şuan Drupal, phpBB, Joomla! ve en çok Symfony alternatif olarak gösterilen Laravel birçok Symfony Components i kullanmaktadır, alakalı link ->. Yani şuana kadar aslında Symfony Components kullanmış olmanız muhtemel.

Core Developer Team

Ekibin büyük kısmı web development konusunda fazlaca tecrübeli ve birçoğu PHP nin önde gelen isimlerinden. Misal kesinlikle lame coders değiller, proje yönetimi nasıl olmalı, problem çözümü nasıl olmalı semver nasıl kullanılmalı vs. birçok konuda bilgi sahibiler. Birde Symfony Core Developer olmak gerçekten çok zor, alakalı link .Sırf bu sayfadaki rollerin, kimin ne yapabileceğinin düzenliliğinden dahi mükemmelliyetçiliği anlamak mümkün.

Contributing

Symfony ye contribute etmek çetrefilli bir iş gerçekten. Herşeyin bir standardı bir prosodürü var neredeyse. Buradan anlaşılacağı üzere development da katı kurallara sahiptir. Yani az biraz coding bilen kişi pr göndereyim benim de katkım olsun diyebileceği bir proje değil kesinlikle. Ben projenin kalitesini bu katı kurallarına bağlayanlarındanım. Fakat yanlış anlaşılmasın symfony nin ~1400 contributer ı var yani aslında biz developer ların elinden çıkma Open Source bir proje.

Semver denince benim aklıma direk Symfony projesi gelir. Sebebi ise mükemmel bir release roadmap i olması. Düşün ki şimdiden 2024 e kadar ki çıkacak releases planı hazır. Bu düzenlilik ne sağlıyor derseniz, birgün sabah kalktığınızda Symfony cahili olarak uyanmıyorsunuz. Misal Symfony3 release de silinecek code uses varsa bunu 2.7 gibi @deprecated işaretlemesini yaparlar ki sen yavaştan code revise ını yap Symfony3 e rahatlıkla geçebilesin. Özellikle büyük projeler için kararlı ve doğru semver kullanımı hayati öneme sahip. Symfony ile birgün composer update yaptığınızda patlama ihtimaliniz çok düşük. Aynı konunun Pythonve Angular.jsörneklerini araştırabilirsiniz.

Documantation

O kadar çok dilin framework ün doc. unu okumuşumdur kesinlikle Symfony bu konuda bir dünya markası. Eğer ki bir contributing yapılıyorsa kesinlikle onun doc. uda ekleniyor. Buradan browse edileceği üzere gayet anlaşılır şekilde rich content ile anlatımlı documentation bulunabilir. Ayrıca örnek kodlar, coding standards ve blog yazıları gibi bir çok içerik mevcut. Özellikle Best Practices adlı bir bölümü tadından yenmez :) Pdf leri indirerek yolda vs. okuyabilirsiniz. Bana bunlar yetmedi daha görsel birşeyler arıyorum dersen de KnpUniversity var. Birde verdiğim linklerdeki tüm content İngilizce, “Ama benim ingilizcem yok” a cevabım net “derhal terket burayı, ingilizce öğrenene kadarda gelme” :) şaka bir yana ama gerçekten ingilizce olmadan Symfony öğrenmek biryana kaliteli bir developer olmanız imkansız.

Community

Symfony community si fazlasıyla etkin, sorunlarınıza irc kanalından, mail gruplarına, slack grubundan, stackoverflow dan veya direk Github project issues kısmından bildirebilirsiniz, ama öncelikle bir google araması yapmayı unutmayın :). Çok zorda kalırsan da banagönderebilirsin (ama böyle çok aradın bulamadın :)
Alakalı Linkler;

Mimari Bakış

Symfony Framework aslında sadece Symfony Components i birleştiren bir glue den ibarettir (bkn: SymfonyFrameworkBundle). Directory yapısına bakarsanız zaten vendor u çıkardıktan sonra geriye sadece app ın ve web in altında birkaç dosyadan ibaret olduğunu göreceksiniz. Benim gözümde Symfony ‘yi mükemmel kılanda bu modüler bakış açısı. Bu neyi sağlıyor, misal developer arkadaşım ben reusable XBundle yazacağım dediğin zaman bunu fazlasıyla destekliyor. Bu mantıkla Symfony için yapılmış binlerce 3. party bundle mevcut. Misal FosUserBundle, AsseticBundle vs. vs.
Modüler yapı ile neredeyse her noktada process e müdahil olabiliyorsun. Bunu nasıl yapıyor derseniz Event Dispatch mantığı (Farklı bir yazı ile bu konuyu da anlatmaya çalışacağım). Gerek naming gerek directory mapping açısından da kaliteli bir iş.

Şimdilik bu kadar fırsat buldukça bu yazının devamını getirmeye çalışacağım.

“ Symfony is a set of PHP Components, a Web Application framework, a Philosophy, and a Community — all working together in harmony.”

Mutlu Günler :)

Comment and share

Symfony de Yaml mı Annotation mı?

Symfony camiasının genel tartışması annotation mı yoksa yaml configuration daha kullanışlıdır. Tüm açılardan bakarak karşılaştırmaya çalışacağım. Aynı zamanda XML de bu karşılaştırmaya katılabilir fakat birçok bundle XML configution desteklemediği için şimdilik ayrı tutuyorum.

Speed (Hız)

Herkezin ilk düşüncesi muhtemelen hız farkı olur mudur? Baştan söyleyeyim ikisi arasında eğer ki bir Symfony projesinden bahsediyorsak hiçbir hız farkı olmayacaktır (Symfony Core Configuration için bahsediyorum). Sebebi şu ki Symfony yi az biraz bilenler bilir bu mantık Doctrine dede aynı şekilde ilk request veya cache:warmup işleminde annotation, yaml veya xml farketmeksizin php ye convert edilir. Sonraki request ler için direk pure php den okunur bu yüzden Doctrine veya Symfony configuration farketmeksizin hız bakımından bir karşılaştırma yapılamaz.

Readability (Okunabilirlik)

Bu maddede bence yaml çok daha readability si yüksek çünkü gereksiz hiçbir karakter içermeden minor indentations ile hızlıca configuration yapabiliyorsunuz. Ayrıca Yaml ı birçok IDE fazlasıyla destekliyor auto indentation yapabiliyorsunuz ve bir standart a bağlı. Annotation da maalesef belirli bir standart olmadığı için okunabilirlik yerlerde, birçok IDE extra plugins ile destekliyor fakat stabil çalışan yok denebilir. Annotation için auto indentation yapan bir plugin yok bildiğim kadarı ile. Eğer ki bir de Doctrine conf. u Annotation ile yapayım derseniz readability ölü diyebiliriz. Bunu verdiğim linkten rahatlıkla anlayabilirsiniz.

Eğer ki birde büyük bir projeden bahsediyorsak muhtelemen onlarca extra bundle kullanılacaktır. Bunun sonucu olarak entitylerde 30 line lara kadar propery annotation görmeniz muhtemel hale geliyor.

İçerikten anlaşılacağı üzere bu maddede ben kesinlikle Yaml destekçisiyim.

Yazım kolaylığı

Eğer ki küçük bir projede çalışıyorsanız misal 2 kişinin çalıştığı max. 20 action olan bir minor bir sistem ise Annotation size fazlası ile hız kazandıracaktır extra dosya create etmeden misal routing için direk action larda annotation kullanarak rahat ve hızlı şekilde yazabilirsin. Aynı şekilde max. 3 entity ile işim var ve çok karmaşık relationsum yok dersen aynı şekilde annotation kullanabilirsin. Ama dersen ki projede 5> kişi var, aktif development süreci var, 300> action ımız 50> entity ve relations çorba dersen kesinlikle Yaml derim, eğer annotation kullanıp gününü conflict resolve ile harcamak istemiyorsan.

Büyük projelerde annotation kullanımında bir süre sonra özellikle entity lerde her bundle için bir conf. ekleyerek 50 line lık bir entity olacaktır 1000 line sonrasında bug çıktığında hangi line da problem var çözmesi zaman alacaktır.

Sonuç olarak bu maddede büyük proje ise kesinlikle Yaml, küçük projeler için Annotation kullanılabilir diyorum.

Grup Çalışması

Symfony nin en aşık olduğum felsefesi directory yapısının mükemmel şekilde dizayn edilmiş olmasıdır. Aynı zamanda naming konusunda gerçekten çok titiz olmaları. Aynı mantıkta bir projede directory yapısını ne kadar düzenli tutarsanız, development ında o derece düzenli ve mantıklı ilerlemesi muhtemel. Bunu fazlasıyla tecrübe etmiş birisi olarak, büyük projelerde proje directory root u ne kadar dağınık(tek merkezde toplanmamış) tutulursa development kolaylığı da o derece kolaylaşıyor.

Bahsettiğim dağınık yapı Yaml ile sağlanabilir. Misal doctrine configuration bir directory de, routing bir directory, validation bir directory, services bir directory de vb. birçok örnek verilebilir. Annotation için düşünürsek entity içerisinde doctrine, validation, bundle configuration da olsun bu da olsun derseniz bu daha merkeziyetçi bir yaklaşım oluyor.

Dağınık yapının ilk yararı git conflict resolve sürenizi minimize eder :). Bir projede 5> kişi çalışıyorsa birisi routing üzerinde çalışırken bir diğeri controllers üzerinde çalışabilir. Aynı şekilde birisi entity lerde düzenleme yaparken diğeri aynı entity nin validation kısmına bakabilir.

Dağınık yapıda file history den fazlasıyla bilgi alınabilir. Benim fazlasıyla kullandığım bir tool dur github da olan aynı zamanda commandline dada bakabileceğiniz, bir dosyanın change history si. Eğer ki misal validation ile ilgili bir history ye bakmak istiyorsunuz Yaml da sadece related entity nin validation dosyasının history sine bakarak çok daha sağlam bilgi edinebilirken. Annotation da related entity nin git history sine bakacaksınız alakasız birçok commit i incelemeniz muhtemel.

Git için benim genel felsefem herzaman için minor parçalar halinde çok commit atmaktır. Sebebi farklı birisi yaptığın işlere baktığında hangi commit ile ne amaçladın en ince detayına kadar anlayabilsin. Bu felsefeyi en iyi destekleyen yapı tabikide dağınık directory yapısı, Yaml configuration.

Bu maddedede benim düşüncem eğer ki 5> kişilik bir proje ekibi varsa Yaml zorunluluk.

Son cümlem: “Sağlam bir projem var diyorsan Yaml, diğer türlü Annotation”

İyi Günler.

Comment and share

  • page 1 of 1
Author's picture

Behram ÇELEN

PHP/Symfony Expert


Software Developer


Wroclaw/Poland