PHP geliştiricisi — 2008'den beri

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.

01 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.

02 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.

03 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.

04 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.

01 Ö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.

02 Sonra test yüzeyini genişletmek

Değişikliğe dokunmadan önce koruma kurmak; sonrasında yapılan her düzeltmenin bedeli düşüyor.

03 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.