PHP
Galat-ı Meşhur
Son güncelleme tarihi: 2023-01-31
PHP programlama dünyasında, bir dizi eğilim bazı insanlar tarafından (kendi kitaplarında ve web sitelerinde) “Modern PHP” olarak pazarlanırken, aynı zamanda diğer tüm yaklaşımlar sanki ilkel, aptalca veya yanlış olarak sunuluyor.
Bu insanlar yorulmadan başkalarının işlerini yaparken kendilerinin yollarını takip etmelerini sağlamaya çalışıyor gibi görünüyorlar.
Bu web sitesi PHP ile programlama yapanlara pragmatik bir bakış sunmak amacıyla oluşturulmuştur. Hedeflenen popüler eğilimler, teori veya akademik dogmalardan ziyade tecrübeden ve pratik sonuçlardan oluşturulmuş bir bakış açısı ortaya çıkarmaktır.
PHP - The Wrong Way yaşayan bir site olacak ve yenilikler ortaya çıktıkça site güncellenecektir.
Her türlü katkıya ve yardıma açığız.
Programlama kuralları ve kılavuzlarının önemli bir sorunu da, genellikle belirli bir bağlamda bir amaca hizmet etmeleridir. Bağlam dışına alındığında, iyi bir kural korkunç bir kural haline gelebilir. Aslında, her kural aşırıya götürüldüğünde kötü sonuçlar doğurur.
Bunun anlaşılması önemlidir, çünkü zamanla geliştirilen ve birçok farklı insan tarafından sunulan yazılım geliştirme ilkeleri ve kurallarının çoğu aşırılık yanlılarının elinde çoğunlukla yanlış kullanılır.
Deneyimler genel kuralların ve kılavuzların kötüye kullanılmasının her zaman karmaşıklıkla, güvenlik eksikliğiyle, hataya açık sonuçlarla ve hatta bazı durumlarda felaketle sonuçlandığını göstermiştir.
“Basit ve Aptal Tutun, (Keep It Simple, Stupid)” ın kısaltması olan KISS ilkesi, genellikle deneyimli kişiler tarafından çok yararlı olarak görülen, akıllıca ve iyi bir ilkedir. Takip edilmesi tavsiye edilir. Ancak bu büyük prensip bile, aşırıya götürülürse bir proje için tehlike oluşturur. Gerekli işlevsellikten uzak sadece “çok basit” görünen bir sonuç ortaya çıkabilir.
Yanlış yol: Kuralları ve kılavuzları din gibi algılama
Tüm genel amaçlı PHP uygulama çatıları mutlaka patlar!
PHP topluluğunda, gerçekten çok kötü bir eğilim web uygulamaları geliştirmek için fiili bir standart haline geldi. Bu eğilim mutlaka popüler bir genel amaçlı uygulama çatısının kullanılması gerektiğinin düşülmesidir.
Bu eğilim geliştirme sürecinin kalitesini artırdığı için değil, teknolojik ve mimari açıdan yapılacak doğru şey olduğu için ortaya çıkmış ve popüler hale gelmiştir. Bu eğilimin popüler bir hale gelmesinin bir sebebi de, uygulama çatısı geliştiricilerinden bazılarının kitleleri, “Çarkı yeniden icat etmeyin!” ve “Kendin yapmana gerek yok, başkaları senden daha yetenekli olabilir.” gibi sloganlarla manipüle etmeleridir.
Günümüz programcılarının çoğu, sağlıklı programlamanın temel ilkelerini tamamen görmezden geliyorlar. Akranları olarak gördükleri kişiler tarafından daha akıllı, daha havalı ve daha kabul edilebilir görünmek için ve yeni karmaşık katmanları hayal etmek için çok zaman harcıyorlar.
Bu tarzı benimseyen insanlar, diğer insanların hep “kendi yollarını” takip etmeleri, kendilerini bir tür PHP topluluğu lideri gibi görmelerini ve başkalarının kendi kullandıkları Açık Kaynak araçlarını kullanmalarını sağlamayı (ki bu araçların bazılarının ne olduğunu kendileri bile unutmuş olabiliyor) sağlamak için deli gibi çaba sarfediyor görünüyorlar.
Yazılım endüstrisinde genel amaçlı bir yazılım çatısını önceden inşa edilmiş bir evi ile eşleştirebilirsiniz. Önceden inşa edilmiş bir evi bir araya getirmek nasıl sizi iyi bir marangoz yapmazsa, genel amaçlı uygulama çatıları ile uygulama geliştirmek de sizi çok iyi bir kodlayıcı veya programcı yapmaz.
Bu sitede biz uygulama çatısı kullanmak ile kütüphane kullanmayı birbirinden aşağıdaki maddelerden dolayı ayrı tutuyoruz;
Python ve Ruby dünyasında, en baştan web siteleri inşa etmek zahmetlidir, çünkü ne Python ne de Ruby aslında web siteleri oluşturmak için yaratılmamıştır. Sonuç olarak, Django ve Ruby on Rails gibi genel amaçlı çerçeveler hızla bu dillerde web siteleri oluşturmak için popüler oldu.
Diğer taraftan PHP, başlangıçta Rasmus Lerdorf tarafından C dilinde yazılmış ve dinamik HTML’yi kolayca ve hızlı bir şekilde geliştirmenizi sağlayacak bir dizi araç olarak oluşturulmuştur. Bu tasarımından dolayı PHP hala ** kendi başına bir uygulama çatısıdır **.
PHP ilk zamandan beri kitlesel olarak gelişti ve bugün PHP, HTML ve web siteleri oluşturmaktan çok daha fazlası için kullanılabilir, ancak PHP’yi kendi içinde bir tür çatı olarak görmek hala yanlış değildir. PHP, doğası gereği, tamamen bir C prosedüründe yazılmış web uygulamalarını geliştirmek için bir soyutlama katmanıdır.
Projenizde herhangi bir kütüphane kullanmak son derece doğaldır. PHP, kendi kodunuzu genişletmek için kullanabileceğiniz bir dizi kütüphaneyle birlikte gelir. Örneğin PDO, PHP’deki veritabanlarına erişmek için tutarlı bir arayüz sağlayan sade bir kütüphanedir.
Diğer taraftan PHP’nin üstünde bir çatı kullanmak tamamen başka bir konudur.
PHP’de bir çatı kullandığınızda, bir soyutlama katmanının üstüne başka bir soyutlama katmanı daha eklemiş olursunuz. Çatının sağladığı ek soyutlama katmanı, kodunuzu önceden sabitlenmiş bir kalıplar dizisi halinde düzenlemeye hizmet edebilir ama yüzlerce hatta binlerce sınıfı ve yöntemi bir ya da daha fazla bağımlılık kabusuyla iç içe geçirerek daha da karmaşıklık kazandırır, yani kodunuza ihtiyaç duyulmayan karmaşıklık katmanları eklemiş olursunuz!
Tüm deneyim arayüz ile başlar. Arayüz deneyimi, alttaki teknolojinin ve soyutlama katmanlarının sonucudur. Ne kadar çok soyutlama kullanırsanız, arayüz o kadar az verimli olur ve uygulama o kadar hataya açık hale gelir. Soyutlama ne kadar yüksek olursa, detay ve verimlilik o kadar fazla kaybolur.
Bunu anlamak gerek: Herhangi bir projede ideal kod satırı sayısı ne kadar az olursa proje o kadar açık ve okunaklıdır.!
Herkesin ihtiyaç duymayacağı tek şey genel amaçlı bir çatıdır. Herkesin sorunu birbirinin aynısı değildir, herkesin çözmeye çalıştığı sorun kendine özeldir.
Bazı şirketler PHP çatılarıyla ilgili yutturmacaları dinlemeye başladılar ve bir sonraki projelerine bu popüler genel amaçlı çatılardan birini kullandılar ve süreç felaketle sonuçlandı. Sadece genel amaçlı çatının çok özel ihtiyaçlarını çözmede gerçekten kötü olduğunu keşfetmediler, aynı zamanda bunu yapmakta da oldukça yavaş olabileceğini de gördüler. Ölçeklendirmek imkansızdı ve sonuç olarak, çerçeveyi gerçekten ihtiyaç duymadıklarını çıkarmak için çaresiz bir girişimde parçalamaya başladılar.
Her zaman en faydalı olanı seçin:
Ihtiyacımız olan teori veya dogmadan ziyade pratik sonuçların göz önünde bulundurulmasıyla oluşturulan eylem veya politikalardır.
– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014
Yanlış yol: Mutlaka bir uygulama çatısı kullanmak gerekir.
Fildişi kule tasarlar gibi düşünmeye ve tasarım modellerine büyük alerjim var. Peter Norvig, Harlequin’deyken, tasarım kalıplarının programlama dillerinde nasıl bir kusur olduğunu anlatan bir yazı yazdı. Daha iyi bir programlama dili edinin. Kesinlikle haklı. Desenlere tapmayın ve devamlı “Ah, X modelini kullanacağım” diye düşünmeyin.
– Brendan Eich Coders at work - Reflections on the Craft of Programming
Yazılım mühendisliğinde, tasarım deseni yazılım tasarımında yaygın olarak ortaya çıkan bir sorunun yeniden kullanılabilir bir çözümüdür. Tasarım deseni doğrudan koda dönüştürülebilen bitmiş bir tasarım değildir. Bir problemin çözümü ile ilgili birçok farklı durumda kullanılabilecek bir açıklama veya fikirdir. Nesneye yönelik tasarım desenleri tipik olarak, son uygulama sınıflarını veya dahil olan nesneleri belirtmeden, sınıflar veya nesneler arasındaki ilişkileri ve etkileşimleri gösterir.
PHP imperative, fonksiyonel, nesne tabanlı, prosedürel ve reflective paradigmaları destekler. PHP birçok sorunu farklı şekillerde çözmeyi mümkün kılan çok sayıda farklı araca sahip devasa bir araç kutusudur.
PHP tamamen özgürdür, hızlı ve ölçeklenebilir çözümler sunar ve sorunlarla başa çıkmanın birçok farklı yoluna sahiptir.
Kendimizi yada daha spesifik olarak kodumuzu geliştirmeye çalıştığımızda, bazen belirli bir örüntü veya düşüncenin felsefesine takılırız ve pratik düşünmeyi unutmaya meyilliyiz.
Programlarımda desenler gördüğümde, bunun bir sorun belirtisi olduğunu düşünüyorum. Bir programın şekli sadece çözmesi gereken sorunu yansıtmalıdır. Koddaki herhangi başka bir düzenlilik, en azından benim için yeterince güçlü olmayan soyutlamalar kullandığımın - genellikle elle yazmam gereken bazı makroların genişlemelerini ürettiğimin bir işaretidir.
Belli bir kalıp veya çözümün arkasındaki felsefe veya düşünceye kapılmamalıyız. Asıl endişemiz, kodun okunmasının ve anlaşılmasının mümkün olduğu kadar kolay tutulması ve bunun sonucunda da bakımı kolay ve güvenli olmasıdır.
Anti-patern diye bir şeyin var olduğunu da hatırlamalıyız. Yaygın olarak kullanılabilecek ancak pratikte etkisiz ve / veya verimsiz bir kalıptır.
Bence kalıplar genel sorunlar için genel olarak en iyi çözümler olarak kabul edildi. Ama şimdi bir süredir buralarda olduklarından ve uygulamaların olması gerekenden on kat daha karmaşık hale getirildiğini gördük, çünkü insanlar okudukları tüm kalıpları kullanmaya çalışıyorlar. Desenin değerine dair izlenimim biraz değişti. (“Uygulamam iyi tasarlandı çünkü desenlerle doludur.”)
– Paul Weaton Evil Design Patterns
Her zaman en faydalı yolu seçin.
Ihtiyacımız olan teori veya dogmadan ziyade acil pratik sonuçların göz önünde bulundurulmasıyla yapılan eylem veya politikalardır.
– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014
Yanlış yol: Her zaman bir tasarım deseni kullanmaya çalışmak.
Nesne tabanlı dillerle ilgili sorun, kendileriyle birlikte taşıdıkları büyük kapalı ortamlara sahip olmalarıdır. Bir muz istemişsin, fakat tüm ormanı elindeki muz tutan bir goril ile birlikte sana veriyor.
– Joe Armstrong Coders at work - Reflections on the Craft of Programming
Soyutlama güçlüdür. Gerçekten alerjim olan ve 90’larda tepki verdiğim şey tüm CORBA, COM, DCOM, nesne tabanlı saçmalıktı. Başlangıç olarak “Merhaba dünya” yazdırmak için 200.000 yöntem çağrısı yapmak çılgınca bir şey. Bu çok komik! Böyle bir tarz ile anılan bir programcı olmak istemezsiniz.
– Brendan Eich Coders at work - Reflections on the Craft of Programming
Birçok yazılım geliştirici ve birçok şirket, nesneye yönelik programlamanın bugün yazılım geliştirmenin tek makul yolu olduğunu düşünüyor. Nesne yönelimli programlamaya karşı çıkan herkes endüstrinin “geleneksel bilgeliğine” karşı çıktıklarının farkına varır.
Programlama blogları ve forumlarında, nesne tabanlı programlamayı savunan ve standart bir tanımları olmamasına rağmen ne hakkında konuştuklarını bildiklerinden emin olan birçok insan var!
Gerçek şu ki, nesne tabalı programlama sık sık gereksiz karmaşıklık yükünü doğurur!
Bilgisayar bilimcileri ve programcıları olarak, önyargıları bir kenara bırakmayı ve verilen bir soruna en iyi çözümü bulmayı öğrenmeliyiz.
Günümüzde PHP’nin en güçlü yanlarından biri, imperatif, fonksiyonel, nesne tabanlı, prosedürel ve reflective paradigmalar için verdiği destek. PHP, birçok sorunu farklı şekillerde çözmeyi mümkün kılan çok sayıda farklı araca sahip devasa bir araç kutusudur. - Her zaman bir den fazla yol vardır!
Bir uygulama içindeki farklı sorunları tek bir özel programlama paradigmasına zorlamaya çalışırken, yaratıcı bir şekilde düşünmüyoruz ve verimli çalışmıyoruz!
Belirli bir programlama paradigmasını anlamanın en iyi yollarından biri, ilk olarak nasıl ortaya çıktığına bakmaktır. Gelişiminin nedeni neydi? Yeni bir düşünme biçimine ihtiyaç duyan diğer programlama paradigmalarında ne gibi problemler yaşandı? Gerçek bir dünya problemi miydi yoksa sadece akademik bir problem miydi? Ve o zamandan beri nasıl gelişti?
X kişisinin ne söylediği veya Y kişisinin ne tanımladığı önemli değil, paradigmalar bağlamında önemli olan onları oluşturan tarih.
Yazılım tasarımı yapmanın iki yolu vardır. Birinci yol, o kadar basit hale getirmek ki açık bir şekilde hiçbir eksikliğin olmamasını sağlamak. Ve diğer yol ise, bariz bir eksiklik olmayacak şekilde karmaşık hale getirmektir.
Geçmişte, nesne tabanlı programlamanın ortaya çıkmasından önce, ellili yılların sonlarında, bazen birinci ve ikinci nesil dilleri olarak adlandırılan yapılandırılmamış programlama dilleri kullanılarak birçok yazılım geliştirilmiştir. Yapılandırılmamış programlama, tarihsel olarak en eski programlama paradigmasıdır. “Spagetti” kodunu ürettiği için ağır eleştirildi.
Yapısal olmayan programlama kullanan hem yüksek hem de düşük seviyeli programlama dilleri vardır. Bunlar arasında BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, makine düzeyinde kod, erken assembler sistemleri (işlemsel meta operatörleri olmayanlar) ve bazı betik dilleri bulunur.
Yapılandırılmamış bir dilde bir program genellikle sıralı olarak düzenlenmiş komutlardan veya genellikle her satırda bir tane olmak üzere ifadelerden oluşur. Satırlar genellikle numaralandırılır veya yürütme akışının programdaki herhangi bir satıra atlamasına izin veren etiketlere sahip olabilir (popüler olmayan GOTO ifadesinde olduğu gibi).
Sonra, altmışlı yıllarda, yapısal programlama ortaya çıktı - esas olarak Edsger W. Dijkstra’nın ünlü yazısı nedeniyle Go To kalıpları zararlı olarak kabul edildi .
Yapısal programlama, alt yordamları, blok yapıları ve döngüleri kullanarak yazılımın sadeliğini, kalitesini ve kodlanmasını geliştiren bir programlama paradigmasıdır. Bu, GOTO deyimi gibi basit atlamaların kullanılmasının aksinedir.
Daha sonra, prosedürel programlama yapılandırılmış programlamadan türetilmiştir. Prosedürel programlama “prosedür çağrısı” kavramına dayanır. Bir “prosedür çağrısı”, “işlev çağrısı” için başka bir isimlendirmedir. Prosedürler ayrıca rutinler, alt rutinler veya yöntemler olarak da bilinir. Bir prosedür basitçe gerçekleştirilecek bir dizi hesaplama adımını içerir. Herhangi bir prosedür, başka prosedürler veya kendisi de dahil olmak üzere, programların yürütülmesi sırasında herhangi bir noktada çağrılabilir.
Başlangıçta, tüm prosedürler bir programın herhangi bir bölümünde global veri olarak mevcuttu. Küçük programlarda bu bir problem teşkil etmedi, ancak işler daha da karmaşıklaştıkça ve programın boyutu büyüdükçe, programın bir kısmındaki küçük değişiklikler diğer birçok bölümü de büyük ölçüde etkiledi.
Hiç kimse programdaki değişiklikleri planlamıyordu ve çok fazla bağımlılık vardı. Bir prosedürde yapılan küçük bir değişiklik, orijinal koda bağlı olan birçok başka prosedürde bir hata dizisine neden olur.
Verilerin “nesneler” adı verilen ayrı kapsamlara bölünmesine izin veren yeni bir teknik gelişti. Yalnızca aynı kapsama ait belirli prosedürler aynı verilere erişebilmeli. Buna veri gizleme veya kapsülleme dendi. Sonuç çok daha iyi organize edilmiş kod oldu.
Başlangıçta nesneler nesne olarak adlandırılmadı, sadece ayrı kapsamlar olarak görüldü. Daha sonra bağımlılıklar azaltılarak bu kapsamların içindeki prosedürler ve değişkenler arasındaki bağlantılar yalıtılmış bölümler olarak görüldüğünde, sonuç “nesneler” ve “nesneye tabanlı programlama” kavramlarını doğurdu.
Daha sonra, esas olarak Java’nın gelişmesi nedeniyle, bazı “buzzwords” ifadeleri ortaya çıktı ve “bir prosedür” veya “bir işlev” artık bir işlev olarak adlandırılmadı, ancak ayrı bir kapsamda bulunduğunda “bir yöntem” olarak yeniden adlandırıldı. Değişkenler artık “değişkenler” olarak da adlandırılmadı, ancak ayrı bir kapsamda bulunduklarında “özellikler” olarak yeniden adlandırıldılar.
Dolayısıyla bir nesne özünde basitçe şimdi “yöntemler ve öznitelikler” olarak adlandırılan fonksiyonlar ve değişkenler topluluğudur.
Yöntemlerin ve niteliklerin ayrı bir kapsam içinde izole edilmesinin yolu “bir sınıf” kullanımıdır. Bir sınıf, bir kez yaratıldığında nesne olarak adlandırılır.
Nesneler birbirlerine referans verebilir ve bu referansla içerideki yöntemler (fonksiyonlar) birbirleriyle “iletişim kurabilir”. Nesneler ayrıca yöntemleri diğer nesnelerden “devralabilir” ve bu şekilde genişletilir, buna “miras” denir. Bu, kodu tekrar kullanmanın ve ortak sınıflar ve arabirimler aracılığıyla yazılımın bağımsız uzantılarına izin vermenin bir yoludur. Nesnelerin ilişkileri hiyerarşiye yol açar. Kalıtım, 1967’de programlama dili Simula 67 için icat edildi.
Nesneler, diğer nesnelerden yöntemleri devralabilir ve bunları eklenmiş veya değiştirilmiş işlevlerle “geçersiz kılabilir”, buna “polimorfizm” denir.
Bu farklı fikirlerin nasıl uygulandığı, programlama dilden programlama diline kadar büyük ölçüde değişir.
Nesneye yönelik programlama, kodu öncekinden başka bir şekilde düzenlemekle ilgilidir. Prosedürel programlamanın bir uzantısıdır ve verileri gizleme (kapsülleme) ve küresel bir kapsamdan kaçınma ile ilgilidir. Orijinal kodu (kalıtım) etkilemeden, planlarını “ödünç alarak” işlevlerin genişletilmesiyle ilgilidir. Ve orijinal kodu (polimorfizm) etkilemeden fonksiyonları geçersiz kılmakla ilgilidir.
Nesneye yönelik model, programları biriktirerek oluşturmayı kolaylaştırır. Bunun ne anlama geldiği, pratikte spagetti kodu yazmanın yapılandırılmış bir yolunu sağlamasıdır.
– Paul Graham Ansi Common Lisp
Yanlış yol: Her zaman nesne tabanlı programlama kullanılmalıdır.
Çatı kullanımı için sıklıkla ifade edilen bir argüman da, insanların başkaları tarafından sıfırdan yazılmış kod tabanlarıyla uğraşmak istemedikleridir.
Ancak bu, PHP topluluğundaki web geliştiricileri arasında çoğunlukla karşılaşılan garip bir zihniyettir. Topluluk içinde profesyonellik ve deneyim eksikliği yayan bir şey.
Sıfırdan kod yazmak ve başkalarının kodlarıyla ilgilenmek normaldir. Profesyonel bir programcının günlük çalışmasının bir parçası. Korkacak bir şey değil.
Profesyonel bir programcı, başkalarının kurallarına bakmaz ya da artık şirket veya proje ile ilişkili olmayan eski programcının hangi çatıyı kullandığını ve neden kullandığını düşünmeden işe başlamalıdır.
Bu profesyonel bir programcının zihniyeti değildir. Bunu kimse yapmaz.
Belki de PHP web geliştirmeye giriş engelinin düşük olması bu tür bir zihniyette rol oynamaktadır. Ne olursa olsun, bir insanın yanlış iş kolunda olduğuna dair bir işarettir.
Programlamanın büyük bir kısmı, başkalarının koduyla çalışmak zorunda olan insanlarla ilgilidir. Var olan kod tabanını iyileştirmeye çalışmak ve bazen de yeniden yazmak çalışmanın bir parçasıdır.
Programlamanın büyük ustalarından not alın, İşyerindeki kodlayıcılar - Programlama Zanaatına Yansımalar adlı kitabı okuyun.
Dünyadaki en büyük ve en başarılı kod tabanlarından bazıları, birbiriyle hiç tanışmamış yüzlerce insan tarafından geliştirilen kod tabanları, herhangi bir çerçeve kullanmadan geliştirilen kod tabanları, tamamen prosedürel bir programlama dilinde kullanılmayan kod tabanlarıdır. Ve hatta bazıları prosedürel paradigmadan başka bir şey yapmazlar ve farklı yapmayı hayal etmezler.
Linux Çekirdeği, herhangi bir çatı kullanmadan 14.000’den fazla katılımcı tarafından tamamen prosedürel programlama kullanılarak yazılmış 20 milyon kod satırından oluşur.
BSD ve Linux GNU userland ’ın çoğu tamamen prosedürel programlama kullanılarak yazılmıştır, ve Her hangi bir çatı da kullanılmamıştır.
Aynı şey, sonunda, orijinal programcılar tarafından terk edilen ama diğer yetenekli programcılar tarafından devam edilen dünya çapında yüzlerce Açık Kaynak projesi için de geçerlidir. Bu projelerin birçoğunun dokümantasyonu (eğer varsa) çok azdır, kod tabanında yorum satırları yok denecek kadar azdır ve öneri ya da yönlendirme konusunda hiçbir yardımı yoktur.
Tüm PHP kod temeli, herhangi bir çerçeve kullanmadan, tamamen prosedürel bir programlama dili olan C ile yazıldı.
PHP’de bir sınıf tanımladığın zaman, ya da PHP’nin en sevdiğin çatısını ateşlesen, başkasının saf usule ilişkin işlerinde çalışıyorsun demektir!
Elbette, korkunç bir kod, belki de başlangıçtan tasarlanmamış bir kod, ya da birçok kez kendini aşan bir kod, ancak müşteri yeniden yazma ile baş etmek istemedi. Bu kod ekleme ve çıkarma yapmanıza engel oluyor olabilir, ancak hiçbir çatı bu durumu önleyemezdi. Bu genellikle bir programın doğal büyüme sürecidir. Sonunda her türlü çatı zaten parçalara bölünmüş olacaktı.
Ve tabii ki korkunç bir spagetti kod gerçeği var, ama kimse bilerek korkunç spagetti kodu üretmiyor. Bazen bu, deneyim eksikliğinin bir sonucudur, çoğu zaman müşteri hatasıdır, çünkü gelişimin ortasında birkaç kez teknik özellikleri değiştirdiler, her iki durumda da, bir çatı kullanılmış olsa bile, sonuç hala spagetti kodu olacaktı. ve nesne tabanlı paradigmanın ne kadarının kullanıldığı önemli değil, sonuç yine de spagetti kodu olacaktı.
Programcılar hepimiz bu durumları önlemeye çalışıyoruz, ancak ** bu normaldir , bu programlama sanatıdır , bu programcı olmanın** ne anlama geldiğinin bir parçasıdır!
Yanlış yol: Başkalarının yazdığı koddan korkmayın.
FIG kısaca “Framework Interoperability Group” yani “Çatılarası Uyumluluk Grubu”.
PHP-FIG, 2009 yılında php | tek’te bir dizi çatı geliştiricisi tarafından oluşturulmuştur. O zamandan beri, diğer birçok üye başvurmuş ve oy kullanmış, büyüklüğü arttırılmıştır. Başlangıçta 5 üyeden oluşuyorken sonradan sayı 20 üyeye çıkmıştır.
PHP-FIG ile ilgili birçok tartışma var. Bazıları PHP-FIG’i PHP topluluğundan beri PHP topluluğunun başına gelen en iyi şey olarak görürken, diğerleri grubu unutulması en iyi şey olarak görür.
PHP-FIG ile ilgili sorunlardan biri, SSS’de şöyle kendini gösterme şeklidir.
Grubun arkasındaki fikir, proje temsilcilerinin projelerimiz arasındaki ortaklıklar hakkında konuşması ve birlikte çalışabileceğimiz yollar bulması. Ana izleyicilerimiz birbirimizdir, ancak PHP topluluğunun geri kalanının izlediğini çok iyi biliyoruz. Eğer diğer insanlar ne yaptığımızı kabul etmek isterlerse, bunu memnuniyetle kabul ederler, ancak amaç bu değildir. Gruptaki hiç kimse size bir programcı olarak nasıl uygulama geliştireceğinizi söylemek istemez.
Ancak, grubun birkaç üyesinin çalışmalarını gördüğümüzde, hedefin yukarıdaki açıklamaya oldukça aykırı olduğunu açıkça görebiliyoruz. Bu üyeler PHP-FIG’in, grubun asıl adı olan kabul edilen bir “PHP standart grubu” olması için yorulmadan çalışırlar. Bunu PHP-FIG’in çalışmalarını kitaplarında, web sitelerinde, blog yazılarında, forumlarında vb. “Modern PHP” olarak sınıflandırarak ve diğer yolları geriye dönük olarak sınıflandırarak yaparlar.
PHP-FIG ile ilgili sorunlardan biri, pek çok çatı ve Açık Kaynaklı projenin standartlarının birçoğunu benimsemiş olmasına rağmen, bu standartların “çatı perspektifinden” sorunları ele almasından dolayı temel olarak gerçek yaşam sorunları karşısında oldukça kullanışsız kalıyor olmasıdır.
Pek çok insan, müşterilerin satın almak ve kullanmak istedikleri, son derece verimli, güvenli ve uygun maliyetli yazılımlar geliştirmektedir. Çatı fanatiklerinin fikirlerine uyması gereken standartlarla rahatsız edilmemeliler. Eğer bu şekilde olursa, bu sektör için felaket olur.
Bir tür standart grubunun oluşturulması gerekiyorsa, sadece framework ve Open Source CMS proje geliştiricilerinin değil, tüm PHP topluluğunun çıkarlarını yansıtması gerekir. PHP programlama dilinin geliştiricileri tarafından temsil edilmeli ve oy kullanma hakkı olan çok daha büyük bir üyelik ile temsil edilmelidir.
PHP-FIG tarafından geliştirilen standartları benimsemeyi seçerseniz, bu standartların bazılarının - örneğin PSR-0 ve PSR-4 otomatik yükleyici standartları ve bazı diğer standartların - kodunuzu nasıl değiştirdiğinize doğrudan bir etkisi olduğunu anlamalısınız.
Birçok endüstri ölçeklenebilir, çalışma zamanı açısından kritik ve düşük maliyetli bir yazılımlara ihtiyaç duyuyor ama bunun PHP-FIG’in bu standartları kullanılarak geliştirilemeyeceği aşikardır.
Yanlış yol: PHP-FIG standardlarını takip etmede aşırıya kaçma.
Programcılarla ilgili en büyük problem iş işten geçene kadar ne yaptıklarını söyleyememeleridir.
– Seymour Cray, defprogramming.com
Güvenli kodlama, kötü niyetli ya da tehlikeli insanlar ya da diğer programlar tarafından saldırıya dirençli programlar yazma pratiğidir. Güvenli kodlama, verilerin hırsızlık veya bozulmaya karşı korunmasına yardımcı olur. Ek olarak, güvensiz bir program, bir saldırganın bir sunucuyu veya kullanıcının kimliğini kontrol altına almasına erişim sağlayabilir, bu da tek bir kullanıcıya hizmet verilememesinden, binlerce kullanıcının gizli bilgilerin açığa çıkmasına, hizmet kaybına veya sistemlerin zarar görmesine kadar bir çok kötü durumla sonuçlanabilir.
Her bilgisayar programı bir güvenlik saldırısı için potansiyel bir hedeftir. Saldırganlar, uygulamalarınızdaki güvenlik açıklarını bulmaya çalışacaktır. Daha sonra gizli bilgileri çalmak, programları ve verileri bozmak, sunucu ve ağların kontrolünü ele geçirmek için bu güvenlik açıklarını kullanmaya çalışacaklar. Müşterilerinizin bilgileri ve itibarınız tehlikede altındadır.
Güvenlik yazılıma eklenebilecek bir özellik değildir.!
Güvensiz bir uygulama, güvenliğini sağlamak için kapsamlı bir yeniden tasarım gerektirebilir. Yazılımınıza yönelik tehditlerin yapısını tanımlamalı ve uygulamanızın planlaması ve geliştirilmesinden başından itibaren güvenli kodlama uygulamalarını dahil etmelisiniz.
Kritik yazılım kaynaklarının güvenceye alınması, saldırganların odağı uygulama katmanına doğru olduğundan her zamankinden daha önemlidir. 2009 SANS araştırması, web uygulamalarına yönelik saldırıların İnternette gözlemlenen toplam saldırı girişimlerinin %60’ından fazlasını oluşturduğunu ortaya çıkardı.
PHP aynı zamanda hem bir programlama dili hem de bir web uygulama çatısı olduğu için olağandışıdır. Bu, PHP’nin, güvensiz kod yazmayı çok kolaylaştıran dile yerleşik bir çok web özelliğine sahip olduğu anlamına gelir.
Karmaşıklık çok kötüdür. Geliştiricilerin ömrünü bitirir, ürünleri planlamayı, geliştirmeyi ve test etmeyi zorlaştırır, güvenlikle ilgili zorluklara neden olur ve son kullanıcı ve yönetici sıkıntılarına neden olur.
Uygulamaların uygun güvenlik gereksinimleri ile tasarlanması ve uygulanması için, güvenli kodlama uygulamaları ve güvenlik risklerine odaklanma, günlük operasyonlara, düşüncelere ve gelişim süreçlerine dahil edilmelidir
Genellikle, güvenli bir yazılım oluşturmak, yazılım paketi tamamlandıktan sonra güvenlik sorunlarını düzeltmekten daha ucuzdur. Hele bir de güvenlik ihlaliyle ortaya çıkacak maliyetler de göz önünde bulundurulursa…
Yanlış yol: Yazılım geliştirirken güvenlik konusunu hiç düşünmemek.
Yazılı belgeleri de yanlış anlamak mümkün. Bunun için bazı konuları aydınlatmak gerekiyor.
Q: Bu sitenin amacı nedir ve neden biraz çatışmacı bir yaklaşım seçilmiş?
A: Güncel uygulamalar ve ayrkırı görüşler hakkında tartışma ve düşünme ortamı oluşturmak.
Q: Nesne tabanlı programlamanın kötü mü ya da yanlış mı olduğunu söylüyorsunuz?
A: Hayır, tabii değil! Sorunları çözerken daima yalnızca ve daima nesneye yönelik paradigmayı düşünmenin ve kullanmanın kötü olduğunu söylüyoruz. Sadece siyah ya da beyaz şeklinde düşünmenin yanlış olduğunu söylüyoruz.
Tek bir uygulamada bile bir çok problem vardır. Çoklu paradigma bazen en iyi çözümdür ve bütün çözümler çözmeye çalıştığınız soruna bağlıdır.
Belirli bir sorunu uygun olmayan bir yolla çözmeye çalıştığınız kötü şeyler olur.
Q: Bütün uygulama çatılarının (framework) kötü olduğunu mu söylüyorsun?
A: Belirli ya da bütün uygulama çatılarını yargılamaya çalışmıyoruz. PHP’nin üstünde her zaman bir uygulama çatısı kullanma algısı ile mücadele ediyoruz.
Q: Bir uygulama çatısı beni hızlandırıyorsa, neden kötü olsun ki?
A: Tartışmaya açtığımız durumu ve uzun vadeli sonuçlarını analiz ettiyseniz ve o zaman “hızlı üretmenin” aslında başa çıkmanız gereken tek sorun olduğunu görürsünüz. Bunun yüzünden çoğunlukla programlama veya yazılım geliştirme ile uğraşmak yerine bas ve tıkla çözümleriyle uğraşıyoruz.
Hızlı bir şekilde üretmeye başlamak, yazılım tasarlamamak anlamına gelir; bu çoğunlukla, karşılaştığınız sorunu analiz etmediğiniz ve seçiminizin uzun vadeli sonuçlarını anlamadığınız anlamına gelir.
Q: Harici paket kullanmanın kötü olduğunu mu söylüyorsunuz?
A: Hayır. Harici kütüphanelerin kullanımını teşvik ediyoruz. Herhangi bir sınırlama veya kısıtlama yapmadan kendi projelerinize kolayca entegre edebileceğiniz her kütüphaneyi kullanın. Bu kesinlikle harika bir şey!
Q: Siz kimsiniz?
A: Bu web sitesi PHP topluluğundaki fikirler ve aşırılıkçılıkla mücadele hakkındadır, kişisel şöhret ya da tanınma amacı gütmemektedir. İnsanları adlandırmak, odağı yalnızca web sitesinde değinilen sorunlardan sorunları çözen kişilere kaydırır. Sadece fikirlere odaklanmanızı tavsiye ediyoruz.
Q: Yazılım geliştirme alanındaki tecrübeniz nedir?
A: Bu sitede ifade edilen fikirlere ve sonuçlara ulaşmak için çok fazla tecrübeye gerek olmadığını, ana temaya odaklanmanın yeterli olacağını düşünüyoruz.
PHP The Wrong Way on Hacker News
Why bad scientific code beats code following “best practices”
Coders at work - Reflections on the Craft of Programming
The traits of a proficient programmer
OWASP Secure Coding Guidelines
Survive The Deep End: PHP Security
Refactoring Improving the Design of Existing Code
Understanding programming languages
GitHub’taki repo ile başlayabilirsiniz.