Buggy CakePHP Kodu: CakePHP Geliştiricilerinin Yaptığı En Yaygın 6 Hata
Yayınlanan: 2022-03-11CakePHP harika bir PHP çerçevesidir, ancak dik bir öğrenme eğrisi vardır! Uzman olmak için iyi miktarda araştırma ve eğitim gerekir.
7 yılı aşkın bir süredir CakePHP'yi kullandığım için şanslıyım ve bu süre içinde CakePHP topluluğunun birçok üyesiyle çalışma onuruna sahip oldum.
Bu CakePHP eğitiminde, yıllar içinde gördüğüm birkaç kötü uygulamayı açıklamak ve bu hatalardan kaçınmak için doğru yaklaşımı önermek istiyorum. Bu, kodumun mükemmel olduğu anlamına gelmiyor, ancak bir programcı olarak her zaman öğreniyoruz, bu nedenle en iyi uygulamaları takip etmek ve öğrendikçe uyum sağlamak önemlidir!
Bu makalenin içeriği CakeCoded'dan bir gönderiden esinlenmiştir. CakePHP hakkında daha fazla bilgi edinmek isterseniz, lütfen buradaki öğrenme bölümümüzü ziyaret edin.
Yaygın Hata 1: CakePHP Kodlama Kurallarına Uymamak
CakePHP kodlama kuralları burada görüntülenebilir. Diğer programcıların kodunu görüntülerken sıklıkla fark ettiğim birkaç şeyi vurgulayacağım.
Kontrol Yapıları. Sıklıkla programcıların bunu yanlış anladığını ve bazı durumlarda diğer kodlama dillerinden uygulamalar getirdiğini görürsünüz. CakePHP aşağıdaki sözdizimini bekler:
if ((expr_1) || (expr_2)) { // action_1; } elseif (!(expr_3) && (expr_4)) { // action_2; } else { // default_action; }
İlk parantezden önce 1 (bir) boşluk, son parantez ile açma parantez arasında 1 (bir) boşluk olmalıdır. Yani bu, aşağıdakilerin yanlış olduğu anlamına gelir:
if($this->request->data){ }
if
ve (
, ve arasında )
ile {
arasındaki boşluğa dikkat edin.
Gerekli olmasa bile kontrol yapılarında her zaman küme parantezleri kullanın. Kodun okunabilirliğini artırırlar ve size daha az mantıksal hata verirler.
Bu nedenle, örneğin, aşağıdakiler yanlıştır:
if ($foo) $bar = true
Bu, şu şekilde biçimlendirilmelidir:
if ($foo) { $bar = true }
Son olarak, parantezleri nereye yerleştirdiğinize dikkat edin. Parantez açmak yeni bir satır başlatmamalıdır. Ve tüm parantezlerinizin hizalandığından emin olun, böylece her yeni braket kapanış braketi ile aynı hizada olur.
İşte bazı yanlış örnekler:
if ($foo) { $bar = true; }
Bu yanlıştır, açılış ayracı ilk satırda olmalıdır:
if ($foo) { $bar = true; if ($action) { $to = false; } }
Girinti doğru şekilde hizalanmalıdır.
Programcıların sık sık "Ama kodu düzgün hale getirmek için çok meşgulüm..." dediğini duyuyorum. Cevabım, "Güven bana, temiz kod zamanın testine dayanacak". Okunamayan CakePHP kodu yazmak, birkaç ay içinde bir değişiklik yapmanız gerekirse geri dönmek için bir kabus olacaktır.
Yaygın Hata #2: ORM'de Kapsanabilir Davranışların ve Özyinelemeli Düzeylerin Uygunsuz Kullanımı
Geçenlerde Facebook'tan bir veritabanı geliştiricisiyle gayri resmi bir tartışma yaptığım için şanslıydım. CakePHP hakkında konuşmaya başladık ve bana dedi ki, “Oh, bu ORM kullanıyor değil mi? Bu korkutucu olabilir." Ona ne demek istediğini sordum ve o, Nesne-ilişkisel eşleme (ORM) ile SQL sorgularının gereksiz yere büyük olmasının kolay olduğunu söyledi.
O bir bakıma haklı. CakePHP'nin sihrinin bir kısmı, ORM kullanımında ve farklı veritabanı tablosu ilişkilerini birlikte gruplama biçimindedir. Varsayılan olarak, CakePHP ilgili herhangi bir 'Aittir', 'Biri Var' ve 'Çok Sayıda' verisini otomatik olarak seçer ve bu çok büyük SQL sorgularına yol açabilir. Bu sorgular, başlangıçta bir uygulama geliştirirken bir endişe kaynağı olmayabilir, ancak altı aylık canlı veri toplamanın ardından, uygulamanın çok yavaşladığını ve sorgular optimize edilmezse bazı durumlarda çöktüğünü görebilirsiniz.
Mevcut bir web sitesini denetlerken iki şeye dikkat ederim. İlk olarak, varsayılan özyinelemeli seviye değiştirildi mi? Varsayılan olarak CakePHP özyinelemeli seviyeyi 1'e ayarlar ki bu bence çok yüksek. Her zaman -1'e ayarlıyorum ve ardından ilgili modelleri almak için kapsayıcı davranışı kullanıyorum.
Bu, aradığım ikinci şeye yol açar - Kapsanabilir davranış kullanılmış mı? Bana sık sık yeni müşteriler geliyor ve CakePHP'nin yavaş olduğunu söylüyorlar. Bunun nedeni neredeyse her zaman, Containable'ın kullanılmamış olmasıdır! İyi bir CakePHP programcısı, sahne arkasında ne kadar “otomatik sihir” yapıldığından bağımsız olarak SQL sorgularını optimize edecektir.
Kapsanabilir davranış CakePHP 1.2'ye kadar eklenmemişti, ama bu bir fark yarattı mı?! SQL'inizi optimize etmenin çok etkili bir yolu olduğundan, mümkün olduğunca kapsayıcı kullandığınızdan emin olun. Containable davranışının nasıl uygulanacağı ve kullanılacağı hakkında daha fazla bilgi için burayı tıklayın.
Yaygın Hata #3: İş Mantığını Modeller Yerine Denetleyicilerde Tutmak
İyi CakePHP kodu, model dosyalarında mantığa sahip olacaktır. Buna alışmak biraz zaman alıyor, ancak bir kez ustalaştıktan sonra geriye bakmak yok! MVC modelinde amaçlanan şey için bir denetleyici dosyası kullanılmalıdır - kontrol! Bu nedenle, iş mantığının model dosyasına girmesine izin verirken, kullanıcı eylemlerini işlemek için denetleyici dosyanızı kullanın.
Bunun iyi bir örneği basit bir CRUD olabilir - günlük bir eylem! Örnek olarak bir blog eğitimindeki gönderi ekleme işlevini ele alalım. Varsayılan ekleme işlevi aşağıdaki gibidir:
public function add() { if ($this->request->is('post')) { $this->Post->create(); if ($this->Post->save($this->request->data)) { $this->Session->setFlash(__('Your post has been saved.')); return $this->redirect(array('action' => 'index')); } $this->Session->setFlash(__('Unable to add your post.')); } }
Bu denetleyici eylemi basit bir ekleme için uygundur, ancak bir gönderi eklendiğinde yöneticiye e-posta göndermek veya bir gönderi eklendiğinde başka bir model ilişkilendirmesini güncellemek gibi şeyler yapmak isteseydiniz ne olurdu. Bu ek mantıktır, ancak bu mantık denetleyici dosyamıza girmemelidir.
Bunun yerine Post.php
modelimizde bunun için bir fonksiyon yazardık. Belki şöyle bir şey:
public function addPost($data = array(), $emailAdmin = true) { $this->create(); $this->save($data); // update any other tables // send the email to the admin user if ($emailAdmin) { } // if all is successful return true; }
Bu, daha sonra denetleyici eyleminde aşağıdaki gibi küçük bir değişiklikle sonuçlanır:

public function add() { if ($this->request->is('post')) { if ($this->Post->addPost($this->request->data)) { $this->Session->setFlash(__('Your post has been saved.')); return $this->redirect(array('action' => 'index')); } $this->Session->setFlash(__('Unable to add your post.')); } }
Gördüğünüz gibi, yeni eylem aslında bir satır eksik, çünkü $this->Post->create()
model dosyasına taşındı.
Bu, model dosyasına mantığın taşınmasının iyi bir fikir olduğu mükemmel, günlük bir örnektir - ve kesinlikle çok daha temiz bir kod tabanı sağlar!
Yaygın Hata #4: Sıkça ve Erken Dönmek Yerine Kurallara Çok Fazla Karmaşıklık Eklemek
Bu her zaman biraz devam eden bir tartışmadır, ancak sık sık geri dönmek ve erken dönmek kesinlikle çok daha temiz görünen bir kod yapar. Bu, model yöntemleri için her şeyden çok geçerlidir.
Ama tam olarak ne demek istiyorum? Pekala, yukarıdaki CakePHP eğitiminde eklediğimiz yönteme bir göz atalım:
public function addPost($data = array(), $emailAdmin = true) { $this->create(); $this->save($data); // update any other tables // send the email to the admin user if ($emailAdmin) { } // if all is successful return true; }
Sık sık geri dönmek ve erken dönmek, fonksiyonumuzdan geçerken, her şeyin yolunda olduğundan emin olmak için düzenli olarak kontrol etmemiz anlamına gelir. Değilse, false döndürürüz veya bir CakePHP hatası döndürürüz.
Bunu bir örnekle göstermek en kolayı olabilir. Yukarıdaki işlevin yazılabilmesinin iki yolu vardır:
public function addPost($data = array(), $emailAdmin = true) { if ($data) { $this->create(); $result = $this->save($data); if ($result) { // update any other tables // send the email to the admin user if ($emailAdmin) { // send the admin email } } else { // problem saving the data return false; } // if all is successful return true; } else { // no data submitted return false; } }
Kodun nasıl hızla okunamaz hale geldiğini gördünüz mü? Her yerde if
s ve else
s vardır ve işlev hızla büyük bir girintiye dönüşür. Beni yanlış anlama, temiz girintiyi seviyorum, ancak işlevin dönüş ile sık sık yazılması durumunda nasıl göründüğüne bakın, erken dönüş ilkesi.
public function addPost($data = array(), $emailAdmin = true) { if (!$data) { // no data submitted return false; } $this->create(); $result = $this->save($data); if (!$result) { // problem saving the data return false; } // update any other tables // send the email to the admin user if ($emailAdmin) { // send the admin email } // if all is successful return true; }
Hemen, bu küçük örnekte, kodun yalnızca tek bir girintiye sahip olduğunu ve çok daha okunabilir olduğunu görebilirsiniz. Mantık aslında daha mantıklı - mantığın satır satır çalışmasına izin verin ve yol boyunca herhangi bir sorun varsa, hatayı döndürün ve bir sonraki satıra geçmeyin.
Bu, CakePHP programcısının bizim okuduğumuz gibi yazmasına olanak tanır - kodu farklı bloklar yerine soldan sağa, yukarıdan aşağıya okuma, bu da hızla kafa karıştırıcı olabilir!
Yaygın Hata #5: KURU Prensibini Kullanmamak
DRY, Don't Repeat Yourself anlamına gelir ve CakePHP'de kod yazarken uyulması gereken bir felsefedir. Nesne yönelimli kodda, aynı kod bloğunu iki kez tekrarlamak için hiçbir mazeret yoktur!
Kendinizi tekrar etmemenizi sağlayacak birkaç CakePHP ipucu:
Yukarıda bahsedildiği gibi, mantığı paylaşabilmeniz için mantığı model dosyalarına koymayı hedefleyin.
Görünüm dosyalarınızda, görünümleri tekrarlıyorsanız, görünüm kodunu bir Öğe veya hatta özel bir yardımcı olarak oluşturun.
Bazı yapılandırma ayarlarını yapın -
app/Config/bootstrap.php
dosyası bunun için harika bir yerdir. Bu, uygulama adı ve ana e-posta adresi gibi şeyleri zor kodlamadığınızdan emin olmanıza yardımcı olur. İstemci bir uygulamadaki bir e-posta adresini güncellemek istedi diye yapmak isteyeceğiniz son şey yüzlerce dosyayı gözden geçirmektir.Her zaman kendinize sorun, "Eğer kodu tekrarlıyorsam, bu kodu yazmanın daha iyi bir yolu var mı ve bu kodu doğru yere mi koyuyorum?" Muhtemelen, kodu tekrarlamanız gerekirse, daha iyi yazılabilir.
Yaygın Hata #6: Kodu Yorumlamamak
Son olarak yorum yapacağım nokta. İlk olarak, belge engelleme. Belge bloğu, bir yöntemi veya eylemi belgelediğiniz zamandır. Bir fonksiyonun ne yaptığını biraz kaydetmek sadece bir dakika sürer, ancak kodun okunabilirliği açısından böyle bir fark yaratır.
CakePHP Doc Blocks, sayfanın sol kenarına doğru gitmelidir. Yani yukarıdaki kodu kullanarak basit bir örnek.
/** * Adds & saves a post as well as emails the admin to let them know the post has been added. * Also performs some saving to another table * * @param array $data The post data * @param bool $emailAdmin If set to true, will email the website admin * @return bool Returns true if successful */ public function addPost($data = array(), $emailAdmin = true) {
Göreceğiniz gibi, bir doc bloğu yazmak uzun sürmüyor, ancak kodun uzun ömürlülüğü açısından büyük bir fark yaratıyor. Sonuç olarak, kodun geliştirici olarak sizin geçmişinizde yaşayabileceği anlamına gelir.
Aynı şekilde satır içi yorumlarda. Kodunuzun ne yaptığını ve nedenini açıklamaktan korkmayın! Özellikle başka bir geliştirici bakıyorsa, uzun vadede kodunuzu anlamanızı çok daha kolay hale getirir!
Sarmak
CakePHP kapsamlı, tam özellikli bir çerçevedir. Konfigürasyon üzerindeki kuralı takip ettiği göz önüne alındığında, CakePHP diğer PHP tabanlı çerçevelerden daha katıdır, bir kullanıcının kodu düzenlemenin belirli bir yolunu izlemeye "zorlanması" anlamındadır. Bu tartışmalı olabilir, ancak benim deneyimime göre daha tutarlı, okunabilir ve anlaşılır bir kod tabanına yol açar - bir geliştiricinin kodun nasıl yazılacağını “seçmesine” izin vermek yerine, bir geliştirme ekibi Cake'in kurallarını izleyerek tutarlı kod yazacaktır. .
Bu CakePHP eğitimini takip ederek ve kodunuzun iyi yazıldığından emin olarak, uygulamalar zamanın testine dayanabilir. Kod her zaman yarın için yazılmalıdır - böylece başka bir geliştirici yıllar sonra belirli bir kod bloğuna bakıyorsa, kodu anlayacak ve beklenen standartlara bağlı kalacaktır. CakePHP de farklı değil ve umarım bu kılavuz bazı kötü alışkanlıkları düzeltmeye yardımcı olur.