這題目非常繞口，讓我用圖說描述細節吧! 嘗試實作出一個[網頁版的記帳專案]，我希望在選擇記帳分類選項的時候，子分類選項可以顯示不同的項目，看專業的記帳軟體都有這個功能，且也符合記帳使用體驗，便想要嘗試實作看看。
有了動機後，就先來檢視目前的設計框架該如何進行功能開發。首先，前端頁面所出現的資料是使用 express 搭配 handlebars ，將後端撈出來的資料渲染到前端去；而後端資料則是使用 MongoDB 存取，在 Node.js 中可以用 Mongoose 這套 ODM (Object-Document Mapping)，來對 MongoDB 進行操作；網頁則是透過路由設定對應的處理，完成 CRUD 等功能。
這個專案的DB有兩個，一個儲存每一筆支出的細節，包含[項目名稱、分類、子分類、日期、地點、花費、發票號碼]；另一個是儲存分類名目，包含[類型(支出、收入)、分類名稱、子分類清單]。
然而在規劃功能方法的時候就遇到了第一個難題，該怎麼做到這件事? 當時真的花了3天邊思考邊嘗試解決這件事，還想到鬼打牆QAQ。
我有兩個思路:
- 分類表單上加一個路由連結，當分類表單選擇改變 (onchange) 的時候，可連結到一個路由請求處理，此路由處理可將對應的子分類清單渲染到頁面上。
BUT… 這一定會讓表單頁面重新刷新的，所以開始 Google ，「express 要如何透過路由部分更新網頁」、「express 如何部分更改 handlebars 資料」…..，陷入了茫茫的資訊海，卻找不太到可以短時間理解消化的解法。
意識到越查越發散後，決定先嘗試目前能執行的解法。好吧，重刷就讓他重刷吧，我把分類選項改到表單最上方，正常依序 key in 狀況下，就不會因為重刷頁面，讓使用者輸入的名稱不見，重刷影響應該最小(自暴自棄解法)。
就這樣不負責任地完成新增表單的功能，要來改編輯表單部分時，內心OS : 出事啦~~~，這編輯表單上一改分類選項，所有資料就不見啦 =>果斷捨棄此解，這次決定先從編輯表單改起，開始思路 2
2. 編輯表單顯示的路由處理，會根據支出項目的分類，從分類DB撈出該分類的所有子分類清單，再渲染到前端去，虛擬碼如下。愈透過 Javascript DOM 操作，去判斷分類選項改變，去修改 handlebars 帶出的子分類清單變數資料 subcategoryList。
// express route and handlebars
route.get('/:id/edit', (req, res) => {
...
res.render('edit', { ..., category, subcategoryList})
}又開始 Google ，如何「動態修改 handlebars 資料」….，有看到一種解法在stack overflow或他人網誌上出現，要把 document 的部分HTML撈出，再透過 handlebars 重新編譯資料，但其實因為不太清楚 handlebars 的運作方式，官方文件也沒有相符的應用案例。抱著暫時相信地心態，嘗試改動程式。
BUT….，發現要越改越多，越改越不對勁，氣餒的是，最後還改失敗….=> 掙扎了一天後，QAQ， 還是下了指令 git reset
沉澱心情後，繼續思考有沒有其他解法，要怎麼搭配 handlebars、DOM操作、路由處理，才是比較良好的設計? 決定先釐清一下這三者扮演的角色。
首先是 handlebars，handlebars 會帶資料出來，再依據這些資料渲染出一份HTML靜態頁面……，燒等一下!!! handlebars 主要是決定渲染頁面一開始的樣貌，所以 DOM 是操作不到所謂 handlebars 的變數的!!!
思考到這一點的時候，好像突然懂了些甚麼，handlebars 專心負責帶資料，路由專心負責頁面功能處理，別建多餘的路由去處理這種頁面事件，而頁面上的變化就是DOM操作的範疇，於是生出了第三個思路
3. 在後端撈出所有的分類清單，與所有的子分類清單，渲染到前端去，並對子分類的所有項目上加了 hidden 屬性，初始化顯示隱藏，再使用 DOM 操作，監聽分類選項變換，去調整子分類的 hidden 屬性
這方法不會重新刷新頁面、沒有多餘的路由處理，延伸出的問題，就是要如何設計 <select><option></option></select>裡的內容，讓 DOM 比較好操作；讓 form 在post 資料到後端時，DB 比較好存取，但這些問題，都是能力範圍內的事了。
從一開始做不出來，到解決這個問題，最關鍵的環節是，釐清角色的部分。回顧到這邊，發現是「關注點分離」這概念，讓我想出了解法。
從開始學 express 專案開發後，就默默地建立這觀念，覺得 express 規範資料夾內容很有趣，像是靜態文件要放 public、顯示文件要放 views、路由文件放routes 等，這樣在程式開發跟除錯都可以很直覺的知道，要到哪個資料夾中去找，這算文件上的關注點分離。
將這概念延伸出去也都很受用，像是一條路由就專注做一件事處理、一個函式專注做一個功能、或是一條 git commit 粒度就專注在一種變化。若讓很多處理功能都耦合在一塊，閱讀理解難度會增加，修改難度會增加，拆解問題的難度也會增加!
以上是這次解題的心得與收穫，自己在工作上把所有的 Tensorflow 程式專案改成文件上的關注點分離，像 Checkpoint、Data、Model、Logs、Scripts等，使用與開發除錯上都提升了很多效率呢 !
這邊分享主管說過的一句話，共勉之~
該怕的不是做不出來，而是沒有想法
