Laravel Türkiye Discord Kanalı Forumda kod paylaşılırken dikkat edilmesi gerekenler!Birlikte proje geliştirmek ister misiniz?

Kullanım ne kadar doğru

Kevin-Mitnick

Selamlar herkese bir tabloda durum alanım var ve aldığı 4 değeri viewa bu şekilde yazıyorum

<td class="col-md-4">@if($altprojes->ProjeDurum==1) Devam Ediyor @elseif($altprojes->ProjeDurum==2) Tamamlandı @elseif($altprojes->ProjeDurum==3) İptal @elseif($altprojes->ProjeDurum==4) Beklemede @endif</td>

ne kadar doğru acaba çalışıyor ama amacım doğruları öğrenmek teşekkürler. normalde bunlar arasında ilişki var ama bu yolu bildiğim için bu yoldan ilerledim.

sineld

if elseif kullanımının bu kadar fazla olması gerektiği koşullarda switch kullanmayı tercih ederim:

<td class="col-md-4">
@switch($altprojes->ProjeDurum)
 @case(1)
 Devam Ediyor
 @break

 @case(2)
 Tamamlandı
 @break

 @case(3)
 İptal
 @break

 @case(4)
 Beklemede 
 @break

 @default
 Bilinmeyen bir durum oluştu
@endswitch

</td>

ancak genel olarak kodunuzda sorun yok.

Kevin-Mitnick

@sineld hocam sağolun

evrend

Bu kontrolü controller'da bir fonksiyon ile yaparak ProjeDurumText gibi bir değişkenle collectiona ekleyerekte döndürülebilir. Blade dosyasında bu tarz kontrolleri minimalize etmeniz kodları daha rahat okumanızı sağlar. Ben mümkün olduğunda bu tarz kontrolleri controller'da hallediyorum.

deathisonitsway

https://softwareengineering.stackexchange.com/questions/206816/clarification-of-avoid-if-else-advice

burda güzel tartısılmış bu konu; recursive if/else design hatası bana göre.kodu bölmek zorundasınız.

https://en.wikipedia.org/wiki/Cyclomatic_complexity

siklomatik karmaşıklık teorisine bir göz atabilirsiniz...

sineld

Eğer Database builder değil de Model yapısı kullanıyorsanız sevgili Evren'in dediği gibi controller içerisinde de kullanabilirsiniz.
Hatta Model dosyanızda bunun için şöyle bir metod da yazabilirsiniz:

 public function durum()
 {
 return $this->attributes['ProjeDurum']==1 ? 'Devam Ediyor';
 // vs...
 }

Bunun blade içinde

$projes->durum();

getters da kullabilirsiniz:

 public function getProjeDurumAttribute($value)
 {
 return $this->attributes['ProjeDurum']==1 ? 'Devam Ediyor';
 // vs...
 }

Bunu da blade içinde

$projes->ProjeDurum;

olarak kullanırsınız.

sineld

Bunu yaparken şu ünlü cümleyi hatırlamakta yarar var: "Fat models and skinny controllers"
https://stackoverflow.com/questions/14044681/fat-models-and-skinny-controllers-sounds-like-creating-god-models

deathisonitsway

Ben modellerin controller icinde kullanılmasından yana değilim açıkçası; kullanımı evet doğru olabilir ama geliştirici bunu hunharca suistimal edebiliyor (aynı modelden alınan queryi tekrarlamak gibi) ben daha çok querylerin repository pattern şeklinde kullanılmasından yanayım.

Yalnış düşünüyor olabilirim; Fikrinize açığım.

Kevin-Mitnick

@sineld hocam durum u dödürürsem $projes->Durum şeklinde yazmam yetiyor mu yoksa ekstra birşeye gerek var mı ? modelde fazla deneyimim olmadı.

sineld

İlk örnek için;

{{ $projes->durum() }}

ikinci örnek için

{{ $projes->ProjeDurum }}

yazman yeterli.

Paranteze dikkat.

mgsmus

Ben de bu gibi durumlarda accessor tanımlıyorum. Böylece json çıktılarda model içerisinde public $appends değişkeni ile bunları da json dönüşe ekletebiliyorum
https://laravel.com/docs/5.6/eloquent-mutators#defining-an-accessor

@deathisonitsway
Repository pattern ile bir katman daha oluşturarak ilerlemeyi denedim, controller sadeleşti ama daha sonra (her zaman olmasa da) gereksiz fakat bana yük olan bir katman oluşturduğumu anladım.
Repository pattern kullanımının projenin büyüklüğü, hedefler, takım ve takımdaki geliştirici sayısı ve teslim/tamamlanma süresi gibi durumlara göre belirlenmesi gerektiğini düşünüyorum.
"Ayrıca bir de buna Adaptor katmanı ekleyelim ki ileride MySQL'den belki Oracle'a geçersek entegrasyon sorunu yaşamayalım" ise şu an gözümde sadece bir fantazi ve aşırı mühendislik.
Bir kere kontrolü kaybettiniz mi vaay dediğiniz şeyler size bloatware olarak geri dönebilir.

deathisonitsway

mgsmus yazdıBen de bu gibi durumlarda accessor tanımlıyorum. Böylece json çıktılarda model içerisinde public $appends değişkeni ile bunları da json dönüşe ekletebiliyorum
https://laravel.com/docs/5.6/eloquent-mutators#defining-an-accessor

@deathisonitsway
Repository pattern ile bir katman daha oluşturarak ilerlemeyi denedim, controller sadeleşti ama daha sonra (her zaman olmasa da) gereksiz fakat bana yük olan bir katman oluşturduğumu anladım.
Repository pattern kullanımının projenin büyüklüğü, hedefler, takım ve takımdaki geliştirici sayısı ve teslim/tamamlanma süresi gibi durumlara göre belirlenmesi gerektiğini düşünüyorum.
"Ayrıca bir de buna Adaptor katmanı ekleyelim ki ileride MySQL'den belki Oracle'a geçersek entegrasyon sorunu yaşamayalım" ise şu an gözümde sadece bir fantazi ve aşırı mühendislik.
Bir kere kontrolü kaybettiniz mi vaay dediğiniz şeyler size bloatware olarak geri dönebilir.

Ben zararını görmedim üstad ya; haklı olabilirsin ama.
Ben daha çok repository kullanıyorum modeller de çünkü o modelle ilgili tüm queryleri tek bir yerde görmek istiyorum.
Birde aşağıdaki gibi iki sınıfı baz aldığımızda


<?php 

namespace App;

class User extends Controller {

public function foo(){

 User::where()->get();
}

}


<?php 

namespace App;

class Comment extends Controller {

public function bar(){

 User::where()->get();
}

}

böyle bir şeyi kendi açımdan çok doğru bulmuyorum açıkçası; doğru scope kullanımları olursa okey diyebilirim ama her geliştirici böyle hunharca kullanabiliyor açıkçası; ben böyle bir koda denk gelmiştim açıkcası dışardan bir projeydi; bir modele is_deleted kontrolü eklemem gerekiyordu; ama musteri baska bir yerde çalışmadığını söylemişti.

O yüzden repository nin doğru olabileceğini düşüyorum.Hem denetleyiciyi sadeleştiriyor;
hem bir katman vasıtasıyla modelle ilişki kurduğumuz icin geliştirme boyutu biraz daha kolaylaşıyor diye düşünüyorum.
Bu benim düşüncem tabi.Yalnış olabilir.

mgsmus

Düşüncenizde bir yanlışlık yok. Verdiğiniz örnekteki kullanım değişiklik durumunda refaktör gerektiren bir durum, aynı zamanda kod tekrarı, kısacası tavsiye edilmeyen bir durum. Repository pattern kullanılarak bir UserRepository ile düzeltilebilir, öyle yapılması da önerilir, ben de öneririm ama işte küçük işlerde pratik ile gereksizlik arasındaki çizgi iyice kayboluyor. Havai fişek gösterisi gibi, 10 saniyelik gösterici için saatlerce hazırlanıyorsunuz. Benim demek istediğim 10 saniyelik gösteri için saatlerce hazırlanmama gerek yoktu, 2 dk içinde de halledebilirdim diyebiliyorsam 2 dk'lık yolu seçerdim.

Benim düşünce şeklim sadece saf bilgisayar başında kod yazmak ve teorik hareket etmekten ibaret değil (sizinki öyle ama diye bir şey kesinlikle kastetmiyorum, kendi durumumu belirtiyorum, yanlış anlaşılmasın), keşke öle olsaydı. Para, zaman, sözleşme, planlama... gibi iş hayatına dair bir çok faktör (ve elbette normal yaşantıma dair bir çok faktör) kod yazma şeklimi, proje yapımı etkiliyor. Sadece teorik konuşamıyorum yani. Kendi özel işlerimde hep yeni olanı kullanmaya çalışırım, trend olan ne var bakarım onu da öğrenmek için projeye dahil ederim ama çalıştığım yerin işi olursa işin boyutu değişiyor. Siz ofiste projede abstract abstract gezerken, bileşenleri namespaceleyip muazzam bir yapı kurduğunuzu düşünürken, bazı yerleri hoşunuza gittiği için pakete çevirirken bir anda toplantı yapılıp bu ay içinde bitmez ise zarar ediyoruz dendiğinde ya da takvime bakıp oha! ne zaman teslim süresine 1 hafta kaldı dediğinizde keşke fat controller olaydı diyebiliyorsunuz.

Japonca'da Tsundoku diye bir kavram var. Kitapları alıp alıp yığmak ama okumamak anlamına geliyor. Günde bir saat okusam yeter deyip de kitabı alıyorsunuz ama gerçek dünya buna izin vermiyor, daha yaprakları açılmadan evinizin bir köşesinde yatıyor. Sadece teorik hareket edince evinizde okunmamış kitaplardan bir kütüphane oluşuyor. Okumadığım bir kütüphane ego tatmininden, hava atmaktan başka benim ne işime yarar ki?

Ben burada yazılanları okurken "adamın bu işle ilgilenmek için sınırsız süresi var" şeklinde düşünüp cevap verseydim yazdığım tavsiyelerle işler bitmezdi, her şey karışırdı herhalde. Bakın design patternden nereye geldim. Neden? Çünkü bu Taylor denen adam Laravel'den kazandığı para ile Camaro SS almış geziyor. Sebebi design pattern değil, bu adamın uzmanlığı COBOL, sebebi proje yönetimindeki başarısı.

Farklı bir cevap oldu ama bu saatte normaldir

Kevin-Mitnick

teşekkürler herkese cevapları için dün biraz forumlara baktım hız açısından özellikle veya doğruluğu açısından modelde kullananlar insanlar çok fazla ama + getirisi olmadığını söylemişler hız açısından vs sadece kurallara uyduklarını belirtmişler.Blade tarafında kod fazlalığından kurtulmak en mantıklısı geldi model kullanımına daha çok özen göstereceğim bundan sonra teşekkürler.

deathisonitsway

@mgsmus nedense yazının sonuna geldiğimde; bitti mi ya diye bir hissim oldu emin olabilirsin

hemen hemen aynı düşüncelere sahibiz; hemen hemen az kalır cümlelerinin altına imza atmadıgım yer yok; maalesef ülkede para faktörü yazılımdan önce geliyor.Bunu bir türlü aşamıyoruz,aşacağımızıda düşünmüyorum hiç ümidim yok açıkçası.'Zarar ediyoruz -- dükkan dönmez yoksa ' gibi business tarafı söylemler; projeleri istenildiği formatta sürdürmüyor açıkçası.

Türkiyede cok iyi adamları hariç tutuyorum; genel manada frameworkler sadece framework kullandım oldu bitti manası taşımak için kullanılıyor ve projeler modern çöplüğe dönüyolar.Bizde yaptık yapmadık değil ama biz spagetti yazıyorduk; daha sonra codeigniterla tanıştı millet; ben biraz geç girdim bu düzene ama; girdiğimde bilinçliydim en azından.Detay yapa yapa bu seviyeye geldim.

Ne laravel kodları gördüm; taylor görse (ki bu adamı ön plana atmakta istemiyorum açıkcası) herhalde güler geçerdi.Ama developeri suçlayamıyorum işte; adam da böyle yazmak istemiyor olabilir.

ama daha sonra oturup aklıma clean code kitabında okuduğum cümleler geliyor.

Kod bozulur/çürür. Bazen kötü kod görürüz ve "Bunu temizlemeliyim" deriz. Bir sonraki düşüncemiz ise, "kesinlikle buna dokunmam" olur. Çünkü koda dokunursak, onu bozacağız. Onu bozarsak da suç bize kalacak. Korku, bizi kodu temizlemekten alıkoyar. Kötü kodu o şekilde bırakmak ise çürümeyi kaosa dönüştürür.
Bu kaos ise bizi yavaşlatır, her şeyi yavaşlatır. Değişiklikleri yapmak günler sürecekken haftalar sürmeye başlar. Kod tabanımızdaki belirsizlikler büyürken tahmin büyüklüklerimiz de artar ama yine de tahminlerimizi tutturamayız. Projeler bataklığa dönüşür.

#cleancode

bir clean code alıntısı daha yapayım;

Projelerin son teslim tarihi baskısı hiç azalmaz, müşterilerin sabır katsayısı birden bire pat diye düşmez, aciliyet hiç bitmez ve proje takvimi sizi asla rahat bırakmaz. Bu yüzden hiçbir zaman geriye dönüp kodu temizlemek gibi bir fırsatınız olmaz. Kodu baştan temiz tutup o şekilde ilerlemek gerçek anlamda hızlı gitmenin tek yoludur.

#cleancode

Herşeyi açıklıyor aslında; aslında sadece bizim memlekete has sorunlardan bahsetmiyor; genel bir izlenimden dolayı yazılmış cümleler bunlar.Aslında konu nereye geldi ama kaçınılmazdı buraya gelmesi.üstad zor işler bunlar.kod yazmak hiç önemli değil; alt alta yaz kodu çalışıyor zaten.İnsan iyi olanı yapabilmeli sorun burda.

İstenildiği kadar deadline bizi sıkıştırsın; kötü kod yazmaya hakkımız yok.Bazen stackover da soru sorarken; kodun commetine kadar güzel görünsün diye düzeltiyorum

neden çünkü kodumu görecekler; mahcup olmayayım.İyi ama projede bas geç.sorun yok.

Başa dönecek olursam; aslında developerin kaliteside projenin gidişini büyük ölçüde belirleyebiliyor.Örneğin ben yazdığım bir sınıfın tek iş yapmasına azami ölçüde önem veriyorum.yazdığım bir kod beni tatmin etmiyorsa; kolay ve yönetilebilir nasıl yazabilirim acaba diye zaman kaybettiğimde; bunun business tarafında kabul görmediğini anlıyorsun ve hemen detaysız düşünme ile yazma moduna geçiyorsun.Neden çünkü iş bitmeli. Daha sonra herhangi bir feature yada bugfix çıkıncada uğraşıp duruyorsun işte.Kendince mırıldanıyorsun neden böyle saçma sapan diye.Sabır ve zaman olmayınca o komplex kod tekrar komplexleşiyor ve kısır döngüye giriyor.

Burada anlatmak istediğim aslında; developer temiz gitmiyor; kullanılmak istenen teknolojiyi bilmediği için kod ister istemez bozuluyor ve dönülmez yollara giriyor.

Sonuç olarak; Ne kadar iyiysen kodun bozulması o denli zorlaşır.Kalite düzeyi iyi değilse; seni laravel symfony kurtarmaz.Daha çok rezil eder.O yüzden php bilgisine her zaman onem veririm.Nasıl yazıyorsan yaz ama var olanı en iyi şekilde kullan.

sineld

Burada aslında şöyle bir durum da var; kodun yeniden kullanılabilirliği. Yani bu örnekteki durum hem index'te, hem ilişkisel ekranda hem de show'da kullanılacaksa bunu model vs. bir yerde tanımlayıp kullanmakm son derece makul; hayır sadece bir yerde kullanılacaksa, mesela blade, orada ilk örnekteki gibi if veya switch kullanmak daha makul geliyor bana.

Pyrotoxin

@lang('status.project_'.$altprojes->ProjeDurum);

bir alternatif de bu şekilde kullanabilirsin.

sineld

Pyrotoxin yazdı

@lang('status.project_'.$altprojes->ProjeDurum);

bir alternatif de bu şekilde kullanabilirsin.