解決問題的起點是，「發現問題」跟「面對問題」
學習起點只是知識點，學習的內化則是將知識點與自己既有的知識體系建立成知識面。
會用就好只能應急，只能把別人的詩朗誦地很好聽，但始終無法成為大詩人。
前端的世界更是如此，因為框架推陳出新的迭代速度更快，只有了解了本質，在熟悉新框架才能只需要關注在「差異」、「適用場景」、「優缺點」。
不了解本質，就只能像狗追尾巴一樣，一直被學習新框架搞得團團轉。
沉澱了兩天，其實上完課後還在整理家裡，到今晚才能夠好好再回顧一下上週六日所學到的內容。
這次的「Clean Coder: DI/AOP 進階實戰」課程，在過去的工作經驗中已經有使用 DI 在產品代碼上的經驗，上課前就一直在猜想著 91 究竟會用什麼樣的方式來帶我們進入 DI/AOP 的實作。課程一開始讓我們重新體驗寫個 #乾淨的胖子 開始。接著帶著我們思考這樣樣的程式究竟有什麼樣的問題，並透過重構的手法將胖子瘦身。平時在開發產品時通常寫到這裡就會結束了，看起來很乾淨、又不肥。但事實上卻只是將一坨垃圾分成數個小堆掃到桌子底下，看起來很乾淨，但其實垃圾仍然存在。
#不知道有問題
> 最怕的就是你覺得沒有問題，但實際上問題很多。
這門課最精華的莫過於是 91 帶著大家重新思考每當需求變更時如何以改最少的 Code 來達到目的，如何不動現有的 Source Code，而寫新的物件來取代或組合上去，這考驗著如何在程式碼中實踐 SOLID、OO 等設計方法。
> 什麼是實作？什麼是Flow？什麼是設計？
平時寫 Code 時很容易將需求都直觀的依順序寫下來，所造成的現象是當需求變更時我的 Production code 要修改、呼叫端要修改、Unit Test 要修改，這也是我一直困擾的問題。每當這樣的狀況時我總要額外花上許多心力在修改 Unit Test。91 帶我們重新思考需求與 Code 其實是可以拆開來看的，別一股腦的把需求攤開轉成 Code 實作。要能透過各種設計方式，將物件組合在一起來達到需求。
#動手解決問題
這兩天的課程就是在不斷的思考可能的問題→找出問題→思考如何解決→動手寫Code 的迴圈，每當解決一個問題時心裡總會想到在工作時的某段 Code 也是同樣的問題，我也許可以拿來先試著修改看看，心裡充滿著想趕快動手的衝動。這門課不是在教你怎麼用 DI/AOP，而是該怎麼用這些 Framework 來解決問題？
Resharper 也多學了新招，每次回來上課總能再多學到關於 IDE 操作的技巧，而不是只能看著 vim 的游標在那邊閃啊閃，卻還是拿著滑鼠裝忙…😅
乾淨的胖子 在 [問卦] 胖子不論怎麼乾淨都覺得髒？ - 看板Gossiping - PTT網頁版 的美食出口停車場
可是我覺得他還是很油很髒很噁心，在那種過分乾淨的環境中，反而覺得他更髒了，而且很臭。 是那種打從心底厭惡的臭肥宅感覺。 是不是人一胖就自動開啟油髒臭buff？ ... <看更多>