到了倒數第二天，一直在想自己該寫什麼，在參加這個比賽之前，自己常埋首在自以為是的開發中，無論遇到什麼問題就是不斷地的解決 bug，並製造更多 bug，很少會去找這些問題的源頭，也很少會去了解 bug 的發生原因，但這個寫文章的自我挑戰，讓我自己看到在技術能力上的盲點以及不足，在翻閱官方文件時，總會看到一些自己在開發上錯誤的用法，原來我已落入了達克效應的過度自信區卻不自知，以前總認為框架是套工具，可以利用它快速建立專案，但是像 Laravel 這種設計完整的後端架構，若不照著它的規範進行開發，不過就是在把自己的髒 code 丟到框架上，反而不夠簡潔（對，我說的就是把所有功能和業務邏輯都寫在 Controller 的你我），失去這個框架當初被設計出來的初衷。
達克效應，圖片來源：陳品皓臨床心理師 粉絲專頁
不過想像自己正在往累積更多技能及經驗的方向前進，還是很令人興奮的。
這邊主要是希望能夠記錄一下自己在開發專案的時候常會犯的錯誤，作為警惕。
寫作風格不按照 PSR 規範
PSR（PHP Standards Recommendations）是 php-fig 提出的 PHP 程式寫作風格，其實不按照這個風格寫作也沒差，程式大部分都還是跑得動，但是當你的專案越來越大，且越來越多開發人員加入時，會導致風格不一，難以維護，如果去看 Laravel 的原始碼，可以發現他們的寫作風格都有依照這個規範。
過度依賴資料庫管理工具
phpmyadmin 或是我常用的 DBeaver 都是相當方便用來操作資料庫的工具，但過度依賴這些工具，且不了解底層資料庫操作語法，很容易讓你在誤改資料庫結構時改不回去，另外 Laravel 也有提供 Migration 這個方式建構你的資料表，因此如果要見資料表或是修改架構，都建議使用 Migration 統一操作。
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 一直以來的一個大問題。
過度依賴 Laravel Helpers
Laravel Helpers 封裝了很多 PHP 的原生函式，讓你在使用 Laravel 時與其他的語法更貼近，且更加方便，不過既然他多封裝了一層，因此多少犧牲了一些些效能，而且許多人在公司可能不只維護 Laravel 專案，可能有些專案是使用其他框架或是純 PHP 寫的，反而導致你不容易習慣使用原生的 PHP 用法。記得，我這邊都是講不要過度依賴，並不是說這些工具不好，而是要曉得這些工具使用的原因以及目的，才不會讓自己陷入達克效應的自信（蠢）區間。
功能、業務邏輯全部都寫在 Controller
這也是我剛學 Laravel 等 MVC 框架會發生的問題，因為實在太方便，只好都寫在一起，程式就神奇的動起來了，但是 Laravel 有提供很多的方式處理不同需求，如要檢查進入 Routes 的請求，可以利用 Middleware；要寫抽象的業務邏輯，可以利用 Service Providers 等等。Controller 可以專心處理 Model 與 View 的請求及資料就好。
不寫測試
人工測試也許比較貼近人，但很浪費時間，你總不可能在加入新功能時，還要測試登入功能有沒有依賴問題吧，所以一些已經開發完成的功能都建議將測試寫完整，這樣在專案上 Production 時也能保證沒有問題。
明明是 RDBMS 系統，資料庫卻不設關聯
Migration 真的很方便，你要設定外鍵跟 Index 都不會太難，所以花點時間把資料庫關聯建好是必要的，如果只使用 Eloquent 提供的關聯功能是不且實際的，應該兩個地方都要做。
以上是目前開發 Laravel 專案時曾踩過的雷以及心得，希望對大家有幫助，這類的文章可以參考 Recca 大大的鐵人賽文章 - 如何用 Laravel 撰寫難以維護的專案。
iThome鐵人賽
看影片追技術