Laravel Paketleri Oluşturmanın Temelleri
Yazılım dünyasında yer alan herkes bilir ki, yapay zeka çağında bile her gün her şeyi sıfırdan yazmak yerine diğer geliştiricilerin oluşturduğu paketlere başvuruyoruz. Bu, özellikle müşteri teslim tarihlerini, genelde “dünden önce” olarak belirleyen durumlarda geçerlidir. Ben bir Freelance Yazılım Mühendisiyim ve benim gibi birçok geliştirici yüzlerce Laravel paketi kullanmış olsa da, kendi paketimi hiç yapmamıştım.
Son zamanlarda küçük bir ekip ile yürüttüğüm bir müşteri projesinde sürekli aynı sorunla karşılaşıyordum: yeni commitler ve özellikler arasında veritabanı yapısını anlamak zordu. Migration’lardaki bir değişiklik olduğunda, tüm şemayı yeniden açıklamak zorunda kalıyordum. Bu, onuncu kezden sonra gerçekten can sıkıcı hale geliyordu.
Yardımcı olabilecek bir paket arayışına girdim, ancak ihtiyaçlarıma uygun bir şey bulamadım. Bu durumda her geliştirici gibi, birkaç gün şikayet ettikten sonra bunu kendim yapmaya karar verdim.
Neden bir paket, neden şimdi
İki neden beni bu duruma itti.
Birincisi pratik bir sebepti: Veritabanı yapısının her zaman tek bir dışa aktarılabilir dosya olarak mevcut olmasını istiyordum. Bu dosya, bana yapıcı zihinler içinde yarattığım projelerden bağımsız olarak kullanabileceğim şekilde hazır olabilmeliydi.
İkincisi ise kişisel bir sebepti: Laravel’in iç işleyişine daha derinlemesine dalmak için bir bahane arıyordum. Web uygulamaları oluşturmak harika, ancak bir noktada çerçevenin sağladığı şeylerin ötesinde neler olup bittiğini anlamak istiyorsunuz.
Bu nedenle yeni bir repo açtım ve takıldığımda Claude adlı arkadaşımı arayabileceğimi biliyordum.
Bir satır kod yazmadan tasarlamak
Uygulamaya geçmeden önce iki şey yaptım.
Öncelikle Reddit topluluğuna gidip bir paketi kullanmaya ikna eden unsurların neler olduğunu sordum. Cevaplar kesinlikle tutarlıydı: net dokümantasyon, odaklı bir kapsam, iyi bir test örtüsü ve hemen sekmeyi kapattırmayan bir kod yapısı. Devrim niteliğinde bir şey değil, ancak gerçekten kullanıcıların görüşlerini duyduğumda değerli bir bilgi kaynağı oldu.
Sonra diğer Laravel paketlerini inceleyerek zaman harcadım. Bu paketlerin nasıl göründüğünü anlamak için, kendim için yapmadığınız zaman farklı olduğunu görmek zorundasınız. Kamu repo içinde karmaşık parçaları gizleyemezsiniz.
Yalnızca yapının kafamda netleşmesinin ardından uygulamaya geçtim. AI benim için tasarlayabilirdi ama bunu istemedim. Gerçekten anlamak istedim.
Mimari
Ana hedefim her şeyi basit ama genişletilebilir tutmaktı. Sadece belirli bir veritabanı için çalışan bir script değil, zamanla topluluğun yeni formatlar veya entegrasyonlar ekleyebileceği bir yapı oluşturmaktı.
İki tasarım deseni ihtiyacım için mükemmel bir uyum sağladı.
İlki, render’lar için kullandığım Strategy Pattern. Paket, Mermaid diyagramları ve dbdiagram sentaksı gibi birden fazla çıktı formatını destekliyor. Gelecekte daha fazlası olabilir. Çekirdek içindeki render mantığını hardcode etmek yerine, her format ortak bir arayüzü uygulayan ayrı bir sınıf. Gelecekte yeni bir format eklemek demek, sadece yeni bir sınıf eklemek demek, başka hiç bir şey değil. Çekirdek değişmiyor.
İkincisi ise, çeviri süreci için kullandığım Template Pattern. Çıktı formatları farklı olsa da, genel süreç her zaman aynı: şemayı analiz et, tabloları dolaş, sütunları ve ilişkileri işle, çıktıyı üret. Bu yapıyı bir kere tanımlamak ve her render’ın yalnızca özel kısımlarını doldurmasına izin vermek, mantığı kopyalamadan her şeyi tutarlı tutmayı sağladı.
Kod Yardımcısı Olarak Claude’u Kullanmak
Tasarım kilitlendiğinde, uygulamayı hızlandırmak için Claude’u kullandım; özellikle render formatları ve birim testleri yazmak için. İşte arayüzlerin net tanımlanmış olması hemen fayda sağladı: iyi tanımlanmış arayüzlerle ve yapılandırılmış bir planla, AI kaybolmadan sağlam bir kod üretebildi.
Bunun gerçekten işe yaradığını kontrol etmek için her uygulama yazmadan önce sıkı bir Composer script seti hazırladım: linting, statik analiz, %100 tip kapsamı, %100 kod kapsamı ve otomatik yeniden yapılandırma kontrolü. Her çıktı hepsinden geçmeliydi. İstisna yok, “sonra düzeltiriz” yok.
{
"scripts": {
"test:lint": "pint --test",
"test:type-coverage": "pest --type-coverage --exactly=100",
"test:unit": "pest --coverage --exactly=100",
"test:types": "phpstan",
"test:refactor": "rector --dry-run",
"test": [
"@test:lint",
"@test:type-coverage",
"@test:unit",
"@test:types",
"@test:refactor"
]
}
}
Bu, hem beni hem de AI arkadaşımı dürüst tuttu. Çalışan bu durum, genellikle bir haftalık işi birkaç güne sıkıştırdı ki, bu da genel müşteri teslim tarihleri düşünüldüğünde ihtiyaç duyduğum şeydi.
Paketin Gerçekten Ne Yaptığı
Fikir basit: tek bir komut, tek bir dosya, tüm veritabanı yapısı. Araçlarınızın hemen kullanabileceği bir format.
php artisan er:generate
Bu sürecin üç ana senaryosu ortaya çıkıyor.
Birincisi, AI ajanslarına veritabanı bağlamı sağlamak için sabır kalmaması. Migration’ları yapıştırmak veya her oturuma başlarken tabloları manuel olarak tanımlamak yerine, yapıyı içeren bir üst seviyeli dosya üretiyorsunuz. AI bunu bir kez okuduğunda her şeye sahip oluyor: tablolar, sütunlar, ilişkiler, indeksler, hepsi bir yerde.
İkincisi, aslında dokümantasyon yazmak zorunda kalmadan veritabanı dokümantasyonu. Şemanın sıkça geliştiği projelerde, her zaman güncel bir dışa aktarılabilir referansın mevcut olması gerçekten yararlı; bu, yeni ekip üyeleri, müşteriler ve kendiniz için geçerli olur.
Üçüncüsü, karmaşık şemaları ek araçlar olmadan görselleştirme. Mermaid ve dbdiagram formatları, bir ER diyagramını anında oluşturmanıza olanak tanır ki bu, özellikle miras alınan bir projeye başlarken veya bir PR’nın on beş tabloyu etkilediği durumlarda gözden geçirme yapmak için yararlıdır.
Bundan Ne Öğrendim
Bir Laravel paketi oluşturmak dışarıdan göründüğü kadar göz korkutucu değil. Composer’autoloading ve service provider keşfi nasıl çalıştığını anladığınızda mekanizmalar oldukça basit. Daha zor olan, başkalarının kodunuzu nasıl kullanacağını hayal etmek, yalnızca sizin nasıl kullandığınız değil — bu bakış açısındaki kaydırma, tasarım kararlarının çoğunun bulunduğu yerdir.
Ayrıca, kod yazmadan önce mimariye zaman harcamanın boşa zaman olmadığını görmek oldukça açıktı. Başlangıç yapısıyla birlikte her eklediğim özellik doğal bir şekilde uyum sağladı çünkü genişletme noktaları zaten oradaydı. Bunun sürekli duyduğunuz ama deneyimlemeden tam olarak inanmadığınız bir şey olduğunu görseniz gerekti.
Bu Sadece Bir Başlangıç
Paket mükemmel değil ve buna gerçekten hazırım. Amaç, ilk seferde kusursuz bir araç göndermek değil. Laravel paketlerinin içinden nasıl çalıştığını anlamak ve her gün beni sinirlendiren bir sorunu çözmekti.
Buradan gidebileceğim zaten birçok yön var: ek dışa aktarma formatları, daha iyi diyagram üretimi, derinlemesine şema analizi, daha fazla AI aracı ile entegrasyon. Açık kaynak, sizin kadar deneyimli olmayan geliştiricilerden öğrenmek ile ilgilidir ve oldukça mutluyum, katkılar, öneriler veya tamamen yanlış bir şey yaptığımı işaret eden birisini bekliyorum.
Denemek istiyorsanız:
composer require paolobellini/laravel-er
Kaynak: Orijinal Makale
