# WordPress Geliştiricileri için Kod Refactoring Teknikleri URL: https://noonwp.com/tr/journal/kod-refactoring-teknikleri-wordpress Type: blog Locale: tr Published: 2026-06-29 Updated: 2026-07-04 --- > WordPress geliştiricileri için pratik kod refactoring teknikleri: extract method, guard clause, DRY prensibi ve FSE pattern temizliği, gerçek üretim kısıtlarıyla birlikte ele alınır. 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. ![PHP kodunun dizüstü bilgisayar ekranında düzenli fonksiyon yapısıyla görünümü](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-06/54ffc6-inline1.webp) ## 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. ![Yapışkan notlar panosunda modüler kod mimarisi planlayan bir geliştirici](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-06/406483-inline2.webp) ## 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](https://wordpress.org/plugins/create-block-theme/) 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 `` 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](https://developer.wordpress.org/themes/templates/template-parts/), 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. ![Kod refactoring sonrası otomatik test sonuçlarını ekranda inceleyen bir geliştirici](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-06/5ef3dc-inline3.webp) ## 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. ## FAQ ### WordPress geliştirmede kod refactoring nedir? Kod refactoring, mevcut PHP fonksiyonlarının, blok pattern'lerinin veya FSE şablonlarının davranışını değiştirmeden okunabilirliğini ve bakım kolaylığını artıracak şekilde yeniden yapılandırılmasıdır. Yeni özellik eklemek veya bug düzeltmek değildir. Amaç, projenin yaşam döngüsü boyunca bakımı daha kolay olan bir yapı elde etmektir. ### functions.php dosyasını ne zaman refactor etmeliyim? functions.php 200-300 satırı geçtiğinde refactor zamanı gelmiştir. Önerilen yaklaşım, dosyayı bir /inc/ dizininde tek bir konuya odaklanan ayrı dosyalara bölmektir: blok stil kaydı, editör betikleri, blok destekleri, özel yazı tipleri. Bunları functions.php'den include edin. Sonuç, gezinmesi ve test edilmesi daha kolay bir yapıdır. ### Extract Method refactoring tekniği nasıl uygulanır? Extract Method, birden fazla iş yapan bir fonksiyonu, her biri tek bir işi yapan daha küçük, adlandırılmış fonksiyonlara bölmek demektir. WordPress PHP'sinde yaygın örnek, girdiyi doğrulayan, veriyi işleyen ve veritabanına yazan büyük bir eklenti fonksiyonunu üç ayrı, adlandırılmış metoda ayırmaktır. Her metot bağımsız olarak okunabilir ve test edilebilir hale gelir. ### PHP'de guard clause nedir? Guard clause'lar, çalışmayı engelleyecek koşulları ele almak için fonksiyonun başına yerleştirilen erken return ifadeleridir. Mantığı if-else blokları içinde iç içe geçirmek yerine, bir koşul karşılanmadığında erken çıkış yaparsınız. Bu, WordPress eklenti kodunda yaygın olan iç içe merdiven kalıbını ortadan kaldırır ve başarılı çalışma yolunu okumayı kolaylaştırır. ### theme.json kod refactoring'e nasıl yardımcı olur? theme.json, tasarım token'larını (renkler, font boyutları, boşluklar) bir kez ve adlandırılmış olarak tanımlamanızı sağlar. CSS ve blok markup'ı bu token'lara CSS özel özellikleri üzerinden referans verir. Bir tasarım değeri değiştiğinde, güncellemeyi theme.json içinde tek bir yerde yaparsınız. Bu, birden fazla CSS dosyasına dağılmış sabit hex değerlerini ortadan kaldırır. ### WordPress kodunu ne zaman refactor ETMEMELİ? Üç durumda temkinli olun: teslim tarihine yakınken (refactoring risk getirir), kodun ne yaptığına dair net bir modeliniz yokken (yeniden yazmadan önce okuyun) ve kodun altı ay içinde tamamen değiştirileceğini bildiğinizde. Bu durumlarda refactoring yatırımı zaman içinde katlanarak geri dönmez, çünkü kod ya geçicidir ya da yeterince anlaşılmamıştır.