Laravel, PHP ile yazılmış açık kaynak bir çatıdır ve bir sistemi kurmak için yapı ile başlangıç noktası verir. Sizin açınızdan asıl ayrım bundan sonra başlıyor: çatı, kuralın yazılacağı yeri getirir; yazılacak kuralı getirmez. Bu yüzden adı okumak kodun düzenini anlatır, düzenin işinize uyduğunu göstermez.
Laravel nedir: dil değil, hazır site değil, PHP ile yazılmış açık kaynak bir çatı
Laravel bir programlama dili değil. Dil PHP’nin kendisi; Laravel ise o dille kurulan sistemin kodunu hangi düzende tutacağını belirleyen hazır yapı. Çatının kendi kurulum belgesi işini açıkça tarif ediyor: uygulamayı kurmak için bir yapı ve başlangıç noktası sağlamak. Aynı belge, Laravel ile bir sistem kurmak için makinede PHP bulunması gerektiğini de yazıyor. Yani ad altındaki dili ima ediyor ama dilin yerini almıyor.
Düzen kelimesi burada somut bir şeyi anlatıyor. Yolların tanımlandığı dosyalar belirli bir yerde durur, veritabanı tablosuna karşılık gelen kayıt sınıfları başka bir yerde, gelen girdinin sınandığı kurallar kendi yerinde. Bu yerleşim kurulumdan kuruluma değişmiyor. Kodu ilk kez açan birinin nereye bakacağını bilmesi bu yüzden kişisel hafızaya değil ortak bir alışkanlığa bağlı.
Kurulum bittiğinde elinize ziyaretçinin bakabileceği bir site geçmiyor. Hazır tema ile çatı arasındaki ayrım tam burada duruyor: bir tema hazır ekran ve hazır kural getirir, çatı ne ekranı ne kuralı getirir; getirdiği şey o ekranın ve o kuralın yazılacağı yer. Ekranların ve kuralların sıfırdan yazılması ayrı bir işin konusu ve o işin kapsamını web yazılım sayfası anlatıyor. Bu yazı yalnız sınırı çiziyor: sabit kalan şey çatı, yazılan şey ekran ve kural.
Hazır kurulan kurumsal siteler aynı soruyu başka uçtan açıyor. WordPress gibi hazır bir içerik aracıyla kurulan site elinize çalışan ekranlarla geliyor; kararın nereden geçtiğini kurumsal site için WordPress ile özel yazılımı karşılaştıran rehberde ele aldık. Ayrım bir üstünlük sıralaması değil: o araçlar hazır ekranla başlıyor, çatı boş bir düzenle.
Lisans tarafı kısa tutulabilir. Laravel izin verici bir açık kaynak lisansıyla, MIT metniyle dağıtılıyor; lisansın neyi verip neyi üstlenmediğini açık kaynak yazısında açtık. Burada önemli olan tek şey lisansın kuralları yazmaması.
Adı gördüğünüz yer de anlamını değiştiriyor. Kurulurken verilen bir kararda ad bir tercihtir. Devraldığınız bir sistemin belgesinde ise aynı ad bir tercih değil, envanterin bir kalemi. Bize ulaştığında KGM SsangYong’un kurumsal sitesi yayındaydı ve çalışıyordu; talep yeni bir site kurmak değil, ayakta duran siteyi hafifletmekti.
Laravel ne işe yarar: tanıtım sayfası ile gelen talep aynı kod tabanında durur
Soru çoğu zaman şu endişeyle geliyor: tanıtım sayfaları için bir sistemin, siteden gelen talep için başka bir sistemin parasını mı ödeyeceğim. Cevap ayrı bir kurulum değil. Diotek’in klima ve havalandırma sitesinde sayfa geçişini Inertia ziyaretçinin cihazında yapıyor; yönlendirmeyi ve formun sınanmasını Laravel taşıyor, gelen talebin kaydı ile sitenin içeriği tek bir MySQL şemasını paylaşıyor.
Bunun alıcı açısından anlamı şu: içeriğin durduğu yer ile talebin düştüğü yer aynı şemada olduğu için araya bir aktarma işi girmiyor. Ayrı kurulan sistemlerde o aktarma sonradan yazılır, bakımı ayrıca istenir ve bozulduğunda hangi tarafın kusurlu olduğu tartışılır. Kuruluş anında alınan karar bu tartışmayı baştan kapatıyor. Sonradan birleştirmek ise aynı karar değil: ayrı şemaları tek şemaya taşımak kayıtların kendisini elden geçirmeyi gerektiriyor.
Kurulumun içinde görünen şey sayfalardan fazlası. KGM SsangYong’un kurumsal sitesinde model sayfaları, katalog okumaları ve araç görsellerinin deposu aynı kurulumun parçaları olarak elden geçirildi. Yani bu soruya “sayfa üretir” cevabı eksik kalıyor; kurulum aynı zamanda bir okuma yolu ve bir dosya deposu taşıyor.
Aynı kod tabanında durmak her sorunu da kapatmıyor. İçerik ile talep aynı şemayı paylaşıyorsa, içerikte yapılan bir şema değişikliği talep tarafını da ilgilendiriyor ve değişiklik aynı bakım penceresinde ele alınıyor. Kazanç aktarma işinin hiç doğmaması; bedel ise değişikliklerin birbirine bakması. Hangisinin size uygun olduğu, içeriğin ve talebin ne sıklıkla değiştiğine bağlı.
Soruya her zaman “yeni bir kurulum” cevabı da düşmüyor. Elinizde çalışan bir sistem varsa çatı bir karar değil bir veri. O durumda sorulacak şey ne kurulacağı değil, kurulmuş olanın hangi kısmının işinize göre yazıldığı.
Çatı, her sistemde tekrar eden işi hazır getirir
Çatının hazır getirdiği işler resmi belgelerinde adlarıyla yazılı ve okur aynı adları teklifte de görüyor. Yönlendirme (routing) gelen adresi bir davranışa bağlıyor; yollar proje içindeki yönlendirme dosyalarında duruyor. Doğrulama (validation) bileşeni gelen veriyi sınamak için hazır bir kural kümesi taşıyor ve bir değerin veritabanı tablosunda tek olup olmadığını sınamak da bunun içinde. Eloquent, her veritabanı tablosuna karşılık gelen bir modelle kayıt okuyup yazıyor. Göçler (migrations) şema tanımını sürümleyerek ekip içinde paylaşılabilir hâle getiriyor. Kuyruklar (queues) bir istek içinde uzun süren işi arka planda işlenecek işe taşıyor. Kimlik doğrulama (authentication) kullanıcı girişini kurmak için hazır araçlar veriyor.
Bu kalemlerin ortak yanı tekrar etmeleri. Adresi koda bağlama işi her sistemde var; gelen girdiyi sınama işi de. Alternatifi düşünmek ayrımı netleştiriyor: bu işler her kurulumda baştan yazılsa, her kurulum kendi hatalarını da baştan üretirdi ve o hataların nerede olduğunu yalnız yazan ekip bilirdi. Çatı bu yüzden yazılacak kod miktarını değil, aynı kodun kaç kez yazılacağını azaltıyor.
Diotek’te bu ayrım yüzeyde de görünüyor: sayfa geçişi ziyaretçinin cihazında olurken, formun kabul edilip edilmeyeceği sunucuda kalıyor. Hangi işin hangi yarıda durduğunu ön yüz ile arka ucu anlatan yazıda ayrıca açtık. Buradaki eksen başka: aracın çatıdan mı işten mi geldiği.
Bir işin çatıdan hazır gelmesi, o işin sizin düzeninize göre yapıldığını göstermiyor. KGM SsangYong’un kurumsal sitesinde çatı yerindeydi; buna karşın aynı katalog sorgusu her sayfa açılışında veritabanına düşüyor ve gereksiz okuma yükü üretiyordu. Hazır araç, o aracın doğru ayarlandığına dair bir kanıt değil.
Hazır gelen şeyin bir sınırı var: çatı işi getiriyor, o işin nasıl ayarlanacağına dair kararı getirmiyor. Doğrulama kural kümesi elinizde duruyor ama hangi kuralın hangi forma bağlanacağı boş bir alan. Kuyruk mekanizması hazır, hangi işin kuyruğa taşınacağı değil. Çatı bu yüzden bir cevap listesi değil, doldurulacak bir soru listesi getiriyor.
Çatıyla gelen her şey yığında hazır da durmuyor. Hazır gelen iş ile yığına ayrıca giren bileşen aynı şey değil: biri adın içinde geliyor, öteki envantere adıyla ekleniyor. Bu ayrım teklifte de görünür, çünkü adıyla eklenen bileşen bakım kapsamına kendi kalemiyle giriyor.
İşinize özel kural çatıda yazılı gelmez: aracı çatı verir, kuralı işi bilen yazar
Doğrulama aracı bir alanın boş olup olmadığını sınıyor; o alanın hangi talepte zorunlu olacağını sınamıyor. Diotek’te bu asimetrinin nedeni işin kendisinde: kapasiteyi mekân belirlediği için keşif, teklif verilmeden önce yapılmak zorunda. Montaj sonrası gelen talepte ise konu baştan belli: kurulu cihaz. Ayrımın kayda nasıl yazıldığını randevu ile servis talebini ayıran yazıda anlattık.
Asıl nokta çatının bilemeyeceği şey. Hazır bir kural kümesi “bu alan zorunlu” diyebilir; “bu alan keşifte zorunlu, serviste değil” demesi için işin koşulunu bilmesi gerekir. O koşul kodda değil sahada duruyor ve kodu yazan tarafa anlatılması gerekiyor. Anlatılmazsa sistem yine çalışır: form kabul edilir, kayıt düşer, kimse bir hata görmez. Yanlış olan şey kaydın kendisi olur.
Aynı türden karar okuma tarafında da duruyor. KGM SsangYong’un kurumsal sitesinde kayıt şöyle: Katalog okumaları Redis üzerinden karşılanıyor; aynı sorgu her ziyaretçi için baştan çalışmıyor, MySQL yalnızca veri değiştiğinde devreye giriyor. Hangi okumanın oradan karşılanacağı ve ne zaman tazeleneceği çatıdan yazılı gelmiyor; veri hangi ritimle değişiyorsa ona göre kararlaştırılıyor. Yani kural kelimesi form sınamasıyla bitmiyor, işin bütün yüzeyine yayılıyor.
Kuralın nerede durduğu alıcı açısından ayrı bir kazanç. Zorunlu alan kümesi kodun tek bir yerinde yazılıysa, bir alanın eklenmesi ya da çıkarılması ekranın kendi koduna dokunmadan yapılabiliyor. Dağıtılmış kuralda aynı değişiklik, kuralın kopyalandığı her yeri bulmayı gerektiriyor ve bir kopyanın atlanması ancak yanlış bir kayıt düştüğünde görülüyor. Bu ayrım çatıdan değil, kuralın nereye yazıldığı kararından geliyor.
Devraldığınız bir sistemde kural zaten yazılmış olabilir ve nerede yazıldığı ancak kod okunarak bulunur. KGM SsangYong işinde ilk karar bu yüzden teknik değildi: neye dokunulmayacağına karar verildi, sonra yalnızca sayfa yükünü taşıyan yerlere girildi.
Hangi kalem çatıdan gelir, hangisi sizin kararınızdır
Aşağıdaki tablo kalemleri yan yana koyuyor. Okuma yönü satır boyunca: bir kalemi doğru satıra yerleştirdiğinizde, kimin neye karar vereceği sorusu o satırın sağındaki hücrelere düşüyor. Sondaki satırlar ayrımın tek yönlü olmadığını da gösteriyor; bazı kalemler çatıdan geliyor, bazıları hiç gelmiyor ve o boşluk bir eksiklik değil, bir karar alanı.
| İş kalemi | Çatıdan hazır gelen | İşinize özel yazılan | Sonradan değiştirmek neyi gerektirir |
|---|---|---|---|
| Adresin hangi davranışa bağlandığı | Yönlendirme bileşeni: gelen adresi bir davranışa bağlar, yollar proje içindeki yönlendirme dosyalarında durur | Hangi yolların var olacağı: Diotek’te her talep tipi kendi yolundan giriyor | Yeni bir talep tipi yeni bir yol ve yeni bir kayıt tipi ister |
| Gelen formun sınanması | Doğrulama bileşeni ve hazır kural kümesi; bir değerin tabloda tek olup olmadığını sınamak da bunun içinde | Hangi talepte hangi alanın zorunlu olduğu: keşifte mekân ve tarih, serviste kurulu cihaz | Kural tek yerde durduğu için alan kümesi ekran koduna dokunmadan değişir |
| Kaydın veritabanındaki yeri | Her tabloya karşılık gelen bir modelle kayıt okuma ve yazma, şema değişikliğini sürümleyen göçler | Hangi bilginin hangi kayıtta duracağı: Diotek’te gelen talebin kaydı ile site içeriği tek şemada duruyor | Şemaya dokunmak o kaydı okuyan her ekranı birden ilgilendirir |
| Hangi okumanın önbellekten geldiği | Önbellek yığına adıyla eklenen bir kalem | Hangi okumanın önbellekten geleceği ve ne zaman tazeleneceği: KGM SsangYong’da katalog okumaları önbellekten geliyor | Yeni bir içerik türü, önbelleğin ne zaman eskidiği sorusunu yeniden açar |
| Dosyanın adının ne söylediği | Araç görsellerinin adlandırma ve klasör düzeni çatıyla gelmiyor | Araç görsellerinin nereye konacağını belirleyen kural KGM SsangYong’da sonradan yazıldı | Düzene uyulmadığı anda yeni model eklemek dosya arama işine döner |
Tablo tek yönlü bir kural dayatmıyor. Aynı kalem bir işte çatının getirdiği araçla kapanırken başka bir işte yığına ayrıca giren bir bileşen gerektiriyor. Hazır gelen sütunu bu yüzden bir vaat değil, bir başlangıç noktası. Değiştirme sütunu ise çoğu zaman atlanıyor: bir kalemin sonradan değişmesinin bedeli, o kalemin hangi sütunda durduğuna göre değişiyor.
Satırların arasındaki bağ da okunabiliyor. Kaydın şeması değiştiğinde onu okuyan her ekran birden ilgileniyor; buna karşılık zorunlu alan kümesi, kural kodun tek bir yerinde durduğu için ekran koduna dokunulmadan değişebiliyor. Aynı sistemde bir değişiklik ucuz, başka bir değişiklik pahalı olabiliyor ve bunu belirleyen şey çatının adı değil.
Çatı yerinde kalırken işin düzeni yeniden kurulabilir
Okurun bu noktada sorduğu şey genelde şu: çatı sabitse elimiz bağlı mı. KGM SsangYong’un kurumsal sitesinde bakımı marka tarafındaki ekip sürdüreceği için uygulama çatısı ile ön yüz seti yerinde kalmak zorundaydı. Buna karşın işin düzeni yeniden kurulabildi. Araç görsellerinin nereye konacağını belirleyen kural sonradan yazıldı ve çatı bu kuralı getirmiyordu. Hangi okumanın önbellekten karşılanacağı da aynı dönemde kararlaştırıldı.
Bölümün yükü şu çıkarımda: bu düzenler çatıya dokunulmadan kurulabildiyse, baştan da çatının değil işin kararıydı. “Çatı sabit” cümlesi işin düzenini kilitlemiyor. Kilitlediği şey araç listesi; düzen ise açık kalıyor.
Değişmeyen tarafın bedeli de kayıtlı ve yazılmadan geçilemez. Baştan yazmak yerine mevcut kalıbın içinde kalan daha küçük hamleler yapıldı. Ön yüz seti de dondurulduğu için jQuery ile yapılan istekler yenisiyle değiştirilmedi, tek tek elden geçirildi. Yani çatı sabitken yeniden kurulabilen şey işin düzeni, kullanılan araç değil. Mevcut araç seti korundu ve yığına yalnız bir okuma önbelleği katıldı.
Hangi işin çatıdan bağımsız olduğunu önceden bilmek de kolay değil. Devralınan bir sistemde bu ayrımı kod okumadan söylemek mümkün olmuyor; dosya düzeni gibi görünen bir sorun çatının dayattığı bir şey de olabilir. KGM SsangYong işinde ayrım okuma turundan sonra netleşti ve müdahalenin sınırı o turda çizildi.
Çatının kendi takvimi de bu tabloya giriyor. Laravel’in yayımlanmış bir sürüm ve destek politikası var: her ana sürümün hata ve güvenlik düzeltmesi desteği belirli bir süre sonra bitiyor ve süreler politikanın kendi sayfasında yazılı. İşinizin kuralları bir sürüm geçişiyle kendiliğinden değişmiyor; kuralların ne olduğu uygulamanın kodunda yazılı kalıyor. Geçişin dokunduğu şey o kodun çatıya bakan kısmı. Bu izlemeyi kimin üstlendiğini bakımı kimin sürdürdüğünü anlatan yazıda ele aldık.
Laravel adı kodun düzenini anlatır, kuralın doğruluğunu sınamaz
KGM SsangYong’un kurulumu, araç görselleri dağınık bir düzende dururken ve hangi dosyanın hangi modele ait olduğu yazılı değilken de çalışıyordu. Çatı o gün de yerindeydi, adı da aynıydı. Buradan çıkan sonuç ağır: ad kodun nereye yazıldığını anlatıyor, yazılanın işin düzenine uyup uymadığını anlatmıyor. Aynı ad, düzen kurulmadan önce de sonra da aynı şeyi söylüyordu.
Adın taşıdığı somut güvence başka yerde duruyor: kodu açacak tarafın hangi yerleşimi okuyacağı önceden belli. Yolların, kayıt sınıflarının ve sınama kurallarının nerede duracağı kurulumdan kuruluma değişmediği için, devreden ekip ile devralan ekip aynı haritaya bakıyor. KGM SsangYong işinde araç listesi de bu nedenle korundu: bakımı bugün marka tarafındaki ekip taşıyor ve tanımadığı bir parça o taşımayı zorlaştırırdı.
Tanıdıklık ile uygunluk aynı şey değil. Kuralın işinize uyup uymadığı ad okunarak anlaşılmıyor, sınanarak anlaşılıyor. Hangi senaryonun bunu gösterdiğini kabul ederken neyi test ettiğinizi anlatan yazıda yazdık. Sınama yapılmadığında elinizde kalan şey bir ad ile çalışan bir sistem; bu kadarı uygunluğu göstermiyor.
Yerine sorulacak soru kısa. Hangi ekranın ve hangi kuralın sizin işinize göre yazıldığı, bunların nerede durduğu ve bir değiştiğinde neyin birlikte değiştiği. Bu cevaplar çatının adından çıkmıyor; sistemi kuran ya da sürdüren tarafın yazması gerekiyor. Ad ise yalnız cevabın nerede aranacağını söylüyor.
Elinizde çalışan ama içinde neyin işinize göre kurulduğu belirsiz bir sistem varsa, kodu okuyup neyin kalıp neyin değişeceğini çıkarmak devralma sayfasının konusu.
