iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 29
1
自我挑戰組

Laravel 實戰經驗分享系列 第 29

Laravel 實戰經驗分享 - Day29 剩下最後的兩篇,該講些什麼呢?

到了倒數第二天,一直在想自己該寫什麼,在參加這個比賽之前,自己常埋首在自以為是的開發中,無論遇到什麼問題就是不斷地的解決 bug,並製造更多 bug,很少會去找這些問題的源頭,也很少會去了解 bug 的發生原因,但這個寫文章的自我挑戰,讓我自己看到在技術能力上的盲點以及不足,在翻閱官方文件時,總會看到一些自己在開發上錯誤的用法,原來我已落入了達克效應的過度自信區卻不自知,以前總認為框架是套工具,可以利用它快速建立專案,但是像 Laravel 這種設計完整的後端架構,若不照著它的規範進行開發,不過就是在把自己的髒 code 丟到框架上,反而不夠簡潔(對,我說的就是把所有功能和業務邏輯都寫在 Controller 的你我),失去這個框架當初被設計出來的初衷。


達克效應,圖片來源:陳品皓臨床心理師 粉絲專頁

不過想像自己正在往累積更多技能及經驗的方向前進,還是很令人興奮的。

盤點一下自己在開發的時候常會犯的錯

這邊主要是希望能夠記錄一下自己在開發專案的時候常會犯的錯誤,作為警惕。

  1. 寫作風格不按照 PSR 規範
    PSR(PHP Standards Recommendations)是 php-fig 提出的 PHP 程式寫作風格,其實不按照這個風格寫作也沒差,程式大部分都還是跑得動,但是當你的專案越來越大,且越來越多開發人員加入時,會導致風格不一,難以維護,如果去看 Laravel 的原始碼,可以發現他們的寫作風格都有依照這個規範。

  2. 過度依賴資料庫管理工具
    phpmyadmin 或是我常用的 DBeaver 都是相當方便用來操作資料庫的工具,但過度依賴這些工具,且不了解底層資料庫操作語法,很容易讓你在誤改資料庫結構時改不回去,另外 Laravel 也有提供 Migration 這個方式建構你的資料表,因此如果要見資料表或是修改架構,都建議使用 Migration 統一操作。

  3. Migration 不只寫 up,更要寫 down
    資料表怎麼建的就要怎麼 rollback,我也曾看過不寫 rollback 的專案,維護起來很痛苦,因為當我要修改架構,在確認的時候 rollback 要嘛沒用要嘛噴錯,因此大家還是要了解這個方法被設計的目的是什麼,不要只會使用一半的功能,這樣很可惜。
    過去也有一個問題是專案越來越大,Migration 檔案就會越來越多,這個問題在今年九月推出的 Laravel 8 有了解答,Migration Squashing 利用指令 php artian schema:dump --prune,讓你在修改資料庫結構後將 Migration 檔案全 dump 成 .sql 檔案,並且清掉 Migration,之後再執行 php artisan migrate:fresh 時,也會先執行這個 dump 出來的檔案,再執行新的 Migration 檔案,並且加入到 .sql 檔中,可以說是解決了 Migration 一直以來的一個大問題。

  4. 過度依賴 Laravel Helpers
    Laravel Helpers 封裝了很多 PHP 的原生函式,讓你在使用 Laravel 時與其他的語法更貼近,且更加方便,不過既然他多封裝了一層,因此多少犧牲了一些些效能,而且許多人在公司可能不只維護 Laravel 專案,可能有些專案是使用其他框架或是純 PHP 寫的,反而導致你不容易習慣使用原生的 PHP 用法。記得,我這邊都是講不要過度依賴,並不是說這些工具不好,而是要曉得這些工具使用的原因以及目的,才不會讓自己陷入達克效應的自信(蠢)區間。

  5. 功能、業務邏輯全部都寫在 Controller
    這也是我剛學 Laravel 等 MVC 框架會發生的問題,因為實在太方便,只好都寫在一起,程式就神奇的動起來了,但是 Laravel 有提供很多的方式處理不同需求,如要檢查進入 Routes 的請求,可以利用 Middleware;要寫抽象的業務邏輯,可以利用 Service Providers 等等。Controller 可以專心處理 Model 與 View 的請求及資料就好。

  6. 不寫測試
    人工測試也許比較貼近人,但很浪費時間,你總不可能在加入新功能時,還要測試登入功能有沒有依賴問題吧,所以一些已經開發完成的功能都建議將測試寫完整,這樣在專案上 Production 時也能保證沒有問題。

  7. 明明是 RDBMS 系統,資料庫卻不設關聯
    Migration 真的很方便,你要設定外鍵跟 Index 都不會太難,所以花點時間把資料庫關聯建好是必要的,如果只使用 Eloquent 提供的關聯功能是不且實際的,應該兩個地方都要做。


以上是目前開發 Laravel 專案時曾踩過的雷以及心得,希望對大家有幫助,這類的文章可以參考 Recca 大大的鐵人賽文章 - 如何用 Laravel 撰寫難以維護的專案


上一篇
Laravel 實戰經驗分享 - Day28 API 文件的寫法
下一篇
Laravel 實戰經驗分享 - Day30 回頭看看,以及未來要幹嘛
系列文
Laravel 實戰經驗分享30

尚未有邦友留言

立即登入留言