最近在學著使用前端框架來處理前端頁面的呈現，同時也拿來當成授課的內容，帶著學生實作了一個範例，不過只是把Vue.js引入後做一些資料綁定的動作，展現給學生了解使用框架和先前的做法有什麼差異。

這兩天則是自己把組件的部份玩了一下，同時把自己的一個案子做了修改，整個改下來的心得就是HTML / CSS / JS可以切得很乾淨，在維護上和後續功能的維護上的確帶來了方便，而且不用再去擔心資料異動時的DOM更新問題；但是整體程式碼並沒有少很多，主要是因為不同的開發方式，各自有不同的細節要注意，因此單就程式碼的撰寫工作上並不一定真的會有所減少，或更輕鬆，不過這個問題我有和學生解釋邊際效應的狀況，因為目前我們課程中練習的範例規模都不大，因此很容易會發生這種使用了框架或物件導向時，似乎沒有比直接原生寫來得省工或乾淨的感覺，但是當開發的規模到達一定程度時，這些不同的開發方式的效益才會顯現出來。

另一個心得就是重構的問題，目前我還只是在現有的案子上引入vue.js來使用，同時還搭配Jquery來處理一些ajax及dom的操作，相比之前在js 裏夾雜一堆html及css來說，目前的架構己經改善很多了，但是我為了快速套用，所以每個功能模組都單獨產生一個Vue的實例來運作，然後再利用實例之間互相丟資料來維持功能和先前的做法一致，理想的做法是整個網站都納入Vue.js的控管之下，儘可能把網站的內容都拆成組件來使用，這需要整個重構，但這樣做之後相信會更清爽及好維護。

最後我還沒空使用到Vue-router,Vue-x，等下個月有空再來研究看看，相信對於前端的網頁內容控制會更有幫助。

上一次的練習真的是從零開始，看完一門線上課程加上一點GOOGLE就開始動手做了，做的過程中發現問題才再回頭翻書找資料，而且也只做完後台而已，在寫完三篇心得後，我又花了大概兩天左右的時間把題目重新做了一次，這一次採用的是比較中規中矩的做法，每一張資料表相關的控制器，模型及視圖都獨立開來做，光路由就寫了46條路由，模型九個，控制器11個，視圖10個，中介層1個，服務供應者1個，整個做下來最花時間的地方是在視圖上，因為後台的視圖我還是嘗試要用一個檔案來搞定，這使得語法上變得有點複雜，下一次簡化應該會從這方面著手，就像我在之前的心得中提到的，用框架來做開發，就不要再擔心檔案太多的問題了。

重做一次的心得是框架可以幫助讓整個網站的架構比較清楚，負責邏輯的和負責資料庫的以及負責顯示的，都切得乾乾淨淨的，不像以前原生寫法那樣一個檔案中同時有PHP又有HTML又有JS，要查問題時很花時間，要修改時也要很小心；但是框架並不完全那麼美好，比如我在session和登入驗證上就花了點時間去研究，才能做出我想要的結果來，比如登入驗證的功能，內建的機制雖然很方便，但如果只依靠內建的來實踐功能，很多事反而會受到限制，題目要求的登入很簡單，不需要太多驗證，我想跳過內建的機制，但沒有相關的資訊，網路上找到的全是告訴你登入很簡單，內建就有，你CODE都不用寫就做好了，但我要的是不同的驗證方式，卻沒有相關的資料可以參考，所以使用框架在我目前的程度來看，一點也不輕鬆；我認為框架在後續的維護上是有一定價值的，但像檢定或比賽之類的場合，框架不一定有優勢，除非刻意的去忽視這些規範，用硬幹的方式在框架內做一些扭曲的應用，這樣的話的確能在速度上取得好處，比如今年的全國技能競賽有一個題目的資料庫查詢語法，用框架反而做不出來，最後大家都是用原生的查詢語法下去做。

在這兩次的試解中，其實我花在找資料和看畫的時間上幾乎是解題時間的兩倍，原因是網路上找到的東西大多只是重覆官方提供的範例再解釋一次而己，如果我想做的功能和官方提供的不太一樣，就幾乎找不到解答，我只能自己想辦法去試出來，所以我覺得學習成本上並沒有比較低，而且還得對程式語言有一定基礎的人，才有辦法從框架的官方說明或原始碼中去找到問題，然後完全的掌控整個框架工具的使用，像是session的使用，之前看的課程或資料都沒提到這塊，我想要做到的功能只能自己去試出來，即使是stackoverflow上的資訊有些也是文不對題。

後續的計畫是用laravel 把乙級四個題目做一篇，當成未來教學的教材之一，接下來是研究比較有歷史的Codeigniter，這樣的話，整個網頁乙級術科的解題就完整了。

這兩天雖然累，但還是花了點時間把一些其它的功能試了一下，主要是解決了後台的刪除資料功能，然後也解決了前台的blade include功能，不過這和原生的include並沒有太大差異，只不過解決了這個問題後，我才發現我必須整個解題重做，不然不但無法發揮laravel的特性，反而會讓整個解題的過程和體驗變糟了。

先前我說過blade在處理前端頁面時非常好用，但我錯了，今天在處理不同功能呼叫同一個VIEW時，卡了很久，主因在於我先前的做法還是照著我原生解題的邏輯，所以我把所有view會用到的功能都丟在一個陣列中，然後view會依照我route的設計來顯示需要的內容，因此我的view中使用了switch的方式來判斷要顯示的內容，雖然相比之前的4,500行少了很多，但是這招在後台有用，到了前台就沒用了，我得製作同樣的樣板來搭配前台的不同路由，雖然最終還是做得出來，但是我自己也感覺到這樣的開發方式是有問題的，因此我打算先停手目前的解題，重新做一次題目；先前我是因為對於拆多個檔案的管理方式感到恐懼，所以才會想要儘量把程式碼都集中在一個檔案來處理，不過到了laravel，觀念需要轉一下，所謂檔案就是類別或物件，不再需要像原生開發那樣，擔心檔案一多，連結和導向的管理變得混亂；在laravel中，一個Controller中己經把常用的幾種function都建好，應該專注在單一功能的實踐上就好了，而不需要去擔心檔案的從屬關係，而View則是專注在佈局和內容的呈現上，而不需要擔心這次要顯示的功能是什麼，所以要額外判斷，然後特別去產生不一樣的內容；應該要更大擔的把需要的內容都物件化，讓laravel去管理路由和一些組件關係就好了。

最後在處理Session時，發現laravel的session管理有自己的一套模式，並非是延用PHP原生的管理方式，比如設定檔中有一項設定可以設定要不要在瀏灠器關閉時讓session立刻過期，照題目的要求，這個設定是要打開的，但從這個設定來看，就可以得知和原生的做法不同，原生的Session在關閉瀏灠器後，並不會馬上過期，但是當使用者再連上網站時，PHP會建立一個新的session，這是符合題目要求的，不關閉瀏灠器的狀況下，瀏灠次數不會更新，關閉瀏灠器後再連上才會更新瀏灠次數的要求；但是laravel預設會記住使用者的連線紀錄，所以就算關閉瀏灠器，只要session還沒過期，再次連上網站還是會有效。

另一個問題是我在處理前端時，其實有不少的值是共用的，但是照我原本的寫法，我得在每次要建構View時，都去再撈一次資料，然後再從各個Controller丟去View做顯示，做到這我也自己知道做錯了，這和原生解題時寫一個base.php，然後每個頁面都要先include這個檔案沒什麼兩樣，等於是在瀏灠各頁面時都要去資料庫再撈一次資料一樣的意思，後來終於找到laravel有一個service povider的功能可以使用，白話點說，就是可以利用這個機制來建立整個網站的全域變數，像是標題圖片的位置，瀏灠次數，頁尾版權，前台的選單及校園映象圖片這些在很多畫面會共同用到的資訊，可以建一個全域變數來放著，然後View就可以直接把變數拿來使用，然後各個Controller在建構View時，只要專注在提供自己專有的資料就好了，不需要再去把共同的資料再撈一次。

總結這一周研究Laravel框架的心得就是的確可以在開發上簡化不少工夫，但這過程並不如許多推廣者所說的那樣無痛而美好，就我個人來說，單看網路上的教學都是功能單一的內容，所以看起來好象真的很容易，但是像我這樣拿一個完整的網站範例來練功一下，就會發現還有很多要去了解和深入的地方，再加上整個開發流程和觀念也不同，熟悉機制到觀念轉換，一個月的學習時間應該是跑不了的。

今天不用上課，所以利用半天時間繼續把第一題解下去，今天主要是解決更新資料的問題，先前在用原生的PHP解題時，我是直接用一個表單POST所有資料到一個專門處理資料更新的API去做多筆資料更新的動作，但是在laravel上，預設是一次只能更新一筆資料，另一個問題是Route的設計會和原本的新增路由衝突到，這兩個問題花了一些時間研究，搞定後，其實後台卜就等於做完了。

先說路由的問題，由於Laravel在一開始設計時就傾向於REST的精神，所以在Route上有提供的PUT/PATCH/Delete的方式，但是目前大多數的瀏灠器只有提供GET和POST的方式，所以如果要在表單上實踐其它的HTTP動作，應該是要以AJAX的方式來實踐，不過，Laravel在這部份有提供了一個欺騙的方式，並且也已經做了路由的對應，因此只要在表單上做一個隱藏欄位，並傳送所要執行的動作名稱，接卜來要設定好動作的的路由，然後對應到Controller的update方法，就可以做資料的更新了；

再來是說更新資料的問題，內建提供的update方法預設是必須帶id的，而且一次只能更新一筆資料，所以我改了原本的方法，把id拿掉，然後在表單上放了一個隱藏的欄位當成id，接下來就是用迴圈去把表單資料一筆一筆做更新；雖然可以完成我預期的大量資料更新的工作，不過在了解了laravel的背後機制後，我認為這樣的做法可能不太有效率，所以之後考慮改用別的做法來實踐，但是做到這裏，我己經掌握laravel一些可以自訂及修改的部份了。

最後我試著撈取資料丟回前端的blade去顯示包括標題圖片，進站人數，頁尾版權宣告這些內容，看起來都運作良好，接下來會再研究一下session，cookie及前端js 的整合，這樣應該拿來解其它題都就沒什麼問題了。

目前的階段在使用Laravel上己經沒有什麼大問題了，不過這類框架在使用上的確和原生PHP的觀念上有很大的不同，比如我現在把後台的所有功能顯示的資料都放在一個Controller中去實踐，包括View的樣版也是一個檔案搞定全部的功能，但這個做法和Laravel強調的MVC是不符合的，實際的做法應該把每個功能都獨立一組MVC出去，這樣才方便日後的維護和分工；BUT，我這樣實驗的目的是考量到如果要拿Laravel來做競賽或檢定時，每一個功能都要MVC的話 ，那光開完相關檔案就要去掉不少時間了，所以這部份只是要驗證說Laravel的彈性可以做到什麼桯度，是否可以依照目的不同，而有相應的調整，後來我也在網路上找到一些文章在討論進階的功能管理方式，可以把MVC的架構再做得更精細，不過這要等日後有機會再研究了。

花了兩天的時間研究了一下laravel的實作，如果只是照著書上說的或是線上課程的範例，大多都能執行成功，但這沒什麼，畢竟只是走別人走過的路；所以自己打算找些題材來實作練習，第一個想到的就是拿網頁設計乙級的題目來試刀，從頁面blade語法開始研究到後來的Model及Controller的運作，兩天下來只完成了後台的一半功能，過兩天有空再來完成剩下的，不過這邊先紀錄一下心得，免得到時要接上時又忘了。

單就前端頁面的建構來說，使用blade樣板語法後，前端頁面的建構變得非常簡單而且好維護，原本後台的各個功能頁面我是採用switch case的做法，直接複製各個功能的 html碼，再把一些文字做替換，雖然複製貼上是很簡單的工作，但是在修改各畫面的欄位名稱及文字時，不免還是會有遺漏或打錯的狀況，使用blade後，欄位名稱改成用變數的方式來傳送，只要用語法做好一份模型，接下來就是由Controller來控制要傳什麼功能的欄位名稱過來，樣板會自動生成對應的完整HTML語法，原本要4,5百行的檔案，一下縮到一百行左右而己。

資料模型是我目前覺得比較麻煩的地方，也是今天花最多時間研究的地方，單純就ORM的操作來說，的確可以簡化原本的SQL語法操作，甚至比我先前的先寫function的做法還來得快，但目前發現的缺點是一張資料表只能對應一個Model，所以第一題會用到九張資料表就得九個Ｍodel，然後再對應九個Controller來操作資料的CRUD，當然也得設定至少九個相應的Route來管理各項動作，雖然最後只是複製貼上再改一下資料表名就可以，但是採用框架就是為了做到DRY(Don’t Repeat Yourself)，這讓我不得不考慮是否改成直接用DB類別來操作SQL語法會比較快一些。

laravel在table migration的做法和之前習慣的做法不一樣，所以這部份也是要花時間研究，以往都是直接在資料庫或透過phpmyadmin直接建表完成後再來寫程式的，但是laravel是把整個資料表的操作都拉回到框架裏來操作，這部份是考量到團隊工作時，需要有個資料表修改的紀錄做為開發的參考，另一方面也是為了同步團隊的資料表結構而做的設計。

估計再花個一天時間可以把後端的部份全部做完，前端的部份目前看起來不難，後面會有點挑戰的地方應該是Session的使用及laravel驗證機制的操作。

做到目前的心得是採用框架來做解題，並不一定比較快速，而且開發觀念也得轉個彎，但如果是花點時間練熟悉的話，因為整體的程式碼數量是減少很多的，加上錯誤發生機會降低非常多，所以如果練習的強度夠高，整體速度還是可以加快不少的；後面的計畫是在年底前把網頁乙級四個題目都用laravel做過至少一次，然後找出最有效率的解法來。

上周錄取了一份工作，然後這周推辭了，雖然對方後來有提出一周只要去上三天班的兼職方案，但我最後還是決定不去了，對方很有誠意，薪水也符合水準，但一來是有其他的計劃要執行，另一方面則是我想起來我學程式的初衷是為了”創作”；當其它的履歷表都沒有面試機會而唯一錄取的工作內容又超出我現有能力範圍時，我花了半個月在思考我到底在幹什麼，原來這幾年現實中的各種雜事搞得我都忘了我的初衷了，所以一下說要回遊戲業做PM，一下說要高普考做公務員，一下說要轉行當程式設計師，沒一件事做的成，但時光已經不留情面的走過了五年了；

在找工作和撰寫前幾篇乙級術科解題心得時，一直有遇到Framework，但因為課程期間一直沒有實務在教，所以也只是知道個名詞，在做CI的教學時，做完也還是一頭霧水；這兩天又在密集的找了一些資料後，總算有些比較整體性的了解，對於我們這種非本科的凡夫俗子來說，那一堆全是專有名詞的framework的介紹文章，真是看了一百篇也還是不懂到底在講什麼。

先前同學在問我框架是什麼的時候，我還很高興的舉了個例子給他聽：”就好像從A點移動到B點這件事，你用兩條腿來走可以走到，但也可以用腳踏車、摩托車、和汽車來走到；Framework就是把’移動’這件事做各種不同的強化，讓你可以適應各種不同需求”，我當時是覺得我的解釋應該算是夠白話了，不過後來想想，這樣的解釋其實很淺，屬於嘴砲等級的解釋；所以後來在丟履歷等面試的空檔，我針對網頁開發這個領域找了很多資料，也試著下去使用framework，真實的去了解一下，框架這東西到底在做什麼。

目前的框架大致分成前端和後端兩大類，前端的框架大多都是基於Javascript做出來的，目的在於把我們原本使用Html來製作的靜態頁面改成為比較模組化，或者是元件化的組合呈現，儘量避免類似頁面，只因為部份內容不同，就要重新做一個新的頁面出來，前端框架的主要應用大多是以所謂的SPA為主，全名為”單頁式網頁應用程式”(Single Page Application)，SPA因為要把原本分屬不同頁面的東西都擠到同一頁來顯示，因此利用框架來簡化程式碼，或者說是把程式碼做適當的管理與組合(因為很多時候前端框架只是讓你寫更多的程式碼，所以需要好的管理方案)，讓後續的維護或修改變得比較容易，換句話說，如果你的前端開發，其實沒有很複雜，修改或擴充的需求也很低的話，其實是可以不用考慮使用框架的，函式庫類的jQuery就很夠用了，只是一堆工作的要求都說要有前端框架經驗，要有MVC觀念什麼的，但我是覺得實務上的開發，前端的框架應用似乎不多，因為後端的框架大多也包了前端一大半的工作了。

後端的框架出現的比較早，這是因為早期的一些中大型網頁應用，都是由後端程式去架構前端頁面的形成，當時前端的javascript語言的標準有好幾年沒有什麼進展或修改，反而是後端的應用百家爭鳴，不管是PHP、JSP還是ASP，都發展出滿成熟的框架技術，其中以MVC的架構為主流，這些後端框架主要想解決的問題是網頁HTML碼中又夾了PHP、CSS、Javascript，單一檔案中有多項程式語言混在一起，閱讀和維護都不容易，因此推出MVC的概念及框架，規範了網頁應用的開發要遵循框架內的規矩，讓網頁顯示的部份和資料存取的部份分開來，這樣在原始碼的閱讀和維護上也才會比較清楚；這就好象以前的安全帽裏的海棉是縫死的，你要洗海棉，就等於整頂安全帽要一起洗；現在有在賣海棉可拆洗的安全帽，你就可以只洗海棉而不用整頂下去洗。

然後最近看了很多框架的應用及自己實際去試用後，也推翻了我原本想的”用框架來做網頁術科的解題會比較快的想法”，現在的答案是不一定，要等我真的掌握了框架的應用並且真的去使用了之後，才能做判斷；因為大多數的框架都是基於某程式語言再去開發出來的，這表示在效率上，絕對不會比原生的程式來得快，而且大多數的框架也都有其特別專長的應用領域，所以要看你的應用在那邊，再來決定要使用什麼框架，否則反而會被框架綁住手腳，或是殺雞用牛刀的狀況，再者是，框架都有其規範的使用方式，簡單來說，使用框架，大概等於重新學一種程式語言，只是，框架做不到的事，你可以馬上用原生程式的語法來自己新增功能，最後，目前各種框架強調的MVC架構，其實又大多是基於物件導向的原則，職訓課程期間也沒講到物件導向，同學們去碰這類框架，一定會一頭霧水，雖然我以前有學過JAVA，所以對物件導向算是有認識，但也因為對物件導向的認識，所以我現在覺得這些框架並不一定會真的省到工，也不一定會讓我少寫很多程式碼，畢竟這些框架能生存的真正原因在於維護和修改，而不是為了我們這種要針對考試檢定而來的，所以針對檢定到底要不要使用框架技術來解，我還要再實測一下才能下定論。

我寫這篇並沒有打算要介紹什麼框架，因為介紹不完，而且會有太多專有名詞，解釋起來麻煩，我只是把我這兩周找到的相關資料，自己做一些心得匯整，用自己比較好懂的白話文來幫自己紀錄一下；至於要不要學框架，我現在的計畫就是後端的CI會先學，然後用乙級術科來做練習，前端我會選擇React來學，主要是要做一些SPA的作品當成作品集，這大概就是我接下來一兩個月如果還是沒工作的計畫惹。