# PHP geliştiricisi — 2008'den beri

> 2008'den beri PHP geliştiricisiyim: Laravel, Symfony ve CodeIgniter ile üretime çıkan işler, framework'süz kütüphaneler ve framework kararı.

- Teknolojiler: Laravel, Symfony, CodeIgniter, Composer, PHPUnit, Pest, Redis, MySQL, RabbitMQ
- Deneyim: 2008'den bu yana
- Yazı: 88
- Proje: 5
- Güncelleme: 2026-09-02
- Kaynak: https://www.muhammetsafak.com.tr/uzmanlik/php/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
## PHP ekosisteminde ben

PHP geliştiricisi olarak işimin merkezinde tek bir soru duruyor: iş kuralı
nerede yaşayacak? Framework seçimi, dizin düzeni ve test yüzeyi bu sorunun
cevabından sonra geliyor. Ters sırayla kurulan projelerde kural uygulamanın her
yerine dağılıyor ve bakım maliyeti tam orada başlıyor.

Aşağıdakiler uygulama seviyesinde ne yaptığım ve kararları neye göre verdiğim.
Mikroservis sınırları, event-driven tasarımın kendisi ve veritabanı iç mekaniği
gibi konuları maliyetleriyle birlikte [sade.dev](https://sade.dev) tarafında
yazıyorum.

### PHP tarafında ne geliştiriyorum

Ortak noktaları tanıtım sitesi olmamaları; PHP'yi iş kuralının yaşadığı yerde kullanıyorum.

- **Fatura ve ödeme akışları** — Para akışına dokunan, iş kuralını uygulamanın içinde taşıyan sistemler.
- **Asenkron arka plan işleri** — Kuyruk, consumer ve idempotent tüketim; senkron beklemeyi kullanıcının önünden alan yapılar.
- **Framework'lü kurulumlar** — Laravel, Symfony ve CodeIgniter; sıfırdan kurduğum işlerde de devraldığım kod tabanlarında da. Üçü de aynı dilin üstünde duruyor; uygulama seviyesinde asıl işi yapan şey framework değil, iş kuralını nereye koyduğunuz.
- **Framework'süz kütüphaneler** — Tek başına çalışabilen, MIT lisanslı paketler; router'dan PSR-11 container'a kadar. Bir kütüphaneyi başkasının projesine soktuğunuzda geri alınamayan tek şey imzadır.

### Framework kararını nasıl veriyorum

Yeni bir işe girerken önce framework seçmiyorum; sırayı belirleyen şey de benim tercihim değil.

1. **Senkron mu, asenkron mu** — Bu karar kuyruğu, hata sözleşmesini ve aynı istek iki kez geldiğinde ne olacağını birlikte belirliyor; sonradan değiştirmesi en pahalı karar bu ve framework'ten önce geliyor.
2. **Ekipteki geliştiricilerin bildiği araç** — Ekipte Symfony bilen yoksa o ürünü Symfony ile yazmak, kazandırdığından fazlasını götürür.
3. **MVP'ye verilen süre ve ürünün kendi ihtiyacı** — Teslim tarihi ve ürünün kendine özgü ihtiyacı, bir framework'ün hazır getirdiklerinin ne kadarını gerçekten kullanacağımı belirliyor.
4. **Performans, en sonda** — Bu kararın en zayıf gerekçesi. Ölçtüğümde framework'ler arasındaki fark, istek gerçek iş yapmaya başlar başlamaz kapanıyor.

### Devraldığım bir kod tabanında sıra

İşlerin bir kısmı sıfırdan kurulmuyor, devralınıyor; devralınan kodda ilk iş yeniden yazmak değil.

1. **Önce davranışı anlamak** — Hangi kural nerede duruyor, hangi yan etki hangi isteğe bağlı, testin koruduğu yüzey nereye kadar uzanıyor. Bunlar netleşmeden yapılan iyileştirme, çalışan bir sistemi görünmez biçimde bozma riskidir.
2. **Sonra test yüzeyini genişletmek** — Değişikliğe dokunmadan önce koruma kurmak; sonrasında yapılan her düzeltmenin bedeli düşüyor.
3. **En son sürüm ve bağımlılık temizliği** — İşin sıradan parçası ama aynı ölçüye bağlı: değişikliğin bedeli, getirdiği rahatlıktan küçük olmalı.

### Testi hangi üç yüzeyde kuruyorum

Test benim için kalite rozeti değil, değişikliğin maliyetini düşüren araç; o yüzden baştan bir yüzey olarak kuruluyor.

- **İş kuralının doğrudan sınandığı yer** — Kuralın kendisi, dış dünyaya hiç çıkmadan sınanıyor. Testi olmayan bir kural, ilk yoğun günde sessizce değişebilecek bir kuraldır.
- **Dış sınırın taklit edildiği yer** — Ödeme sağlayıcısı, kuyruk, üçüncü taraf servis; sınırın karşı tarafı taklit ediliyor ki test kendi başına koşabilsin.
- **Akışın uçtan uca yürütüldüğü yer** — İsteğin girip sonucun çıktığı yol. Parçalar tek tek doğruyken birleşimin yanlış olduğu durumu yalnız burası görüyor.

### Mimariyi burada anlatmıyorum

Mikroservis sınırları, event-driven tasarımın kendisi, veritabanı iç mekaniği ve cache stratejisi gibi konuları bu sayfada kendi başlarına ele almıyorum; onları yazdığım yer sade.dev.

## Sık sorulanlar

### PHP ile kaç yıldır çalışıyorsun?

2008'den bu yana, 18 yıldır. Bu sürenin 88 yazılık kısmı bu sitede kayıtlı.

### Hangi PHP framework'lerini kullanıyorsun?

Derinliğim Laravel'de: ilk projeme Laravel 4 ile başladım, blog arşivinde 5'ten 12'ye kadar ayrı geçiş notları var. Ama tek framework'üm Laravel değil — Symfony ve CodeIgniter'ı hem sıfırdan kurduğum işlerde hem devraldığım kod tabanlarında kullandım.

### Framework kullanmadan PHP yazıyor musun?

Evet. Tek başına çalışabilen paketleri, router'dan PSR-11 container'a kadar, framework'e yaslanmadan yazdım; hepsi MIT lisansıyla Packagist'te. Framework'e yaslanmadan PHP yazmak, framework'ün sizin yerinize ne yaptığını öğrenmenin de en kısa yolu.

### Bir proje için PHP framework'ünü neye göre seçiyorsun?

Üç parametre belirliyor: MVP'ye verilen süre, ekipteki geliştiricilerin bildiği araç ve ürünün kendine özgü ihtiyacı. Performans genelde bu kararın en zayıf gerekçesi — ölçtüğümde framework'ler arasındaki fark, istek gerçek iş yapmaya başlar başlamaz kapanıyor.

### Yeni bir PHP projesine nasıl başlıyorsun?

Framework seçerek değil. Önce işin senkron mu asenkron mu yürüyeceğine karar veriyorum. Bu karar kuyruğu, hata sözleşmesini ve idempotency ihtiyacını birlikte belirlediği için sonradan değiştirmesi en pahalı karar o.

### Mimari tasarım da yapıyor musun?

Evet, ama o tarafı burada anlatmıyorum. Bu sayfa uygulama seviyesinde ne yaptığımı gösterir; mimari kararların kendisini maliyetleriyle birlikte sade.dev'de yazıyorum.

### Kaç projede PHP kullandın?

Bu sitede kayıtlı projelerin 5 tanesi PHP tarafına dokunuyor; freelance dönemde teslim ettiğim işlerin çoğu portfolyoda değil.