Laravel proje devralma: miras kalan uygulamada ilk 30 gün

Bir Laravel projesini devraldığınızda ilk 30 günün amacı yeni özellik yazmak değil, sistemi anlamak ve kontrol altına almaktır. Sıra şöyle: erişimleri toplayın, uygulamayı yerelde çalıştırın, yedeklerin geri yüklendiğini kanıtlayın, bağımlılık ve PHP sürümlerini denetleyin, en kritik akışlara test ekleyin, izlemeyi kurun ve bir risk haritası çıkarın. Baştan yazma kararını, ancak bunlardan sonra ve büyük ihtimalle hiç vermeyin.

İlk hafta: erişim ve envanter

Devralınan projelerde en sık görülen sorun teknik değil, idari: kritik erişimler eski geliştiricinin kişisel hesabında. Kod yazmadan önce envanteri çıkarın ve her kalemin sahibinin şirket olduğundan emin olun.

• Kaynak kod: Repo hangi hesapta? Şirketin organizasyonuna taşındı mı? Tüm dallar ve etiketler orada mı?
• Sunucu ve barındırma: Sunucu, bulut hesabı ya da paylaşımlı hosting paneli kimin adına?
• Alan adı ve DNS: Kayıt şirketindeki hesap ve DNS yönetimi kimde?
• Veritabanı: Canlı veritabanına kim, hangi kullanıcıyla erişiyor?
• Üçüncü taraf servisler: E-posta gönderimi, ödeme, SMS, depolama, e-Fatura entegratörü gibi servislerin hesapları ve API anahtarları.
• Sırlar: Canlıdaki .env dosyası nerede, kopyası güvenli bir yerde duruyor mu?
• Zamanlanmış işler ve kuyruklar: Sunucuda hangi cron satırları ve hangi kuyruk işçileri çalışıyor?
• Dokümantasyon ve bilgi: README, wiki, eski iş takip kayıtları ve — mümkünse — eski geliştiriciyle bir devir görüşmesi.

Eski geliştiriciyle hâlâ iletişim varsa bu haftayı iyi kullanın. Bir saatlik bir görüşmede "en çok neyin bozulmasından korkardın?" sorusunun cevabı, haftalarca kod okumaktan daha değerli olabilir.

Uygulamayı yerelde ayağa kaldırmak ve yedekleri kanıtlamak

Yerel kurulum

Uygulamayı kendi makinenizde ya da bir container ortamında çalıştıramıyorsanız, ona güvenle dokunamazsınız. Bu adım çoğu zaman beklenenden uzun sürer, çünkü eksik bir PHP eklentisi, belgelenmemiş bir ortam değişkeni ya da sadece canlıda var olan bir dosya çıkar. Bulduğunuz her şeyi not edin; bu notlar projenin ilk gerçek kurulum belgesi olacak.

Yerel ortam için canlı veritabanının kopyasını kullanacaksanız, kişisel verileri anonimleştirmeden geliştirici makinelerine taşımayın. Müşteri, çalışan ya da aday verisi içeren bir veritabanı için bu bir tercih değil, KVKK açısından da dikkat edilmesi gereken bir konu.

Yedekler

"Yedek alınıyor" cümlesi, yedekten geri yükleme yapılmadıkça bir varsayımdır. İlk iki hafta içinde şunu yapın: canlı veritabanının ve storage klasörünün yedeğini alın, ayrı bir ortama geri yükleyin ve uygulamanın o yedekle açıldığını görün. Yüklenen dosyalar, faturalar, belgeler genellikle veritabanında değil diskte durur ve unutulan yedek tam da odur.

Kod tabanını okumak: nereden başlanır

Binlerce dosyalık bir projeyi baştan sona okumaya çalışmak yerine, uygulamanın dış yüzünden içeri doğru ilerleyin. Laravel'de bunun için iyi giriş noktaları var:

• Rotalar. php artisan route:list uygulamanın dışarıya açtığı her adresi gösterir. Hangi alanların aktif kullanıldığını, hangilerinin unutulmuş olabileceğini buradan görürsünüz.
• Modeller ve migration'lar. Veritabanı şeması, iş alanının en dürüst özetidir. Tablo adları ve ilişkiler, kimsenin yazmadığı iş kurallarını ele verir.
• Zamanlanmış işler ve job'lar. Gece çalışan bir rapor ya da saatlik bir senkronizasyon, gündüz kimsenin görmediği ama bozulduğunda herkesin fark ettiği işlerdir.
• Servis sağlayıcılar ve config. Uygulamanın hangi dış servislere bağlandığı ve hangi ayarların ortama göre değiştiği burada durur.
• Git geçmişi. En sık değişen dosyalar genellikle en çok sorun çıkaran ya da en çok iş kuralı taşıyan dosyalardır.

Okurken bulduklarınızı kısa notlar olarak yazın. Bir ay sonra bu notlar, ekibe katılacak bir sonraki kişinin başlangıç belgesi olur.

Bağımlılık ve PHP sürüm denetimi

Envanterin teknik yarısı bağımlılıklar. Şunlara bakın:

• Laravel sürümü ve hâlâ güvenlik güncellemesi alıp almadığı. Laravel'in destek tablosu resmi sürüm notlarında yayımlanıyor.
• PHP sürümü, hem web sunucusunda hem komut satırında. İkisinin farklı olması, cron'da çalışan işlerin sessizce başarısız olmasının klasik sebebi.
• Composer paketleri. composer outdated geride kalan paketleri, composer audit bilinen güvenlik açıklarını listeler. Bakımı bırakılmış, son güncellemesi yıllar önce yapılmış paketleri ayrıca işaretleyin.
• Ön yüz bağımlılıkları. Varsa npm paketleri ve derleme zinciri; eski bir Node sürümüne bağımlı bir derleme, deploy'u kilitleyebilir.
• Çekirdeğe yapılan müdahaleler. vendor klasöründe elle değiştirilmiş dosyalar, bir sonraki composer install ile kaybolacak değişiklikler demektir.

Bu denetimin çıktısı bir yapılacaklar listesi değil, bir risk listesi olmalı: hangi bağımlılık bugün güvenlik açığı taşıyor, hangisi bir yükseltmeyi engelliyor, hangisi sadece eski.

Testler: önce güvenlik ağı

Devralınan Laravel projelerinin çoğunda ya hiç test yok ya da yıllardır çalıştırılmamış birkaç test var. İlk iş, mevcut testleri çalıştırıp durumlarını görmek. İkinci iş, iyileştirmek için değil, bugünkü davranışı kayda geçirmek için test yazmak.

Kodu değiştirmeden önce "şu an ne yapıyor"u tespit eden bu testlere karakterizasyon testi denir. Mükemmel olmaları gerekmez; en kritik akışları kapsamaları yeter:

1. Giriş ve yetkilendirme: kim neyi görebiliyor?
2. Para ya da belge üreten akışlar: sipariş, ödeme, fatura, rapor.
3. Dışarıyla konuşan entegrasyonlar: bir API çağrısı, bir webhook, bir e-posta.
4. Zamanlanmış işler: her gece çalışan ve sessizce bozulabilen işler.

Bu birkaç test, sonraki her değişikliğin — bir paket güncellemesinin, bir yeniden düzenlemenin — bir şeyi bozup bozmadığını size söyler.

İzleme ve hızlı güvenlik kazanımları

Loglama ve izleme

Bir hata olduğunda bunu müşterinizden değil, sistemden duymalısınız. Uygulama loglarının nereye yazıldığına, döndürülüp döndürülmediğine ve birinin onlara bakıp bakmadığına bakın. Bir hata izleme aracı ve basit bir erişilebilirlik kontrolü, ilk ayın en ucuz yatırımlarından biridir. Kuyruk kullanılıyorsa başarısız job'ların nereye düştüğünü ve birinin bunu fark edip etmediğini de kontrol edin.

Hızlı güvenlik adımları

Bazı düzeltmeler küçük ama etkisi büyük:

• Canlıda APP_DEBUG kapalı olmalı; açıksa hata sayfaları ortam bilgilerini sızdırabilir.
• .env dosyasının web üzerinden erişilemediğini, sunucunun kök dizininin public klasörü olduğunu doğrulayın.
• Eski geliştiricinin kullandığı veritabanı, sunucu ve servis şifrelerini değiştirin; API anahtarlarını yenileyin.
• Uygulamadaki yönetici hesaplarını gözden geçirin; artık şirkette olmayan kişilerin hesaplarını kapatın.
• composer audit çıktısındaki kritik açıkları kapatın; bunu yaparken yedek ve testlerin hazır olduğundan emin olun.

Risk haritası

İlk ayın sonunda elinizde, yönetime de gösterebileceğiniz tek sayfalık bir risk haritası olmalı. Basit bir tablo yeter:

Tablodaki satırlar örnek; kendi bulgularınızla doldurun. Önemli olan, her riskin bir sahibi ve bir tarihi olması. Bu harita, "neden yeni özellik gelmiyor?" sorusuna verilecek en iyi cevaptır.

Neden baştan yazmamalı

Eski bir kod tabanını okumak yorucudur ve "bunu baştan yazsak daha hızlı olur" düşüncesi neredeyse her devirde gelir. Çoğu zaman yanıltıcıdır:

• Çalışan kod, kimsenin yazıya dökmediği iş kurallarını içerir. Baştan yazım, bu kuralları kullanıcılar şikâyet ettikçe tek tek yeniden keşfetmek demektir.
• Yeniden yazım sürerken eski sistem de yaşamaya devam eder; iki sistemi aynı anda taşırsınız.
• Yeni sistem eskisinin yaptığı her şeyi yapana kadar iş birimi için değer üretmez.

Daha güvenli yol kademeli iyileştirmedir: testlerle güvenlik ağı kurun, en çok acıtan parçayı izole edin, onu düzeltin ya da değiştirin, sonra bir sonrakine geçin. Baştan yazımın gerçekten doğru olduğu durumlar da var — kullanılan teknolojinin artık hiç desteklenmemesi ya da iş modelinin tamamen değişmesi gibi — ama bu karar ilk ayın değil, risk haritasının ardından verilecek bir karardır. O noktaya gelinirse, yeni sistemi kapsamı ve kabul kriterleri yazılı bir özel yazılım geliştirme projesi olarak ele almak, açık uçlu bir yeniden yazımdan çok daha kontrollüdür.

Nereden başlamalı?

İlk 30 günü kabaca şöyle bölebilirsiniz:

1. 1. hafta: Erişimleri ve envanteri şirkete toplayın, sırları değiştirin.
2. 2. hafta: Yerel kurulumu çalıştırın, yedekten geri yüklemeyi kanıtlayın.
3. 3. hafta: Bağımlılık ve sürüm denetimini yapın, kritik akışlara ilk testleri ekleyin.
4. 4. hafta: İzlemeyi kurun, hızlı güvenlik adımlarını tamamlayın, risk haritasını yazın.

Bu işi içeride yapacak kıdemli bir Laravel geliştiriciniz yoksa, önce Laravel geliştiricisini işe almak mı ekip takviyesi mi sorusunu netleştirmek iyi bir başlangıç. Devraldığınız kod tabanına kimse dokunmak istemiyorsa, yazılım ekibi kiralama hizmetimizle bu ilk ayı sizin repo'nuzda ve ekibinizle birlikte yürütebiliriz; bize yazın, uygulamanın durumuna bakıp nereden başlamak gerektiğini söyleyelim.