真假!?

覺得上了91的幾堂課，光是讓我能有能力﹑有意願去重構一年前那相依全部ㄍㄡˊ在一起的code（即使只是把分散的東西聚合成一個物件），就已經物超所值了。

畢竟，這樣就可以把相依的部分用stub的方式作假，寫出專門為了檢查邏輯的﹑穩固的unit test

雖然我一直推崇91的TDD課，教的寫新feature之前，思考設計出環環相扣﹑剛剛好的測試情境，但反而比較常用到的是這堂課教的各種重構手法wwwwww

這可能也和我現在工作上，大部分都是在寫很簡單的資料回傳的API，所以都不太需要抽成專門的元件，而是只需要弄request資料比對的整合測試。這情況，也反而decorator pattern﹑重構比較容易被使用到。

可能需要再用TDD做一些小程式，熟悉一下。

今天晚上，試著弄前天所想的修改法，研磨度調粗，前100cc微微的沖高一點，之後就一直維持這個高度到結束。濃度（口感）如同我思考的，變得比較濃了，即使研磨度調淺快兩大格，但水位高低對萃取濃度的影響還是比較大的。

但風味好像還是跟前天的一樣，比較偏苦。不知道是不是因為這次悶蒸的注水，花的時間比平時還要長5秒左右（在這隻後的斷水時間和之前一樣是30秒）。可是總萃取時間，還是差不多2分30秒。

剛剛查了一些文章，發現有人做了類似的實驗。
https://kknews.cc/...
https://kknews.cc/...

有意思的是，不論總萃取時間固定，還是萃取時間跟著悶蒸時間拉長（悶蒸後的注水時間固定），所拿到的風味走向都一樣。
只要悶蒸越久，風味越靠後。

之前，一直以為是因為單純的用來拉長總萃取時間而已。但假如是這樣的話，只要總萃取時間一樣，那樣萃取到的各種味道比例也應該要一樣才對，可是結果卻不是這樣。

而上面文章的濃度變化，第一組，很容易得知是因為悶蒸後的單位時間注水量變大，所以肯定會導致濃度下降；而悶蒸後的萃取時間固定的那組，思考一下也可以大概推論，是因為不悶蒸和悶蒸的比起來，有悶蒸的後面的注水量比較多，所以導致沒悶蒸的比有悶蒸的還要高濃度，並且，隨著總時間的拉長，會在額外萃取出其他味道，濃度當然會越來越高。
總之，得到了一個結論，還有一個疑問。

結論：悶蒸的時間長短決定著風味的走向，而且這和後面的萃取時間是否固定﹑或者跟著減少，以讓總萃取時間固定。沒有關係。

疑問一：為什麼即使總萃取時間相同，只要悶蒸時間不同，風味走向就會不一樣？

好奇問個問題
你在做重構的時候你們公司會給這麼充裕的時間嗎OAO??

as629453: 因為這邊的code已經是很舊的了，不重構要去修改根本寸步難行，花的時間可能會比重構來的久很多（必須要用人眼測試），連最基本的依賴要用interface之類的方法隔離都沒有做。至少我會以有辦法寫單元測試為最低限度，才去考慮要不要重構，也只有建立在這樣的基礎下，才算重構（在不改變原有行為的前提下，修改程式）

as629453: 在有單元測試的前提下，修改到可以跑測試並且通過的重構，其實不需要花太多時間。
像是改命名﹑inline變數﹑抽變數﹑抽function﹑把有高強度關係的多個資料聚合成一個資料物件......等的操作其實都不會花太多時間。

as629453: 甚至是我上面說的舊code，其實我在開始做修改的時候，都會想辦法把每次的重構切得小小的，像資料庫的相依，我就先讓他並行，一部份是新寫好只暴露清楚API的物件（例如 Database.GetUser(userId) ），一部份還是還是原本的寫法（例如 sql.query("select userName from userProfile;") )

這樣我只要一次把其中一個相依的API抽出來移過去那個物件，並且把呼叫的地方改寫成用新的API的方式，就可以幾乎無痛的移過去了。

詳細的動作，大概就是抽function，把function掛到對應的物件下。假如IDE有支援的話，甚至這邊可以只需要花到5秒左右（抽method﹑move method就完成了）。沒有支援那麼好的IDE也可以利用Find Error ，在修改完function的簽章後，跳到所有調用的地方來修改。（再配合vim的重複動作的按鍵. （點），就可以無腦的 下個錯誤 -> 點 的loop，快速的把調用的地方修改成新的用法。）

綜上而論，大部分的情況，重構不會花到太多時間，反而正好那多花一點的時間，反而可以減少以後會出現的技術債（簡單好擴增的設計）。
然後因為後端只有我一個，並且前端的進度其實還比我落後，所以PM前一陣子比較會去釘前端的進度，為什麼說前一陣子呢？因為現在他正在被上面砸下來的 IT 需求（例如什麼google 試算表連接slack chatbot之類的） 弄得忙不過來