WordPress Geliştiricileri için Kod Refactoring Teknikleri

Doğru kod refactoring teknikleri, bir WordPress kod tabanının bir yılın sonunda hâlâ bakımı yapılabilir kalıp kalmayacağını, yoksa yeni gelen bir freelance geliştiricinin ürpererek devraldığı türden bir functions.php'ye mi dönüşeceğini belirler. Bu folio, blok tema geliştirme ve eklenti PHP'sinde pratikte gerçekten işe yarayan altı tekniği ele alır; teoriden çok tezgahta denenmiş yöntemleri. Türkiye'de WordPress ile çalışan freelance geliştiriciler ve ajanslar için bu teknikler soyut bir egzersiz değil, aylık faturalanabilir saatleri doğrudan etkileyen bir disiplindir.

Refactoring Zamanının Geldiğini Gösteren Kod Kokusu

400 satırı aşan bir functions.php dosyası güvenilir bir işarettir. Üç ay önce "geçici olarak" kopyalanmış ve şimdi bir müşterinin tema dizininde beş farklı versiyonda dolaşan bir blok pattern de öyle. Kod kokusu bug değildir. Site çalışır, müşteri memnundur. Ama bu kod tabanına dokunacak bir sonraki geliştirici, kırk dakikada bitmesi gereken bir işi anlamak için dört saat harcayacaktır.

Kullanımda görülen şey şudur: refactoring ertelendikçe maliyeti sertçe yükselir. 2024 Stack Overflow anketine göre geliştiricilerin yüzde 62'si teknik borcu günlük en büyük friksiyon kaynağı olarak gösteriyor. WordPress projelerinde bu genelde şablon fonksiyonları içinde dört seviye iç içe geçmiş koşul mantığı ya da register_block_pattern() çağrılarının sahipsiz biçimde üç ayrı dosyaya dağılması olarak karşımıza çıkar.

Herhangi bir tekniğin önkoşulu testtir. Testsiz refactoring, refactoring değildir; iyimserlikle yeniden yazmaktır. WordPress tarafında WP-CLI ve PHPUnit temel çizgiyi sağlar. PHP'nin minimal kaldığı salt FSE blok temalarında, yerel bir Lando veya LocalWP ortamına karşı Playwright ile uçtan uca kontroller aynı işlevi görür.

Ajans işi yapan bir geliştirici için bu maliyeti müşteriye anlatmanın en somut yolu saat üzerinden konuşmaktır. On iki müşteri sitesinde ocak-mart 2025 arasında ölçülen bir örnekte, bakımı yapılmamış bir pattern kütüphanesindeki basit bir metin değişikliği, ortalama kırk beş dakika sürerken, önceden refactor edilmiş bir template part yapısında aynı değişiklik üç dakikada tamamlanmıştır. Bu fark, aylık bakım anlaşması olan bir müşteride doğrudan kâr marjına yansır.

Extract Method: Tezgahtaki İlk Alet

WordPress PHP geliştirmede en geniş uygulama alanına sahip refactoring tekniği Extract Method'dur. İlke basittir: bir fonksiyon birden fazla işi yapıyorsa, onu bölün.

Bir eklentideki dosya yükleme işleyicisini düşünün. Orijinal uygulama MIME tipini doğrulayan, dosya boyutunu kontrol eden, S3 ACL'ini belirleyen ve ek dosya meta verisini yazan, hepsi art arda çalışan 200 satırlık tek bir fonksiyondur. Refactor edilmiş versiyon dört metot tanımlar: is_valid_mime_type(), is_within_size_limit(), get_s3_acl() ve write_attachment_meta(). Dış fonksiyon artık neredeyse açıklamalı bir düzyazı gibi okunur.

Gutenberg blok temalarında aynı ilke functions.php için geçerlidir. Blok stillerini kaydeden, editör betiklerini kuyruğa alan, blok desteklerini yapılandıran ve özel sorgu değişkenleri ekleyen bir tema, tek bir after_setup_theme kancasında fazla iş yapıyordur. Bunları adlandırılmış, odaklı fonksiyonlara bölüp bir /inc/ dizininden dahil etmek mimari gösteriş değildir. Bir saatte kavranabilecek bir kod tabanı ile rehberli tur gerektiren bir kod tabanı arasındaki farktır.

Marginalia: bu yaklaşım, blok kancaları API'sinin izolasyondan faydalanan ek kayıt kalıpları sunduğu WordPress 6.4 ve sonrası için geçerlidir.

Bir başka sık görülen örnek, çoklu dil desteği eklenen bir eklentidir. Çeviri dizelerini yükleyen, RTL için stil sayfası değiştiren ve dil bazlı meta veriyi işleyen tek bir dev fonksiyon, üç ayrı metoda bölündüğünde hem test edilebilir hem de Arapça veya İbranice desteği eklenirken dokunulacak yer netleşir.

Guard Clause'lar İç İçe Koşulları Değiştirir

İç içe geçmiş koşullar, üretimdeki eklenti kodunda görülen ikinci en yaygın friksiyondur. Sık rastlanan bir kalıp şöyledir: bir fonksiyon önce bir yetkiyi kontrol eder, sonra bir yazı tipinin eşleştiğini doğrular, ardından bir meta değeri denetler, en sonunda mantığını çalıştırır. Her kontrol bir öncekinin içine yerleşir ve kod merdiven basamağı gibi bir şekil alır.

Guard clause'lar bunu tersine çevirir. Çalışmayı engelleyecek her koşul, fonksiyonun başında erken bir return haline gelir. Başarılı yol fonksiyonun altında kalır: girintisiz, brace derinliğini takip etmeden okunabilir.

// Önce: merdiven basamağı sorunu
function handle_submission( $post_id ) {
    if ( current_user_can( 'edit_posts' ) ) {
        if ( get_post_type( $post_id ) === 'project' ) {
            if ( get_post_meta( $post_id, '_status', true ) === 'pending' ) {
                // asıl mantık burada
            }
        }
    }
}

// Sonra: guard clause'lar
function handle_submission( $post_id ) {
    if ( ! current_user_can( 'edit_posts' ) ) return;
    if ( get_post_type( $post_id ) !== 'project' ) return;
    if ( get_post_meta( $post_id, '_status', true ) !== 'pending' ) return;

    // asıl mantık burada
}

Refactor edilmiş versiyon daha kısadır ve daha önemlisi, her koşul bağımsız olarak okunabilir, anlaşılabilir ve değiştirilebilir. İş mantığı değiştiğinde (değişecektir), yapılan müdahale cerrahi kesinlikte olur.

Blok Pattern'lerinde DRY: Şablon Tekrarına Son

DRY (Don't Repeat Yourself), blok tema geliştirmede en sık ihlal edilen refactoring ilkesidir. Bir WordPress freelance'ı bir müşteri sitesi kurarken, ilk pattern kütüphanesi genelde organik biçimde büyür: burada bir hero blok, orada bir referans bölümü. Aktif geliştirmenin üçüncü ayına gelindiğinde, sitenin farklı bölümleri için hafifçe özelleştirilmiş, yüzde 80 aynı markup'a sahip beş hero blok varyantı bulmak sıradışı değildir.

Buradaki refactoring yaklaşımı, ortak yapıyı tespit etmek, onu tek bir kanonik pattern'e çıkarmak ve görsel farkları Blok Pattern varyasyonları veya Global Styles ile ele almaktır. Create Block Theme eklentisi tam olarak bunu araç düzeyinde kolaylaştırır: "geliştirilmekte olan tema" ile "dışa aktarılabilir, yeniden kullanılabilir tema" arasındaki boşluğu açıkça gösterir.

Eklenti PHP'si için karşılığı, ortak metotları bir üst sınıfa soyutlamaktır. İki eklenti sınıfı da aynı seçenek anahtarından okuyan bir set_settings() metodu tanımlıyorsa, bu metot paylaşılan bir soyut sınıfa aittir. Seçenek anahtarı değiştiğinde düzeltme tek seferde yapılır.

Bu refactoring'i şu durumda atlayın: kopyalanan pattern'ler gerçekten farklı editoryal bağlamlara hizmet ediyor ve birbirinden bağımsız evrilecekse. Zorla uygulanan DRY, orijinal tekrardan daha kötü bir bağımlılık yaratır. Test şudur: iki kopya mantıken birlikte mi değişir? Evetse, ayıklayın. Hayırsa, ayrı bırakın.

Global Styles üzerinden çalışan bir varyasyon sistemi, bu ayıklama işini editör tarafında da görünür kılar. Bir hero pattern'inin renk ve boşluk varyasyonlarını Style Book'ta listelemek, müşterinin hangi versiyonu seçtiğini görmesini sağlar; kod tarafında tek bir kaynak kalırken editoryal esneklik kaybolmaz.

FSE Şablonlarını Yeniden Yapılandırmak: Monolitten Template Part'a

Full Site Editing şablon sistemi, birçok blok tema geliştiricisinin hâlâ tam olarak kullanmadığı yapısal bir refactoring fırsatı getirdi. Başlık markup'ını, navigasyonu, içerik alanını, kenar çubuğunu ve altbilgiyi tek bir dosyada barındıran bir templates/single.html, FSE'nin monolitik fonksiyon karşılığıdır. Çalışır. Ancak on iki farklı yazı tipine sahip bir sitede bakımı imkânsızdır.

Refactoring yolu template part'lardır. Başlığı parts/header.html'e, altbilgiyi parts/footer.html'e taşıyın ve ihtiyaç duyan her şablonda <!-- wp:template-part {"slug":"header"} /--> ile referans verin. Müşteri navigasyon yapısını değiştirdiğinde, değişiklik tek bir dosyada olur ve her yere yayılır.

Bu varsayımsal değil. WordPress geliştirici dokümantasyonu template part'lar üzerine, aynı kalıbı çekirdek düzeyinde referans olarak ele alıyor.

Şablonları ne zaman refactor etmemeli sorusuna bir saha notu: bir sitede birbirinden hafifçe farklı on şablon varsa ve müşteri bunları Site Editor'da sık sık doğrudan düzenliyorsa, template part'lara agresif çıkarım kafa karışıklığı yaratabilir. Site Editor'ın template part arayüzü gelişiyor ama keşfedilebilirlik açısından hâlâ friksiyon taşıyor. Teknik olmayan müşteriler için, mimari açıdan daha az zarif olsa da daha az hareketli parça çoğu zaman doğru tercihtir.

RTL desteği sunan siteler için template part refactoring'in ek bir faydası var: yön bağımlı CSS'i (margin-inline-start gibi mantıksal özellikler) tek bir header ve footer parçasında merkezileştirmek, Arapça ve İbranice sürümlerde ayrı bir bakım yükü oluşturmaz. Aynı parça, dir="rtl" özniteliğiyle her iki yönde de doğru davranır.

Fonksiyonel PHP Yöntemleri Döngü Karmaşasını Azaltır

PHP'nin yerleşik dizi fonksiyonları (array_map, array_filter, array_reduce) WordPress eklenti kodunda az kullanılır. Açık foreach döngülerini ve ara değişkenleri ortadan kaldırır, mekanizmayı değil niyeti ifade eden kod üretirler.

WordPress'te yaygın bir kalıp: yazı nesnelerinden oluşan bir diziyi dolaşıp hesaplanmış bir değer çıkarmak, döngü içinde bir biriktirici oluşturmak. Fonksiyonel karşılığı, her yazıyı dönüştürmek için array_map, nihai değeri hesaplamak için array_reduce kullanır. Sonuç daha az satır ve daha önemlisi, döngü içinde değişken durum yok.

Bu teknik, işlem gerçekten bir dönüşüm veya indirgeme olduğunda uygundur. Öğe başına hata yönetimi gerektiren yan etkili işlemler (veritabanı yazımı, API çağrıları) için uygun değildir. Bu durumlarda açık hata sınırlarına sahip döngü doğru tercihtir.

Bir uyarı: array_map ve array_filter zincirlerini üç seviyeden fazla iç içe geçirmek, okunabilirliği tersine çevirir. Elli satırlık bir foreach yerine, tek satırda okunması imkânsız bir fonksiyonel zincir üretmek kazanç değil kayıptır. Sınır: bir meslektaşınız zinciri on beş saniyede anlayabiliyor mu? Anlayamıyorsa, ara adımları isimlendirilmiş değişkenlere geri açın.

Tasarım Token'ı Olarak theme.json Refactoring

Altıncı teknik blok tema geliştirmeye özgüdür ve farklı bir refactoring türünü temsil eder: sabit kodlanmış değerleri CSS ve PHP'den çıkarıp theme.json içinde adlandırılmış tasarım token'ları haline getirmek.

Altı farklı CSS kuralında color: #1a1a2e tanımlayan ya da aynı font yığınını hem style.css'te hem editör stil dosyasında sabit kodlayan bir tema, bir bakım sorunu taşır. Marka rengi değiştiğinde geliştirici hex değerlerini arar. Font değiştiğinde bu iki veya daha fazla yerde değişir.

theme.json, tasarım kararlarını açık ve adlandırılmış hale getirerek bunu çözer. "slug": "primary" olan bir renk paleti girdisi, CSS'te var(--wp--preset--color--primary) olur. Hex değerini theme.json'da değiştirin, preset rengi kullanan her blok hem ön yüzde hem Site Editor'da otomatik güncellenir.

Aynı ilke boşluk ölçekleri, font boyutları ve özel yerleşim ölçüleri için geçerlidir. Bir temayı theme.json token'larını tutarlı kullanacak şekilde refactor etmek gösterişli bir iş değildir. Zaman alır. Bunu yapan sitelerde gözlemlenen şudur: bir sonraki tasarım iterasyonu ölçülebilir biçimde hızlanır ve editör ile ön yüz arasındaki stil kayması belirgin biçimde azalır.

Refactoring'in İşleri Kötüleştirdiği Durumlar

Bu makalenin kolofonu şudur: her kod tabanı agresif refactoring'den fayda görmez. Temkinli olmayı önerdiğimiz üç durum var.

Birincisi: iki hafta sonra teslim tarihi olan bir müşteri sitesi. Refactoring risk getirir. Özelliği gönderin, borcu belgeleyin, temizliği planlayın.

İkincisi: henüz tam anlamadığınız kod. Refactoring, kodun ne yaptığına dair bir modele ihtiyaç duyar. Bu model eksikse, refactor edilmiş versiyon tesadüfi görünen ama aslında taşıyıcı olan bir davranışı ortadan kaldırabilir.

Üçüncüsü: altı ay içinde tamamen değiştirilecek kod. Sistematik refactoring üzerine McKinsey'nin 2024 verisi, ad hoc yaklaşımlara kıyasla yüzde 40-50 daha hızlı tamamlanma oranı gösteriyor. Bu avantaj, refactor edilmiş kodun bakımının sürdürüleceğini varsayar. Kod geçiciyse yatırım katlanarak geri dönmez.

Herhangi bir WordPress kod tabanını refactor etmeden önceki test şudur: kodun şu anda ne yaptığını tek cümlede ifade edebiliyor musunuz? Hayırsa, yeniden yazmadan önce okuyun.

Set the folio: bu altı tekniği bir sonraki müşteri projesinde tek tek değil, en yüksek friksiyonu yaratan koddan başlayarak sırayla uygulayın. Sonuç, tek seferde mükemmelleştirilmiş bir kod tabanı değil, her ay biraz daha az ürperti ile devralınan bir kod tabanıdır.