[{"data":1,"prerenderedAt":46},["ShallowReactive",2],{"blog-legacy-laravel-projesi-devralma":3},{"html":4,"toc":5,"faq":33},"\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"ilk-hafta-erisim-ve-envanter\">İlk hafta: erişim ve envanter\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Kaynak kod:\u003C\u002Fstrong> Repo hangi hesapta? Şirketin organizasyonuna taşındı mı? Tüm dallar ve etiketler orada mı?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Sunucu ve barındırma:\u003C\u002Fstrong> Sunucu, bulut hesabı ya da paylaşımlı hosting paneli kimin adına?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Alan adı ve DNS:\u003C\u002Fstrong> Kayıt şirketindeki hesap ve DNS yönetimi kimde?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Veritabanı:\u003C\u002Fstrong> Canlı veritabanına kim, hangi kullanıcıyla erişiyor?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Üçüncü taraf servisler:\u003C\u002Fstrong> E-posta gönderimi, ödeme, SMS, depolama, e-Fatura entegratörü gibi servislerin hesapları ve API anahtarları.\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Sırlar:\u003C\u002Fstrong> Canlıdaki \u003Ccode>.env\u003C\u002Fcode> dosyası nerede, kopyası güvenli bir yerde duruyor mu?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Zamanlanmış işler ve kuyruklar:\u003C\u002Fstrong> Sunucuda hangi cron satırları ve hangi kuyruk işçileri çalışıyor?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Dokümantasyon ve bilgi:\u003C\u002Fstrong> README, wiki, eski iş takip kayıtları ve — mümkünse — eski geliştiriciyle bir devir görüşmesi.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"uygulamayi-yerelde-ayaga-kaldirmak-ve-yedekleri-kanitlamak\">Uygulamayı yerelde ayağa kaldırmak ve yedekleri kanıtlamak\u003C\u002Fh2>\n\u003Ch3 id=\"yerel-kurulum\">Yerel kurulum\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3 id=\"yedekler\">Yedekler\u003C\u002Fh3>\n\u003Cp>"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 \u003Ccode>storage\u003C\u002Fcode> 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.\u003C\u002Fp>\n\u003Ch2 id=\"kod-tabanini-okumak-nereden-baslanir\">Kod tabanını okumak: nereden başlanır\u003C\u002Fh2>\n\u003Cp>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:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Rotalar.\u003C\u002Fstrong> \u003Ccode>php artisan route:list\u003C\u002Fcode> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Modeller ve migration'lar.\u003C\u002Fstrong> Veritabanı şeması, iş alanının en dürüst özetidir. Tablo adları ve ilişkiler, kimsenin yazmadığı iş kurallarını ele verir.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Zamanlanmış işler ve job'lar.\u003C\u002Fstrong> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Servis sağlayıcılar ve config.\u003C\u002Fstrong> Uygulamanın hangi dış servislere bağlandığı ve hangi ayarların ortama göre değiştiği burada durur.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Git geçmişi.\u003C\u002Fstrong> En sık değişen dosyalar genellikle en çok sorun çıkaran ya da en çok iş kuralı taşıyan dosyalardır.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"bagimlilik-ve-php-surum-denetimi\">Bağımlılık ve PHP sürüm denetimi\u003C\u002Fh2>\n\u003Cp>Envanterin teknik yarısı bağımlılıklar. Şunlara bakın:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Laravel sürümü\u003C\u002Fstrong> ve hâlâ güvenlik güncellemesi alıp almadığı. Laravel'in destek tablosu resmi \u003Ca href=\"https:\u002F\u002Flaravel.com\u002Fdocs\u002Freleases\" target=\"_blank\" rel=\"noopener noreferrer\">sürüm notlarında\u003C\u002Fa> yayımlanıyor.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>PHP sürümü\u003C\u002Fstrong>, 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Composer paketleri.\u003C\u002Fstrong> \u003Ccode>composer outdated\u003C\u002Fcode> geride kalan paketleri, \u003Ccode>composer audit\u003C\u002Fcode> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Ön yüz bağımlılıkları.\u003C\u002Fstrong> Varsa npm paketleri ve derleme zinciri; eski bir Node sürümüne bağımlı bir derleme, deploy'u kilitleyebilir.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Çekirdeğe yapılan müdahaleler.\u003C\u002Fstrong> \u003Ccode>vendor\u003C\u002Fcode> klasöründe elle değiştirilmiş dosyalar, bir sonraki \u003Ccode>composer install\u003C\u002Fcode> ile kaybolacak değişiklikler demektir.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"testler-once-guvenlik-agi\">Testler: önce güvenlik ağı\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Giriş ve yetkilendirme: kim neyi görebiliyor?\u003C\u002Fli>\n\u003Cli>Para ya da belge üreten akışlar: sipariş, ödeme, fatura, rapor.\u003C\u002Fli>\n\u003Cli>Dışarıyla konuşan entegrasyonlar: bir API çağrısı, bir webhook, bir e-posta.\u003C\u002Fli>\n\u003Cli>Zamanlanmış işler: her gece çalışan ve sessizce bozulabilen işler.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"izleme-ve-hizli-guvenlik-kazanimlari\">İzleme ve hızlı güvenlik kazanımları\u003C\u002Fh2>\n\u003Ch3 id=\"loglama-ve-izleme\">Loglama ve izleme\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3 id=\"hizli-guvenlik-adimlari\">Hızlı güvenlik adımları\u003C\u002Fh3>\n\u003Cp>Bazı düzeltmeler küçük ama etkisi büyük:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Canlıda \u003Ccode>APP_DEBUG\u003C\u002Fcode> kapalı olmalı; açıksa hata sayfaları ortam bilgilerini sızdırabilir.\u003C\u002Fli>\n\u003Cli>\u003Ccode>.env\u003C\u002Fcode> dosyasının web üzerinden erişilemediğini, sunucunun kök dizininin \u003Ccode>public\u003C\u002Fcode> klasörü olduğunu doğrulayın.\u003C\u002Fli>\n\u003Cli>Eski geliştiricinin kullandığı veritabanı, sunucu ve servis şifrelerini değiştirin; API anahtarlarını yenileyin.\u003C\u002Fli>\n\u003Cli>Uygulamadaki yönetici hesaplarını gözden geçirin; artık şirkette olmayan kişilerin hesaplarını kapatın.\u003C\u002Fli>\n\u003Cli>\u003Ccode>composer audit\u003C\u002Fcode> çıktısındaki kritik açıkları kapatın; bunu yaparken yedek ve testlerin hazır olduğundan emin olun.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"risk-haritasi\">Risk haritası\u003C\u002Fh2>\n\u003Cp>İlk ayın sonunda elinizde, yönetime de gösterebileceğiniz tek sayfalık bir risk haritası olmalı. Basit bir tablo yeter:\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Alan\u003C\u002Fth>\n\u003Cth>Bulgu\u003C\u002Fth>\n\u003Cth>Etki\u003C\u002Fth>\n\u003Cth>Olasılık\u003C\u002Fth>\n\u003Cth>Öneri\u003C\u002Fth>\n\u003Cth>Öncelik\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Yedek\u003C\u002Ftd>\n\u003Ctd>Storage yedeklenmiyor\u003C\u002Ftd>\n\u003Ctd>Yüksek\u003C\u002Ftd>\n\u003Ctd>Orta\u003C\u002Ftd>\n\u003Ctd>Yedeğe ekle, geri yüklemeyi test et\u003C\u002Ftd>\n\u003Ctd>Hemen\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Sürüm\u003C\u002Ftd>\n\u003Ctd>Laravel güvenlik desteği bitmiş\u003C\u002Ftd>\n\u003Ctd>Yüksek\u003C\u002Ftd>\n\u003Ctd>Artıyor\u003C\u002Ftd>\n\u003Ctd>Kademeli yükseltme planı\u003C\u002Ftd>\n\u003Ctd>Bu çeyrek\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Test\u003C\u002Ftd>\n\u003Ctd>Ödeme akışında test yok\u003C\u002Ftd>\n\u003Ctd>Yüksek\u003C\u002Ftd>\n\u003Ctd>Orta\u003C\u002Ftd>\n\u003Ctd>Karakterizasyon testleri\u003C\u002Ftd>\n\u003Ctd>Yükseltmeden önce\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Bilgi\u003C\u002Ftd>\n\u003Ctd>Deploy adımları tek kişide\u003C\u002Ftd>\n\u003Ctd>Orta\u003C\u002Ftd>\n\u003Ctd>Yüksek\u003C\u002Ftd>\n\u003Ctd>Deploy'u belgele ve otomatikleştir\u003C\u002Ftd>\n\u003Ctd>Bu ay\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"neden-bastan-yazmamali\">Neden baştan yazmamalı\u003C\u002Fh2>\n\u003Cp>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:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Ç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.\u003C\u002Fli>\n\u003Cli>Yeniden yazım sürerken eski sistem de yaşamaya devam eder; iki sistemi aynı anda taşırsınız.\u003C\u002Fli>\n\u003Cli>Yeni sistem eskisinin yaptığı her şeyi yapana kadar iş birimi için değer üretmez.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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 \u003Ca href=\"\u002Fhizmetler\u002Fozel-yazilim-gelistirme\">özel yazılım geliştirme\u003C\u002Fa> projesi olarak ele almak, açık uçlu bir yeniden yazımdan çok daha kontrollüdür.\u003C\u002Fp>\n\u003Ch2 id=\"nereden-baslamali\">Nereden başlamalı?\u003C\u002Fh2>\n\u003Cp>İlk 30 günü kabaca şöyle bölebilirsiniz:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>1. hafta:\u003C\u002Fstrong> Erişimleri ve envanteri şirkete toplayın, sırları değiştirin.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>2. hafta:\u003C\u002Fstrong> Yerel kurulumu çalıştırın, yedekten geri yüklemeyi kanıtlayın.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>3. hafta:\u003C\u002Fstrong> Bağımlılık ve sürüm denetimini yapın, kritik akışlara ilk testleri ekleyin.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>4. hafta:\u003C\u002Fstrong> İzlemeyi kurun, hızlı güvenlik adımlarını tamamlayın, risk haritasını yazın.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Bu işi içeride yapacak kıdemli bir Laravel geliştiriciniz yoksa, önce \u003Ca href=\"\u002Fblog\u002Flaravel-gelistirici-ise-alim-mi-ekip-takviyesi-mi\">Laravel geliştiricisini işe almak mı ekip takviyesi mi\u003C\u002Fa> sorusunu netleştirmek iyi bir başlangıç. Devraldığınız kod tabanına kimse dokunmak istemiyorsa, \u003Ca href=\"\u002Fhizmetler\u002Fyazilim-ekibi-kiralama\">yazılım ekibi kiralama\u003C\u002Fa> hizmetimizle bu ilk ayı sizin repo'nuzda ve ekibinizle birlikte yürütebiliriz; \u003Ca href=\"\u002Filetisim\">bize yazın\u003C\u002Fa>, uygulamanın durumuna bakıp nereden başlamak gerektiğini söyleyelim.\u003C\u002Fp>\n",[6,9,12,15,18,21,24,27,30],{"id":7,"text":8},"ilk-hafta-erisim-ve-envanter","İlk hafta: erişim ve envanter",{"id":10,"text":11},"uygulamayi-yerelde-ayaga-kaldirmak-ve-yedekleri-kanitlamak","Uygulamayı yerelde ayağa kaldırmak ve yedekleri kanıtlamak",{"id":13,"text":14},"kod-tabanini-okumak-nereden-baslanir","Kod tabanını okumak: nereden başlanır",{"id":16,"text":17},"bagimlilik-ve-php-surum-denetimi","Bağımlılık ve PHP sürüm denetimi",{"id":19,"text":20},"testler-once-guvenlik-agi","Testler: önce güvenlik ağı",{"id":22,"text":23},"izleme-ve-hizli-guvenlik-kazanimlari","İzleme ve hızlı güvenlik kazanımları",{"id":25,"text":26},"risk-haritasi","Risk haritası",{"id":28,"text":29},"neden-bastan-yazmamali","Neden baştan yazmamalı",{"id":31,"text":32},"nereden-baslamali","Nereden başlamalı?",[34,37,40,43],{"q":35,"a":36},"Devraldığım Laravel projesinde ilk ne yapmalıyım?","Kod yazmadan önce erişimleri şirketin adına toplayın ve yedeklerin gerçekten geri yüklenebildiğini doğrulayın. Bu ikisi olmadan yapılan her değişiklik, bir şey ters gittiğinde geri dönüşü olmayan bir risk taşır.",{"q":38,"a":39},"Eski bir Laravel uygulamasını baştan yazmak mantıklı mı?","Çoğu zaman değil. Çalışan kod, yazıya dökülmemiş birçok iş kuralını içerir ve baştan yazım bu kuralları yeniden keşfetmeyi gerektirir. Genellikle daha güvenli yol, testlerle güvenlik ağı kurup uygulamayı parça parça iyileştirmektir.",{"q":41,"a":42},"Test olmayan bir Laravel projesine nereden test eklenir?","En kritik iş akışlarından başlayın: giriş, ödeme, fatura ya da sipariş gibi bozulduğunda en çok zarar veren yerler. Bu akışların bugünkü davranışını kayda geçiren birkaç feature test, sonraki her değişikliği daha güvenli yapar.",{"q":44,"a":45},"Devralınan projede güncel olmayan PHP ve Laravel sürümleri ne kadar acil?","Kullandığınız sürümlerin hâlâ güvenlik güncellemesi alıp almadığına bakın. Almıyorsa yükseltme planı ilk aylarda yapılmalı; ama yükseltmeden önce yedek, yerel kurulum ve temel testler hazır olmalı.",1793978420994]