Yerel Çalışmalar Yayılmaya Başladığında Laravel Projelerini Bulunabilir Tutma

Eğer bilgisayarınızda birden fazla Laravel uygulaması bulunduruyorsanız, asıl sorun php artisan serve değildir. Sorun, doğru projeyi hızlı bir şekilde bulmak ve akışta kalmaktır.

Bu durum, birden fazla müşteri işi, deneyler, dahili araçlar ve benzer isimlere sahip eski repolar arasında gidip gelirken küçük görünebilir. Yanlış .env dosyası, yanlış veritabanı, yanlış branch, yanlış terminal sekmesi, yanlış PHP versiyonu veya yanlış kuyruk işçisi ile zaman kaybı yaşamak kaçınılmaz hale gelir. Çözüm, başka bir yer işaretleri klasörü açmak değildir. Çözüm, Laravel uygulamalarını keşfedilebilir, ayırt edilebilir ve güvenli bir şekilde geçiş yapmayı sağlayan yerel bir proje iş akışıdır.

Tavsiyem basit: yerel Laravel projelerini bir dizin sistemi gibi düşünün, bir klasör yığını gibi değil. Tutarlı adlandırma, aranabilir bir proje kökü, makine tarafından okunabilir meta veriler ve küçük bir kısayol katmanı kullanın. Bunu yaptığınızda, proje dağılması kaotik hissettirmekten çıkıp operasyonel bir hale gelir.

Tek Bir Proje Haritası ile Başlayın

Çoğu Laravel dağılması rastgele yerleştirme ile başlar. Bir uygulama ~/Code‘da, diğeri ~/Sites‘de, iki tane daha bir müşteri arşiv klasörü içinde ve bir garip dahili araç, Desktop/yeni-son-yeni dizininde kaybolmuş durumdadır. Hiçbir başlatıcı, kurallar içermeyen bir düzeni düzeltemez.

İlk adım, aktif çalışmalar için tek bir üst düzey kural oluşturmaktır. Bu, her repo’nun fiziksel olarak tek bir klasör içinde bulunması gerektiği anlamına gelmez, ancak etkin Laravel evreniniz bir öngörülebilir yapı izlemelidir.

Pragmatik bir düzen aşağıdaki gibi görünebilir:

~/work
  /clients
    /acme-billing-api
    /acme-admin-portal
    /northwind-dashboard
  /products
    /qcode-cms
    /internal-ops
  /experiments
    /laravel-octane-bench
    /rag-prototype
  /archive
    /old-client-portal

Bu amaçla sıkıcıdır. Amaç, bir adlandırma şeması ile karar alma sürecini ortadan kaldırmaktır, marka oluşturma fırsatları yaratmak değil.

Önemli birkaç kural var:

• Tanım veya sahiplik bilgilerini yolda belirtin: clients, products, experiments, archive.
• Klasör adları makinenizde küresel benzersiz olmalıdır.
• Belirsiz adlar kullanmaktan kaçının, örneğin admin, backend, api veya new-app gibi.
• Ölü repoları archive‘a taşıyın, böylece arama sonuçlarınız temiz kalır.

Burada yararlı olan değişim bilişsel bir kaymadır. Artık “O Laravel uygulamasını nereye koymuştum?” diye sormuyorsunuz; “Bu hangi klasörde olmalı?” diye soruyorsunuz. Bu soru çok daha az maliyetlidir.

Projeleri Estetik İçin Değil, Elde Tutmak İçin Adlandırın

Yerel karmaşa, güzel repo adlarıyla başlar, ancak kötü arama anahtarı olur. pulse, forge, core, platform, studio, dashboard güzel görünebilir ama altı alakasız projeyle örtüşen niyet sahibi olabilir.

Yerel adlandırmaları baskı altında elde tutmayı optimize edecek şekilde yapmalısınız. Spotlight, Raycast, Alfred, terminalde bulanık bulucu veya menü çubuğu başlatıcıda iken, proje adlarının derhal kendini ayırt etmesini istersiniz.

Daha iyi bir kalıp şöyle olabilir:

{owner-or-domain}-{app-name}-{role}

Örnekler:

• acme-inventory-api
• acme-inventory-admin
• northwind-client-portal
• qcode-content-pipeline
• internal-support-desk

Uzun isimler sorun değildir; belirsiz isimler sorundur.

İyi İsimler Neleri Önler

İyi adlandırma sadece arama yardım etmez, aynı zamanda operasyonel hataları da önler.

Hem acme-api hem de acme-admin gibi iki proje varsa, ikisi de backend versiyonlarına sahip olduğu için yanlış repo içinde migrate işlemi yapma ihtimaliniz daha düşük olur. Bir uygulama arşivdeyse, yolun kendisi onu açmadan önce bile size bunu söyler.

Bu aynı zamanda Git branch listeleri, terminal istemi, Docker konteyner adları ve editör çalışma sekmeleriyle de yardımcı olur. Güçlü bir proje adı, tüm araç zinciri boyunca sürekli yarar sağlar.

Kuralım: eğer bir klasör adı kime ait olduğunu ve ne yaptığını belirtmiyorsa, yeniden adlandırın.

Hafif Proje Metadata’sı Ekleyin

Klasör yapısı sizi yarıya kadar götürür. Bir sonraki adım, her Laravel uygulamasını kendini tanıtabilir hale getirmektir.

Üç hafta uzakta kaldıktan sonra bir repoyu açtığınızda, bu soruları anında cevaplayabilmelisiniz:

• Hangi PHP sürümüne ihtiyaç var?
• Valet, Herd, Sail veya özel bir Docker yığını mı kullanılıyor?
• Yerel olarak hangi veritabanı ile iletişim kuruyor?
• Hangi branch güvenli veya varsayılan olarak kabul ediliyor?
• Kuyruklar, Horizon, Reverb veya Vite çalıştırılması bekleniyor mu?

Bunları aklınızda tutmayın. Bunu repoya veya yanında koyun.

Basit bir yaklaşım, kök dizininde küçük bir makine dostu dosya, örneğin .project-meta.json veya kısa bir PROJECT.md oluşturmaktır.

{
  "name": "acme-inventory-admin",
  "runtime": "laravel-herd",
  "php": "8.3",
  "node": "22",
  "database": "acme_inventory_admin",
  "default_branch": "main",
  "services": [
    "vite",
    "queue"
  ],
  "notes": "Uses S3-compatible local storage and requires Redis"
}

Bu, belge tiyatrosu değil; projenin scriptler tarafından dizine alınabilir ve insanlar tarafından okunabilir hale getirilmesidir.

Örneğin, bir başlatıcı script bu dosyayı analiz edebilir ve uygulamanın Sail istemesi veya bir terminal açıp npm run dev çalıştırmasını söyleyebilir. Otomatik hale getirmeseniz bile, meta veriler duraksamayı azaltır.

Gizli Kazanım: Daha Güvenli Bağlam Geçişi

Çoğu yerel sürtünme aslında bağlam geçişi riskidir. cd kullanmanın zor olduğu için yavaş değilsiniz. Her proje geçişi belirsizlik taşıdığı için yavaşsınız.

Bu belirsizlik rahatsız edici alışkanlıklar yaratır:

• .env‘yi açıp veritabanını kontrol etmek
• Eski uygulamaların bozulabileceği için php -v‘yi kontrol etmek
• Doğru yerel URL’yi bulmak için eski notları aramak
• Bu repoda npm run dev mi yoksa composer dev mi kullanılacağını tahmin etmek

Küçük bir meta veri dosyası, bu tekrar eden kontrolleri tek bir bakışta halleder. Bu gerçek bir iş akışı iyileştirmesidir, kozmetik bir değil.

Belleği Değil, Aranabilir Kısayollar Kullanın

Klasörleriniz ve isimleriniz mantıklı hale geldikten sonra, ince bir kısayol katmanı ekleyin. İşte burada bir başlatıcı, menü çubuğu uygulaması, Raycast scripti, shell fonksiyonu veya hatta fzf gerçekten işe yarar hale gelir.

Hata, önce belleğe, sonra araçlara güvenmektir. Bunu tersine çevirin. Projelerin nerede olduğunu veya hangi komuta ihtiyaç duyduğunu hatırlamayacağınızı varsaymalısınız. Bakış yolunu, hatırlamaktan daha hızlı olacak şekilde inşa edin.

Shell tabanlı bir versiyon çoğu geliştirici için yeterlidir.

# ~/.zshrc
lp() {
  local root="$HOME/work"
  local project
  project=$(find "$root" -maxdepth 3 -type d \( -name .git -prune -o -name artisan -print \) 2>/dev/null | \
    sed 's#/artisan##' | \
    fzf --prompt='Laravel project > ' --height=40%)

  [ -z "$project" ] && return
  cd "$project" || return
  echo "Switched to: $project"
}

Bu fonksiyon kasıtlı olarak basittir. artisan içeren dizinleri bulur, bunları bulanık bir şekilde aramanıza olanak tanır ve seçtiğiniz uygulamaya geçiş yapar.

Öğeleri çerçeve olmadan zenginleştirebilirsiniz:

• Seçicide branch adını gösterin
• .project-meta.json önizlemesi yapın
• Otomatik olarak Cursor veya VS Code’da açın
• Yerel URL’yi kopyalayın
• Beklenen hizmetleri başlatın

GUI araçlarını tercih ediyorsanız, aynı mantık uygulanır. Bir menü çubuğu uygulaması veya başlatıcı, kurallarınıza dayalı olarak yararlı hale gelir. Bunun dışında, sadece daha güzel bir arama kutusudur.

Örnek: Bulucudan Tek Komuta

Gerçek bir iş akışından önce:

1. Finder’ı açın.
2. Müşteri adını arayın.
3. Önce yanlış repo’yu açın.
4. .env‘yi kontrol edin.
5. Terminali açın.
6. Uygulamanın aslında başka bir klasörde olduğunu anlayın.

Gerçek bir iş akışından sonra:

1. lp çalıştırın.
2. acme adm yazın.
3. Doğru bağlam ile acme-inventory-admin dizinine gelin.

Bu fark basit görünüyor. Ancak değil. Haftada çok sayıda geçişte, keskin hissetmek ile dağınık hissetmek arasındaki farktır.

Yerel Çalışma Giriş Noktalarını Standartlaştırın

Keşfedilebilir bir proje, eğer her repo farklı bir şekilde başlıyorsa hala sinir bozucudur. Bir Laravel uygulaması composer run dev ister, diğeri php artisan serve bekler, biri Sail kullanır ve eski bir müşteri projesi hala Valet ile manuel kuyruk işçisi gerektirir.

Bu farklılıkları tamamen ortadan kaldırmanıza gerek yok, ancak giriş noktasını normalleştirmelisiniz.

Temiz bir kalıp, her projeyi belirgin bir başlatma komutunu destekler hale getirmektir, iç yapılar farklı bile olsa.

Örneğin, her repo için bir make dev, just dev veya Composer betiği ekleyebilirsiniz:

{
  "scripts": {
    "dev": [
      "Composer\\Config::disableProcessTimeout",
      "php artisan serve",
      "php artisan queue:listen --tries=1",
      "npm run dev"
    ]
  }
}

Sail tabanlı uygulamalar için de kısayol dev‘yi gösterebilir, ancak uygulama Dockerı çağırabilir. Harici arayüz stabil kalır.

Bu önemli çünkü beyin, her proje kategorisi için bir eylemi hatırlamayı, bir dizi istisna yığınına kıyasla çok daha iyi yapar.

Ekiplerin Genelde Hatalı Gittiği Noktalar

Başlangıç adımlarını bir README dosyasında belgeliyorlar ve bunu tamamladıklarını düşünüyorlar. Bu, işe alımda yardımcı olur, ancak günlük sorgulama çözümünü sağlamaz. Yerel iş akışı yine de hatırlamaya dayanır.

Daha iyi bir kural:

• README yığını açıklar.
• Meta veri yerel bağlamı açıklar.
• Başlatma uygulaması için bir standart komut vardır.
• Başlatıcınız veya shell fonksiyonunuz her ikisini de açığa çıkarır.

Bu, belgeler ile operasyonlar arasındaki farktır.

Yanlış Proje Hatalarını Zor Hale Getirin

Proje dağılmasındaki asıl tehlike kaybedilen saniyeler değildir. Doğru nesneyi yanlış repoda yapmak tehlikesidir.

Bu nedenle, yanlış yerel veritabanında migrate yapmak, ihtiyaç duyduğunuz taşlayıcı verileri silmek ya da unuttuğunuz bir bayrağa commit yapmak gibi sorunlar ortaya çıkar.

Bu tür hataları varsayılan olarak zor hale getirmelisiniz.

Pratik güvenlik önlemleri:

• Shell isteminde proje adını ve Git branch’ini gösterin.
• Her uygulama için farklı yerel veritabanı adları kullanın, asla app veya laravel gibi paylaşılan genel isimler kullanmayın.
• Veri üzerinde yardımcı olan .env değerlerinde uygulama adını ekleyin, örneğin Redis önekleri veya kuyruk adları gibi.
• Tarayıcı sekmesini belirgin hale getirmek için görünür bir APP_NAME ekleyin.
• Arşivlenmiş uygulamaları aktif arama kapsamınızın dışında tutun.

İyi Bir Güvenlik Kalıbı

Birçok benzer müşteri panosuyla çalışıyorsanız, tahrip edici işler öncesinde nerede olduğunuzu tam olarak belirten bir çevre denetim komutu oluşturun:

php artisan about
php artisan env
git branch --show-current

Dahası, bunu sarın:

ctx() {
  echo "Project: $(basename "$PWD")"
  echo "Branch:  $(git branch --show-current 2>/dev/null)"
  php artisan env 2>/dev/null
}

İşlemler, müzik, toplu veriler, kuyruk yeniden başlatmaları veya arama ve değiştirme işlerini yürütmeden önce ctx komutunu çalıştırın. Bu küçük bir alışkanlık, gereksiz hataların önlenmesi açısından faydalıdır.

İş Akışını Katmanlar Üzerinde Kurun

Günlük birincil her yönü aşırı mühendislik yapmayın. Doğru yaklaşım katmanlıdır.

Gerçek sorunu çözen minimum sistemi aşağıdaki gibi başlayın:

1. Öngörülebilir bir klasör yapısı.
2. Açık, aranabilir isimler.
3. Temel proje meta verileri.
4. Bir bulanık kısayol veya başlatıcı.
5. Bir standart yerel başlatma komutu.

Bunlar yalnızca çoğu Laravel proje dağılmasını temizler.

Yalnızca bu tamamlandığında, menü çubuğu dizini, otomatik olarak algılanan yerel URL’ler, branch’a özel başlatıcılar veya proje panoları gibi daha zengin araçları eklemeyi düşünün. Bunlar yararlıdır ama çarpanlardır. Temel değildirler.

Birçok yerel üretkenlik aracı, bu tür karmaşıklık kalabalığını hedef almaktadır. Araçlar, dosya sistemi, adlandırma ve çalışma zamanları arasındaki tutarsızlık halka açık kalmaya devam ettiği sürece bu tür karmaşıklık yararlanamaz. Araçlar yararlıdır, ancak kaosu kurtaramazlar.

Pratik Kural

Eğer düzenli olarak birden fazla Laravel kod tabanıyla çalışıyorsanız, proje keşfini resmi bir alışkanlık olarak ele almayı bırakın. Bunu bir sisteme dönüştürün.

Başarılı ayar karmaşık değildir: stabil yollar, belirgin isimler, hafif meta veriler, aranabilir kısayollar ve standartlaştırılmış başlatma komutları. Bu kombinasyon, friksiyonu ortadan kaldırır ve merasim eklemez.

Bu hafta yalnızca bir şeyi değiştirirseniz, belirsiz repo’larınızı yeniden adlandırın ve aktif Laravel uygulamalarınızı tek bir dizin altında toplayın. Bu Tek hamle, genellikle geri kalan karmaşayı hızla açığa çıkaracak ve projeleri güvenli bir şekilde bulmak mümkün olduğunda, her türlü yerel iş akışı iyileşmesi daha da kolaylaşır.

Tam yazıyı QCode’da okuyun: https://qcode.in/laravel-project-sprawl-keep-local-apps-findable/