Türkiye'deki kurumsal sistemlerin önemli bir kısmı hâlâ PHP 5.6 veya 7.x üzerinde koşuyor. Çalışıyor, evet; ama güvenlik yaması almayan bir sürümde çalışmak, sigortasız araba kullanmak gibidir. PHP 8.5'in yayında olduğu bugünlerde, 16 yılda onlarca yükseltme projesi yürütmüş bir ekip olarak güvenli modernizasyonun yol haritasını paylaşıyoruz: neden değer, hangi adımlarla ilerlenir, nerede sürpriz çıkar ve maliyet nasıl öngörülür.
Neden yükseltmeye değer?
Mesele sadece güvenlik değil. PHP 7.0'dan bu yana her sürüm somut performans kazandırdı; 5.6'dan 8.x'e geçen projelerimizde aynı donanımda iki-üç kat hız artışı ölçtük. Dil tarafında da kazanımlar birikti: tip bildirimleri ve enum'lar hata sınıflarını derleme benzeri aşamada yakalıyor, match ifadeleri ve constructor promotion kodu sadeleştiriyor, 8.5 ile gelen pipe operatörü (|>) zincirleme dönüşümleri okunur kılıyor. Daha az kod, daha erken yakalanan hata, daha ucuz bakım.
Güvenli geçişin adımları
- Envanter: Hangi PHP sürümündesiniz, hangi eklentiler kullanılıyor, composer bağımlılıkları hedef sürümü destekliyor mu? php -m çıktısı ve composer.json ilk bakılacak yerlerdir.
- Statik analiz: PHPStan'ı mevcut kod üzerinde çalıştırıp fotoğraf çekin. Baseline özelliğiyle mevcut hataları dondurup yeni hata girişini engelleyin.
- Otomatik dönüşüm: Rector, sürüm geçişlerindeki mekanik değişikliklerin büyük kısmını otomatikleştirir; elle günler süren iş saatlere iner.
- Test ağı: Kritik akışlar için en azından smoke test seviyesinde otomasyon olmadan yükseltmeye çıkmayın. Test yoksa önce karakterizasyon testleri yazılır.
- Kademeli geçiş: Önce staging'de tüm akışlar, sonra üretimde kanarya yaklaşımı: trafiğin küçük bir yüzdesi yeni sürüme, sorun yoksa tamamı.
Maliyet ve süre nasıl öngörülür?
Yöneticilerin haklı sorusu: "Bu iş kaça, kaç ayda biter?" Dürüst cevap, envanter çıkmadan kimsenin sağlıklı rakam veremeyeceğidir; ama yıllar içinde oturttuğumuz kaba bir çerçeve var. Süreyi belirleyen üç değişken: kod tabanının büyüklüğünden çok yaşı ve test kapsamı, kullanılan terk edilmiş paket sayısı ve ekibin sisteme hakimiyeti. Testsiz, 10 yaşında, framework'süz bir kod tabanında 5.6'dan 8.x'e geçiş aylar mertebesinde bir projedir; testli ve görece derli toplu bir Laravel projesinde büyük sürüm atlamak haftalarla ölçülür. Bütçelerken iki kalemi unutmayın: geçiş sonrası en az bir aylık yoğun izleme dönemi ve bu süreçte özellik geliştirmenin yavaşlayacağı gerçeği. Bu ikisini baştan konuşan projelerde sürpriz yaşanmıyor.
Sahadan uyarılar
En çok sürpriz çıkaran yerler bellidir: eski mysql_* fonksiyonları (8.x'te tamamen yok, PDO'ya geçiş şart), her yerde örtük tip dönüşümüne yaslanan kod, artık hata fırlatan eski sessiz davranışlar ve terk edilmiş composer paketleri. Bir de işin insan tarafı var: yükseltmeyi "boş bir sprintte yaparız" diye planlamayın; olmaz. Ayrı bir proje olarak bütçelenmeli, sorumlusu ve bitiş tarihi olmalı.
Sonuç
Legacy PHP sistemi olan her kurumun önünde iki yol var: kontrollü, planlı bir modernizasyon ya da bir gün mecburen, panik içinde yapılacak acil geçiş. İlki her zaman daha ucuzdur. Rich Design olarak 2010'dan beri PHP ile kurumsal sistemler geliştiriyor, legacy projelerin analiz, yükseltme ve yeniden yapılandırma süreçlerini üretimi durdurmadan yönetiyoruz. Sisteminizin yükseltme haritasını çıkarmak için bizimle iletişime geçin.