Modern WordPress Geliştirmeye Nasıl Yaklaşılır (2. Bölüm)

Yayınlanan: 2022-03-11

WordPress, gezegendeki en yaygın kullanılan site teknolojisidir ve bunun iyi bir nedeni vardır. Yine de özündeki eski kod bir karmaşadır ve bu sorun üçüncü taraf geliştiricilere kademelendirilir. Bazı geliştiriciler bunu, kendi WordPress PHP kodlarında köşeleri kesmek için bir bahane olarak alırlar, ancak bu yaklaşım, en önemsiz değişiklikler dışındaki herkes için uzun vadede daha pahalıdır.

İki bölümden oluşan serimizin 1. Bölümünde, genel proje ve iş akışı araçlarına ve ardından ön uç geliştirmeye odaklandık. Şimdi boğayı boynuzlarından alma ve PHP ile güreşme zamanı: Spesifik olarak, arka uç WordPress koduyla çalışırken en iyi uygulamaların nasıl izleneceği. Bunu bir PHP/WordPress öğreticisi olarak düşünebilirsiniz, ancak WordPress arka uç özelleştirmesini zaten yaptığınız varsayımıyla biraz daha gelişmiş.

Peki, hangi modern yazılım tasarım ilkeleri ve PHP özellikleri size zamanınız için en iyi değeri verecek? Aşağıda, şiddetle tavsiye ettiğim 10 WordPress ve PHP geliştirme uygulaması bulunmaktadır.

Modern WordPress Geliştirme En İyi Uygulaması #1: “Endişelerin Ayrılığını” İzleyin

Endişelerin ayrılması, WordPress PHP kodunun farklı işlevlere veya amaçlara sahip bölümlerinin birlikte karıştırılmaması gerektiği anlamına gelir. Bunun yerine, tanımlanmış bir arayüz aracılığıyla verileri birbirine ileterek farklı bölümler veya modüller halinde düzenlenmelidirler. ( Arayüz , bir modülün girdi olarak aldığı ve çıktısını geri verdiği bir dizi tanımlı parametredir.) Yakın ilişkili bir terim, tek sorumluluk ilkesidir : Her kod modülü (veya işlevi) yalnızca bir şeyden sorumlu olmalıdır.

Bu ilkeleri takip etmenin nihai amacı, modüler ve dolayısıyla sürdürülebilir, genişletilebilir ve yeniden kullanılabilir kod üretmektir.

Bu oldukça ağız dolusu oldu, o yüzden her şeyi birbirine karıştıran bazı WordPress PHP (WordPress çekirdeğinden) örneğine bakalım. Bu kodlama stiline genellikle “spagetti kodu” denir çünkü iç işleyişini anlamak neredeyse imkansızdır. Aşağıdaki alıntı kısa olması için yeniden düzenlenmiştir; ancak orijinal stil ve biçimlendirme korunmuştur.

 $id = isset( $_REQUEST['id'] ) ? intval( $_REQUEST['id'] ) : 0; <table class="form-table"> <?php $blog_prefix = $wpdb->get_blog_prefix( $id ); $sql = "SELECT * FROM {$blog_prefix}options WHERE option_name NOT LIKE %s AND option_name NOT LIKE %s"; $query = $wpdb->prepare( $sql, $wpdb->esc_like( '_' ) . '%', '%' . $wpdb->esc_like( 'user_roles' ) ); $options = $wpdb->get_results( $query ); foreach ( $options as $option ) { if ( strpos( $option->option_value, "\n" ) === false ) { ?> <tr class="form-field"> <th scope="row"><label for="<?php echo esc_attr( $option->option_name ); ?>"><?php echo esc_html( ucwords( str_replace( '_', ' ', $option->option_name ) ) ); ?></label></th> <?php if ( $is_main_site && in_array( $option->option_name, array( 'siteurl', 'home' ) ) ) { ?> <td><code><?php echo esc_html( $option->option_value ); ?></code></td> <?php } else { ?> <td><input class="<?php echo $class; ?>" name="option[<?php echo esc_attr( $option->option_name ); ?>]" type="text" value="<?php echo esc_attr( $option->option_value ); ?>" size="40" <?php disabled( $disabled ); ?> /></td> <?php } ?> </tr> <?php } } // End foreach </table>

Her şeyden önce, tamamen anlaşılmaz. Ve tek yorumun tamamen gereksiz olan End foreach olmasına bayılıyorum. Veritabanı sorgulama, sorgu sonuçları işleme, HTML'de gömülü ek işlemler (fark etmediyseniz orada iç içe bir if / else vardır), çıktıdan kaçış ve HTML şablonlarının hepsini bir arada püre haline getirdik. Başka bir sorun, gerçek bir parametreyi bir işleve geçirmek yerine doğrudan global $_REQUEST gelen $id parametresidir.

Buna bakıldığında, WordPress çekirdeğinin neden yıllarca aynı kaldığı tamamen anlaşılabilir. Bu tür bir kodu yeniden düzenlemek - özellikle mevcut davranışı korurken - kimsenin yapmak istemeyeceği gerçekten epik bir iştir.

Peki bunu nasıl düzgün yaparız? Hatırlanması gereken bir şey var ki, tek bir doğru yol yoktur. Yukarıda çabalamamız gereken özelliklerden bahsetmiştik: Sürdürülebilir ve modüler olması için WordPress özel PHP koduna ihtiyacımız var. Şimdi yukarıdaki kodu nasıl modüllere ayırabileceğimize bakalım.

SQL sorguları açıkçası ayrı bir modülde olmalıdır. WordPress, örnek olarak kullanılması gereken güzel bir şekilde soyutlanmış bir WP_Query sınıfına sahiptir.
Tüm HTML bir şablona girer. Aşağıda PHP şablonunu ele alacağız.
Kalan PHP kodu bir işleve sarılmalıdır—kod bir işlev için çok uzun veya karmaşıksa birkaç işlev. $id gibi parametreler, işlev bağımsız değişkenleri aracılığıyla iletilir.

Bu, yukarıdaki örneğin büyük ölçüde basitleştirilmiş bir yeniden yazımıdır:

 function betterSiteSettings($args) { $data = WP_Settings_Query($args); // process $data here $context = array_merge([], $data_processed, $other_data); return Template::render('template.name', $context); }

Modern WordPress Geliştirme En İyi Uygulaması #2: Global Değişkenlerden Kaçının

WordPress'in çok fazla global değişkeni var. Global değişkenler neden kötü? WordPress PHP kodunuzu takip etmeyi zorlaştırır ve uygulama durumunu güvenilmez hale getirir. PHP kodunun herhangi bir parçası - ve bu, WordPress'e yüklenen herhangi bir eklenti anlamına gelir - global değişkenleri okuyabilir ve yazabilir, bu nedenle geçerli veriler içerdiklerinin garantisi yoktur. Döngü gibi bir şeyde hangi global değişkenlerin kullanıldığını anlamaya çalışmak da önemsiz bir iş değildir.

Buna pratik açıdan bakalım. Bu örnek WooCommerce'den geliyor. Muhtemelen her WordPress geliştiricisi bunun ne olduğunu bilir—Döngü:

 <?php while ( have_posts() ) : the_post(); ?> <?php wc_get_template_part( 'content', 'single-product' ); ?> <?php endwhile; // end of the loop. ?>

Yukarıdaki snippet, bir ürün şablonu oluşturur. wc_get_template_part aktarılan hiçbir parametre olmadığı için hangi ürünün gösterileceğini nasıl biliyor? Şablona baktığımızda global $product; , geçerli ürün nesnesinin depolandığı yer burasıdır.

Şimdi, ürünleri arayan ve filtreleyen bir katalog sayfamız olduğunu ve aynı sayfada kalırken bir "ürün ayrıntıları" açılır penceresini göstermek istediğimizi hayal edin. Perde arkasında, ön uç komut dosyası, söz konusu ürün şablonunu almak için bir AJAX isteği yapar. wc_get_template_part('content', 'single-product') parametresini kullanmadığı için basitçe çağıramayız, bu yüzden bunun çalışması için birkaç global değişken ayarlamamız gerekiyor.

Daha karmaşık kullanım durumları, birden fazla şablonu, bu şablonlarda tetiklenen kancaları ve geri aramalarını bu kancalara ekleyen üçüncü taraf eklentileri içerir. Hızlı bir şekilde yükselebilir. Bu geri aramaların hangi küresel duruma dayandığını bilmemizin hiçbir yolu yok. Üçüncü taraf eklentiler, geri aramalarındaki herhangi bir global değişkeni değiştirmekte serbesttir. Sistemi kullanmak yerine, güvenilmez global durumdan gelen garip hatalarla karşılaşarak sistemle savaşmaya başlıyoruz.

Bu ürün kimliğini parametre olarak iletmek daha mantıklı olmaz mıydı? Ardından, WordPress tarafından kullanılan global değişkenleri karıştırmaktan endişelenmeden bu şablonu yeniden kullanabiliriz.

Modern WordPress Geliştirme En İyi Uygulaması #3: Nesne Yönelimli Programlama (OOP) Kullanın

Modülerlik, nesneler ve nesne yönelimli programlama kavramına yol açar. En temel düzeyde, OOP, kodu düzenlemenin bir yoludur. İşlevler ve değişkenler, sınıflar halinde bir araya toplanır ve sırasıyla sınıf yöntemleri ve özellikleri olarak adlandırılır. WordPress Eklenti El Kitabı, WordPress özel PHP kodunuzu düzenlemek için OOP kullanmanızı önerir.

OOP'deki önemli bir ilke, yöntemlere ve özelliklere erişimi sınırlamak veya PHP terimleriyle bunları private veya protected olarak belirtmektir, böylece yalnızca diğer sınıf yöntemleri bunlara erişebilir ve bunları değiştirebilir. Bunun için bir OOP terimi, kapsüllemedir : Veriler sınıf içinde kapsüllenir ve bu verileri değiştirmenin tek yolu, sağlanan sınıf yöntemlerini kullanmaktır.

Bu, hata ayıklamayı ve kodunuzun bakımını, tüm kod tabanında herhangi bir yerde değiştirilebilen global değişkenleri kullanırken olduğundan çok daha kolay hale getirir. Global WordPress post değişkenini düşünün. Ona kodunuzun herhangi bir yerinden erişebilirsiniz ve birçok işlevsellik onu kullanmaya bağlıdır. Değişiklikleri yalnızca WordPress temel işlevlerinde kısıtlayabilseydiniz, ancak herkesin okumasına izin verilirse ne olur? Global post değişkenini bir sınıfta gizlemek veya kapsüllemek ve onun etrafında bir arayüz oluşturmak bunu mümkün kılacaktır.

Bu, OOP'nin yalnızca çok temel bir açıklaması ve modern WordPress geliştirmede nasıl kullanılabileceğidir. Daha fazla çalışma için, Carl Alexander'ın WordPress'te OOP konusunda mevcut en kapsamlı ve kullanışlı içeriğe sahip olan WordPress kullanarak nesne yönelimli programlamayı keşfedin e-kitabını tavsiye ederim.

OOP'nin gümüş bir kurşun olmadığını hatırlamak önemlidir: Kötü kod, OOP ile diğer herhangi bir programlama paradigmasında olduğu kadar kolay yazılabilir.

WordPress geliştirme için PHP kullanımı hakkında bazı özel tavsiyelere geçelim.

Modern PHP En İyi Uygulama #1: Hedef PHP 7.0+

Modern PHP özelliklerini kullanmak, PHP'nin modern bir sürümünü gerektirir. 7.0'dan daha düşük PHP sürümlerini desteklemek için hiçbir neden yoktur. WordPress çekirdeği bile 2019'un sonunda PHP 7.0 gerektirecektir.

Yine de, uyumsuz ortamlarda “beyaz ölüm ekranından” kaçınmak için minimum sürümünüzü kontrol etmek iyi bir uygulamadır. Aşağıdaki pasaj, kodda koruma koşuluyla minimum PHP sürümünü bildirmek için bir eklenti başlığının kullanıldığını gösterir.

 <?php /** * Plugin Name: My Awesome Plugin * Requires PHP: 7.0 */ // bails if PHP version is lower than required if (version_compare(PHP_VERSION, '7.0.0', '<')) { // add admin notice here return; } // the rest of the actual plugin here

Modern PHP En İyi Uygulama #2: PHP Endüstri Standartlarını Benimseyin (PSR-2 Kodlama Stili Kılavuzu)

PSR'ler, PHP Framework Interop Group tarafından yayınlanan önerilerdir. Bunlar, herhangi bir modern PHP iş akışında fiili endüstri standartlarıdır ve PHP topluluğunun bir bütün olarak bu standartları takip ettiği güvenle söylenebilir. PSR-2, kodlama stilini tanımlayan bir öneridir. Symfony ve Laravel gibi popüler PHP çerçeveleri PSR-2'yi takip eder.

WordPress kodlama standardı yerine neden PSR-2 kullanasınız? Temel olarak, WordPress standartları eski olduğundan ve daha yeni dil özelliklerinden hiçbirini kullanmadığından. Bu anlaşılabilir bir durumdur çünkü WordPress çekirdeği kendi standartlarını takip etmelidir. Yakın zamana kadar PHP 5.2'yi desteklemek zorundaydı ve PSR-2, PHP 5.2 ile uyumlu değil.

Açık olmayabilir, ancak özü taahhüt etmediğiniz sürece WordPress kodlama standartlarını kullanma zorunluluğu yoktur. PSR-2 standardını takip eden bir eklentiyi WordPress eklenti dizinine göndermekle ilgili herhangi bir sorun olmayacaktır. Aslında, bunu yapmak için bazı çok iyi argümanlar var.

Modern PHP En İyi Uygulaması #3: Bir PHP Şablon Motoru Kullanın

PHP bir şablon motoru değildir. Bir olarak başladı, ancak daha sonra tam özellikli bir programlama diline dönüştü ve onu şablonlama için kullanmaya devam etmek için hiçbir neden yok. PHP için en popüler iki şablon motoru sırasıyla Symfony ve Laravel tarafından kullanılan Twig ve Blade'dir. Bu makale Twig'i örnek bir şablonlama motoru olarak kullanacak; ancak Blade'in benzer özellikleri ve işlevleri vardır. Her ikisini de incelemenizi ve hangisinin size en uygun olduğuna kendiniz karar vermenizi rica ediyorum.

Aşağıdaki örnek, bir PHP şablonunu ve ona karşılık gelen Twig şablonunu karşılaştırmaktadır. PHP örneğinde çıktının görüntülenmesi ve çıkarılması özellikle ayrıntılıdır:

 foreach ( $options as $option ) { ?> <tr class="form-field"> <th scope="row"> <label for="<?php echo esc_attr( $option->option_name ); ?>"> <?php echo esc_html( strtolower( $option->option_name ) ); ?> </label> </th> </tr> <?php } // End foreach

Twig'de bu daha özlü ve okunabilir:

 {% for option in options %} <tr class="form-field"> <th scope="row"> <label for="{{ option.option_name }}"> {{ option.option_name }} </label> </th> </tr> {% endfor %}

Twig'in başlıca avantajları şunlardır:

Okunabilir ve özlü sözdizimi
Otomatik çıkış çıkışı
Kalıtım ve bloklar aracılığıyla şablon uzantısı

Performans açısından Twig, PHP şablonlarını derler ve neredeyse hiç ek yükü yoktur. Twig, yalnızca şablonlamayla sınırlı PHP dil yapılarının yalnızca bir alt kümesine sahiptir. Bu, geliştiricileri şablonlardan iş mantığını kaldırmaya zorlar ve böylece endişelerin ayrılmasını zorunlu kılar.

WordPress için Twig bile var. Adı Timber ve daha iyi şablonlar oluşturmaya başlamanın harika bir yolu. Timber başlangıç teması, temaları OOP yöntemiyle düzenlemenin mükemmel bir örneğidir.

Modern PHP En İyi Uygulaması #4: Besteci Kullanın

Besteci, PHP için bir bağımlılık yöneticisidir. Bir projenin kullandığı kitaplıkların bildirilmesine izin veren ve ardından bunların indirmelerini, kurulumlarını ve güncellemelerini otomatikleştiren bir araçtır. Ardından, her bir kitaplığı manuel olarak istemek yerine Composer'ın otomatik yükleme dosyası vendor/autoload.php eklemeniz yeterlidir.

WordPress eklentileri ve temaları genellikle herhangi bir üçüncü taraf kitaplığı kullanmaz. Bunun nedeni kısmen WordPress'in hemen hemen her ihtiyacı karşılayan kapsamlı bir API'ye sahip olması ve kısmen de olası sürüm çakışmalarıdır. Aynı PHP kitaplığını ancak farklı sürümlerini gerektiren iki eklenti düşünün. İlk çalışan eklenti doğru sürümü alır ve ikinci eklenti de bu sürümü alır. Bu, büyük olasılıkla başka bir beyaz ölüm ekranı durumudur.

Çakışmaları önlemek için, uygulama düzeyinde, yani bir bütün olarak WordPress sitesi bağımlılık yönetimi kullanılmalıdır. Roots (Bedrock, daha spesifik olarak) bunu yapar. Paket (eklenti veya tema) düzeyinde kullanıldığında, Composer üçüncü taraf kitaplıkları kullanılırken çakışmalara neden olabilir. Bu bilinen bir sorun. Şu ana kadar var olan tek çözüm, bu harici kitaplığın ad alanlarını benzersiz bir şeyle yeniden adlandırmaktır ve bu önemsiz bir görev değildir.

Yine de Composer için bir kullanım var: kendi sınıflarınızın otomatik olarak yüklenmesi. Ancak otomatik yükleme ile daha ileri gitmeden önce, PHP ad alanlarını hızlandırmamız gerekiyor.

Modern PHP En İyi Uygulaması #5: Ad Alanlarını Kullanın

WordPress çekirdeği eski bir proje olduğundan, küresel bir ad alanı kullanır veya başka bir deyişle, hiç ad alanı kullanmaz. Global olarak bildirilen herhangi bir sınıf veya işlev (başka bir sınıf veya işlevin içinde olmadığı anlamına gelir) tüm kod tabanının herhangi bir yerinde görünür. Adları yalnızca kod tabanınız içinde değil, şu anda kullanılan veya gelecekte kullanılabilecek tüm eklentiler ve temalar için benzersiz olmalıdır.

Adlandırma çakışması (örneğin, zaten var olan bir adla bir işlevi bildirmek) genellikle beyaz ölüm ekranına yol açar ve biz bunu istemiyoruz. WordPress Kodeksi, tüm işlevlerinize ve sınıflarınıza benzersiz bir ön ek eklemenizi önerir. Böylece, Order gibi basit sınıf adlarına sahip olmak yerine, Akrte_Awesome_Plugin_Order gibi bir şey elde ederiz; burada "Akrte", yeni oluşturduğum benzersiz önektir.

Ad alanları, kodu düzenlemeye ve ad çakışmasını önlemeye yardımcı olan gruplar veya bir dosya sistemi benzetmesi kullanırsak klasörler olarak görüntülenebilir. Tıpkı iç içe klasörler gibi, eğik çizgiyle ayrılmış karmaşık ad alanlarına sahip olabilirsiniz. (PHP ad alanları özellikle ters eğik çizgi kullanır.)

Bu ad alanı bölümlerine alt ad alanları denir. Örnek sınıfımız Akrte_Awesome_Plugin_Order , ad alanları kullanılarak yapılırsa Akrte\Awesome_Plugin\Order olur. Burada Akrte ve Awesome_Plugin , ad alanı parçalarıdır (veya alt ad alanlarıdır) ve Order , sınıf adıdır. Ardından bir use ifadesi ekleyebilir ve daha sonra yalnızca sınıf adını kullanabilirsiniz. Kesinlikle daha iyi görünüyor:

 use Akrte\Awesome_Plugin\Order; $a = new Order;

Açıkçası, ad alanları benzersiz olmalıdır; bu nedenle, ilk "kök" alt ad alanına benzersiz bir ad vermeliyiz ve bu genellikle bir satıcı adıdır. Örnek olarak, WooCommerce sınıfı WC_REST_Order_Notes_V2_Controller aşağıdaki gibi ad alanlarıyla yeniden yapılabilir:

 namespace WooCommerce\RestApi\V2\Controllers; class OrderNotes {}

WooCommerce kod tabanı günümüzde ad alanlarını kullanıyor; örneğin, WooCommerce REST API sürüm 4'te.

Modern PHP En İyi Uygulaması #6: Otomatik Yükleyici Kullanın

Çoğu PHP iş akışında, PHP dosyalarını birbirine bağlamanın genel yolu, require veya include deyimlerini kullanmaktır. Bir proje büyüdükçe, ana eklenti dosyanızda düzinelerce require ifadesi alırsınız. Bir otomatik yükleyici, dosyaları dahil etmeyi otomatikleştirir ve bunu yalnızca gerektiğinde yapar. Teknik olarak, kodda ilk karşılaşıldığında bir sınıf veya fonksiyon içeren sa dosyası require bir fonksiyondur. Artık herhangi bir require ifadesini manuel olarak eklemenize gerek yoktur.

Bir otomatik yükleyici yalnızca belirli bir istekte kullanılan modülleri yüklediğinden, genellikle önemli bir performans kazancı da vardır. Bir otomatik yükleyici olmadan, bir istek kodunuzun yalnızca yüzde 10'unu kullansa bile tüm kod tabanınız dahil edilir.

Bir otomatik yükleyici işlevi, sınıflarınızın ve işlevlerinizin hangi dosyalarda yaşadığını bilmelidir. Ve bunun için bir PHP-FIG standardı olan PSR-4 var.

Bir ad alanının bir bölümünün, önek, bir temel klasöre karşılık gelecek şekilde atandığını söylüyor. Bunu izleyen alt ad alanları, temel klasör içindeki klasörlere karşılık gelir. Son olarak, sınıf adı dosya adına karşılık gelir. Örnek bir Akrte\AwesomePlugin\Models\Order sınıfı aşağıdaki klasör yapısına ihtiyaç duyar:

 /awesome-plugin awesome-plugin.php /includes /Models Order.php

Akrte\AwesomePlugin\ ad alanı öneki, aşağıda tartışılan otomatik yükleyici yapılandırmasında belirtilen includes klasörüne karşılık gelir. Models alt ad alanı, karşılık gelen bir Models klasörüne sahiptir ve Order sınıfı Order.php içinde bulunur.

Neyse ki, otomatik yükleyici işlevini kendiniz uygulamanıza gerek yok. Besteci sizin için bir otomatik yükleyici oluşturabilir:

Composer'ı Yükle
Projenizin kök klasöründe bir composer.json dosyası oluşturun. Şu satırları içermelidir:

 { "name": "vendor-name/plugin-name", "require": {}, "autoload": { "psr-4": { "Akrte\\AwesomePlugin\\": "includes/" } } }

composer install çalıştırın.
vendor/autoload.php ana eklenti PHP dosyanızın üstüne şu şekilde ekleyin:

 <?php /** * Plugin Name: My Awesome Plugin */ defined('ABSPATH') || exit; require __DIR__ . '/vendor/autoload.php'; // do stuff

Ad alanlarının yanı sıra, WooCommerce'in en son kod tabanı ayrıca bir Besteci otomatik yükleyici kullanır.

Bu PHP tasarım ilkelerini ele alarak, son bir öneriyle tüm PHP derslerimizi WordPress arka uç özelleştirmesine bağlamanın zamanı geldi.

Modern WordPress Geliştirme En İyi Uygulaması #4: Kök Yığınını Kullanmayı Düşünün

Roots, mevcut en kapsamlı modern WordPress geliştirme iş akışıdır. Ancak, her WordPress projesinde mutlaka kullanılmaması gerektiğini söyleyebilirim, çünkü:

Kökler baştan kullanılmalıdır. En yaygın neden, gerçekten. Mevcut bir projeyi yeniden düzenlemek çok maliyetli olacaktır.
Fikir sahibi. Kabul ettiğinizde iyi, olmadığınızda kötü. Örneğin, temanızı düzenlemenin başka yollarını tercih edebilirsiniz. Kamuoyu projeleri ayrıca “kendi yöntemlerini” öğrenmek için zamana ihtiyaç duyar.
Bunu herkes bilmiyor. Roots yığını ile oluşturduğunuz siteyi korumak için sizden sonra gelecek olan geliştirici, bunun ne olduğu hakkında hiçbir fikri olmayabilir ve WordPress klasörlerine ne olduğunu merak edebilir. Diğer WordPress geliştiricilerimizi düşünmeliyiz.

Genel olarak, güçlü bir şekilde düşünülmüş herhangi bir projenin tüm avantajlarını ve dezavantajlarını, onu kullanmaya karar vermeden önce tam olarak anlamak istersiniz.

Modern PHP ve Yazılım İlkeleri: WordPress Arka Uç Geliştirmeyi Sağlam Hale Getirme

Yazılım yazmanın tek bir gerçek yolu olmadığı oldukça açık. Endişelerin ayrılması gibi kavramlar onlarca yıllıktır; ancak pratikte ne anlama geldiği her zaman tartışılmıştır. Örneğin, CSS'yi alın. Başlangıçta, bunu HTML'de style olarak sıraladık, sonra ayrı CSS sayfalarının endişelerin ayrılmasıyla ilgili olduğuna karar verdik.

On yılı hızlı ileri sar: Günümüz JavaScript uygulamaları, bileşenleri bir endişelerin ayrılması uygulaması olarak kullanır. Ön uç geliştiriciler, JS'de CSS'ye yönelirler ve bu temelde CSS'yi tekrar HTML'de satır içine almak anlamına gelir (peki, o kadar basit değil, ama siz anladınız). Çember tamamlandı!

En iyi uygulamalar her zaman geliştirici deneyimini geliştirmekle ilgili olmuştur:

Programlar insanların okuması için ve sadece tesadüfen makinelerin çalışması için yazılmalıdır.
Abelson & Sussman, Bilgisayar Programlarının Yapısı ve Yorumlanması

Bu PHP WordPress eğitimindeki uygulamalardan bazıları hızlı ve projenizde uygulanması kolaydır. Örneğin, otomatik yükleyici: Proje başına bir kez yapın ve keyfini çıkarın. Öte yandan, yeni yazılım mimarisi fikirleri, kullanışlı ve rahat olması için zamana, uygulamaya ve çok sayıda yinelemeye ihtiyaç duyar. Yine de ödüller çok daha büyük. Sadece yaptığınız işte daha verimli olmakla kalmayacak, aynı zamanda yaptığınız şeyden daha çok keyif alacaksınız. Ve müşteriler için yaptığınız işten düzenli olarak keyif almak, sürdürülebilir olmanın belki de tek yoludur.