相信大家沒聽過Laravel也聽過別人吹捧Laravel XD
總之使用Laravel到現在大概過了一年，想說來記錄一下這一年來的想法和心得。
1. 強迫改變習慣
以前沒有用框架的時候，因為比較沒有限制，想怎麼做就怎麼做，經常在不同地方會有不一樣的做法。
換了Laravel後，一部分是因為框架的限制，限制你的程式要怎麼擺放，類別大概要長怎麼樣，不照著做的話有些機制會沒辦法運作，所以只能照著做。
二來則是因為，想說大家都這麼推崇Laravel，想必它的規範或做法，一定有它的道理所在，所以就會逼自己用Laravel的思維去撰寫程式，試著去體會Laravel帶來的好處。
而且，也比較容易要求團隊成員，遵循一致的規範。因為人家文件都幫你寫好了，只要請團隊成員遵照官方文件就好XD
漸漸地一些以前不好的開發習慣就改掉了。
2. 強迫學習新知
Laravel使用很多PHP的語言特性，跟物件導向開發的概念與技巧，而有些Laravel的功能，其實也隱含了許多已知的解決方案，如果把這些東西都學習起來，不但開發能力可以提升，對於整個Web應用的生態系，也可以有更多的了解。
比如說IoC Container，讓你可以方便地實現依賴注入，但是可能在此之前，你根本沒聽過依賴注入，所以不懂這個東西怎麼用。
為了學會使用這個Container，就要去學習什麼是依賴注入，然後，在這樣的基礎上去延伸，去接觸到SOLID或一些物件導向開發的原則。
或又像是event、queue的，看到了就會想用用看，但又不知道怎麼用，所以就要去看文件，或是去看soruce code，從中學會概念跟用法。
再舉一個例子，如果試著去看懂Laravel Request的生命週期，從request的產生，經過middleware，到controller，看懂了這一整個流程，就可以體會什麼叫做現代的Web框架了。
3. PHP基礎的重要性
如前面所提，Laravel使用了很多PHP的語言特性，所以不熟PHP的話，很容易搞不清楚「魔法」發生的原因，這樣debug常常會陷入無底深淵（？）
再來，「框架」通常是為了某種應用情境而生的，而Laravel就是為了Web Application而產生的，如果只是學會了Laravel，知道的Model、Controller、View、Route這些Web開發的概念，卻沒辦法理解框架實作的細節(aka 沒有閱讀Source Code的能力)，那就太可惜了。
4. 框架不是萬靈丹
可以從幾個問題來探討。
框架可以解決系統複雜度過高的問題嗎？
我認為框架在一開始，確實可以解決這個問題，但是如果概念不對、或是習慣沒有更改，即便有框架的協助，隨著系統的增長，也容易寫出可怕的東西。
比如說，大量重複的程式分散在各個Controller，而沒有用適當的方式將程式分層、分類整理，或是在router中，為求方便以closure的形式寫出上百行的View。
這樣的話，並沒辦法解決複雜度過高的問題。
框架可以提高開發速度嗎？
我覺得這個有幾個前提，
一、要對於Laravel有一定熟悉度
二、要維持良好的習慣跟系統架構
如果對Laravel不熟，或是沒人帶，一開始鬼打牆，反而導致開發速度變慢。
如果沒有維持良好的規範或架構，隨著複雜度指數型成長，程式品質持續低落，一樣會有維護難度越來越高的問題，開發速度自然就提高不了。
所有的應用情境都適合用Laravel嗎？
答案是不，Laravel為了能夠讓各種系統跟工具都能夠良好的整合，所以用了很多設計技巧，好處是，可以快速在不同開發環境下跟不同工具做整合，但壞處是，如果今天想要對某些情境做優化，就會受限於框架，綁手綁腳的。
我會覺得Laravel比較適合中小型專案，如果預期專案會成長成超大型專案，可能Laravel不一定會適合，要審慎評估。
反正框架不是萬靈丹，不要以為用了框架什麼問題就都解了XD
結論
我覺得用了Laravel一年，覺得最大的收穫就是追了大量的Source Code，了解神人們是怎麼活用PHP，還有怎麼妥善的運用各種設計來解決問題的。
雖然有時候還是會被Laravel的設計給氣到，明明只是要處理一個簡單的問題，卻包了很多層，但這也是這樣的「泛用型」框架的小缺失吧。
總體而言，Laravel的確給了不錯的方向，也的確是蠻好用的，但就像減肥如果只是運動，沒有搭配良好的飲食習慣，也是瘦不下來。如果只是用了Laravel，卻沒有持續提升自己的能力，或是改變自己的習慣，而濫用Laravel的方便，一樣會寫出可怕的程式。