Fork me on GitHub

PHP

Galat-ı Meşhur

Son güncelleme tarihi: 2019-01-10
cartoon

Giriş

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 programlama konusunda pragmatik bir bakış sunmak amacıyla oluşturulmuştur. Hedeflenen popüler eğilimler, teori veya akademik dogmalardan ziyade tecrübe ve pratik sonuçlar tarafından oluşturulan 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.

Diğer Diller

Programlama kuralları ve kılavuzlarıyla ilgili bir sorun, genellikle yalnızca belirli bir bağlamda bir amaca hizmet etmeleridir. Bağlam dışında alındığında, iyi bir kural korkunç bir kural haline gelebilir. Aslında, her iyi kural aşırıya götürüldüğünde kötüye gider.

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 sık sık suistimal edilir.

Deneyimler, genel kuralların ve kılavuzların kötüye kullanılmasının her zaman komplikasyon, güvenlik eksikliği, hataya açık sonuçlar ve hatta bazı durumlarda tam felaketle sonuçlandığını göstermiştir.

“Basit ve Aptal Tutun, (Keep It Simple, Stupid)” ın kısaltması olan [KISS ilkesi] (https://en.wikipedia.org/wiki/KISS_principle), genellikle deneyimli kişiler tarafından çok deneyimli olarak görülen, çok akıllıca ve iyi bir ilkedir. Takip etmek için iyi bir tavsiyedir. Ancak bu büyük prensip bile, aşırıya götürülürse bir proje için tehlike oluşturur. Gerekli işlevsellik eksikliği ile sonuçlanan “çok basit” gibi bir şey de ortaya çıkabilir.

Yanlış yol: Kuralları ve kılavuzları din gibi algılamaThumbs down

Mutlaka uygulama çatısı (framework) kullanmak gerekir

Tüm genel amaçlı PHP uygulama çatıları mutlaka patlar!

Rasmus Lerdorf

PHP topluluğunda, gerçekten 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ı çerçevenin kullanılması gerektiğinin düşülmesidir.

Bu eğilim, geliştirme sürecin sonucununun katilesini artırdığı için değil, teknoloji 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 ve akranları olarak gördükleri kişiler tarafından daha akıllı, daha havalı ve daha kabul edilebilir görünmek için 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 önceden inşa edilmiş bir evi genel amaçlı bir yazılım çatısı karşılaştırabilirsiniz. Önceden inşa edilmiş bir evi bir araya getirmekten 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] (https://en.wikipedia.org/wiki/Django_%28web_framework%29) ve [Ruby on Rails] (https://en.wikipedia.org/wiki/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 o 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 bir kütüphane kullanmak sadece 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.

Rasmus Lerdorf

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 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: Mutlaka bir uygulama çatısı kullanmak gerekir. Thumbs down

Her zaman bir tasarım modeli kullanılmalı

Fildişi kule tasarlar gibi düşünmeye ve tasarım modellerine bu büyük alerjim var. Peter Norvig, Harlequin’deyken, tasarım kalıplarının programlama dilinizde nasıl bir kusur olduğunu anlatan bir yazı yazdı. Daha iyi bir programlama dili edinin. Kesinlikle haklı. Desenlere tapmayın ve 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, bir tasarım deseni, yazılım tasarımında yaygın olarak ortaya çıkan bir soruna yeniden kullanılabilir bir çözümdür. Bir tasarım deseni doğrudan koda dönüştürülebilen bitmiş bir tasarım değildir. Birçok farklı durumda kullanılabilecek bir problemin nasıl çözüleceği ile ilgili 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 geliştirmeye çalıştığımızda ve bu durumda daha spesifik olarak kodumuzda, bazen belirli bir örüntü veya düşüncenin felsefesine takılırız ve pratik olarak 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.

Paul Graham

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 tutulması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. Thumbs down

Her zaman nesne tabanlı programlama yapılmalı

Nesne tabanlı dillerle ilgili sorun, kendileriyle birlikte taşıdıkları bu 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ğuruyor!

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!

Kıssaden hisse

Belirli bir programlama paradigmasını anlamanın en iyi yollarından biri, ilk nasıl geliştiğine 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ı yapan 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.

C.A.R. Hoare

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] (http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html) .

Yapısal programlama, alt yordamları, blok yapıları ve döngüleri kullanarak yazılımın netliğ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 nesneler 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. Thumbs down

Başkalarının yazdığı koddan korkmayın

Ç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] (https://www.kernel.org/), 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. Thumbs down

PHP-FIG standardlarını takip etmede aşırıya kaçmayın

FIG kısaca “Framework Interoperability Group” yani “Çatılarası Uyumluluk Grubu”.

[PHP-FIG] (http://www.php-fig.org/), 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. Thumbs down

Yazılım güvenliğini gözardı etmeyin

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.

Baştan güvenli

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.

Ray Ozzie

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. Thumbs down

SSS

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. # Tavsiye edilen diğer kaynaklar #

PHP The Wrong Way on Hacker News

Why bad scientific code beats code following “best practices”

How to program without OOP

Coders at work - Reflections on the Craft of Programming

The traits of a proficient programmer

OWASP Secure Coding Guidelines

Security by Design Principles

Survive The Deep End: PHP Security

Refactoring Improving the Design of Existing Code

The Practice of Programming

The pragmatic programmer

Understanding programming languages

Nasıl katkıda bulunabilirim?

GitHub’taki repo ile başlayabilirsiniz.

sections/LANGUAGE klasörüne yeni bölümler ekleyebilir ya da var olanları düzenleyebilirsiniz.