dev, production 都可用
怕的話就 local 玩一玩就好，算是最簡單的方式建立一個 k8s 環境，然後資源用的很少。
去裝 minikube 或是 Docker Desktop 內建的 k8s 就知道，裡面什麼都沒裝就吃掉 30% CPU usage，這真的抓狂
kaif 哪天我也會轉到 k3s 吧… 有空的話 XD
基本上新設計的 date API 多半都有 Java8 time API 的影子 -- 分為機器產生的絕對時間和人使用的曆法時間
Absolute -- Java 8 Instant
DateTime -- Java 8 LocalDateTime
不過沒看到相對應的 ZonedDateTime 或是 OffsetDateTime，只有轉 string 時才會出現。
這個嘛... 我猜未來 proposal 會加上去吧，而且 Absolute 這個字大概會被改掉，因為明明文件裡就一直出現 instant 這個字。
我想的方向不太一樣。有一種重複，是像開發 Android app 這樣，每一個開發 app 的人都要繼承 Activity (或 Service etc)，並部分 overwrite parent 特定的實作。當很多使用 API 的開發者都在一樣的地方做相同的 overwrite 時，也可以看作是重複。
不當的抽象可粗分為二，一為對抽象對象的錯誤解讀造成的不正確的抽象架構設計或不貼切的描述，另一種是為了避免重複而做的過分集中的抽象。我們當然能避免重複，而不重複的方法就是在抽象層做統一的描述，但這同時也造成了收斂。收斂和僵化是一體兩面，因此收斂的同時也減少了彈性；實務上的影響就是未來擴充的東西，一定要能夠被抽象描述表達，這其實是一種畫地自限。
舉個簡單的例子，幾乎所有繼承 Activity 的 app 都要 call onCreate() 的 super()，這也是一種重複，那為何不在 Activity 中就統一做掉？相信這除了是原設計 Activity 的人，希望能在 Activity class 中擁有足夠凝聚的描述，也是希望使用 API 的開發者能對 Activity 的使用有一個制式的規格可以遵循。
建構程式就像拼拼圖，抽象集中的程度好比拼圖塊的大小，較集中的抽象就是較大塊的拼圖，而拼圖塊如果都太大，可能就沒辦法拼成想要的樣子。但拼圖塊太碎，也同樣不好用，而且經驗淺的程式設計師面對太小的碎塊可能會無所適從。我覺得要做出好的取捨的心法是，朝兼顧彈性、易用性但又不鬆散的方向做設計，而不是單純考量如何讓抽象層最凝聚、濃縮 (過度抽象) 或讓使用者做最少操作 (彈性最差)。
所以要寫 test
如果比較好測，那通常是比較好的設計。你通常也只會重構到測試不會太難寫這樣，不會太過頭。(class 太多就測試更多，想到這你就會懶得抽這麼多層了)
測試可以引導設計，再加上一些經驗的累積大概不會錯太多。
當然如果寫的是 library ，會放出來給別人用，那又是另一種規則。
這篇又浮上來了
method 加上參數，裡面多寫個 if 進行擴充 -- 這大概工程師每天都在做
所以我覺得這類型的還好，它要累積到一個程度之後，才要重構，看是要回到重覆或是抽得更多層。
出現問題的大部份都是太多參數，就是作者說的，抽象化錯了方向。另一種錯誤是太早將單純的 if 抽成更複雜的 class/interface，也不能說一定錯，但新需求多半不可預知，所以八成都是抽錯方向，不如不抽。
然後更難得問題是，這些修改不一定是同一個人做的…
TDD 很好；但寫 React 怎麼做開發者測試(乃至於 TDD)又是一回事...我會覺得目前沒有好答案啦。
現在常見的做法大概分成兩種：
用 enzyme 的 shallow 測單個 component 的 render、不執行下層 component 的 render。 類似 mockist 的做法，寫起來很快，但問題是重構、改寫 component 的時候，整個測試會爛掉、或是發生「明明下層 component props 改了，但是這一層的測試卻依然通過」的事情(因為 shallow 只能測是否傳入特定的 props 給下一層)。 另外 React 官方已經棄用 shallow 了，useEffect/useContext 的 hooks 在 shallow 不起作用。只能等待 enzyme 把 shallow renderer 收進去跟改寫： issue1
用真正的 React mount component 測輸出的 DOM。也是這篇文章提到的 Kent C. Dodds 倡導的。屬於測結果而非狀態的做法。理論上重構會比 shallow 穩定。 但是被測的 component tree 大起來的時候(例如要測上層 component 的邏輯)，比較難 trace code。 需要做 api mock。一旦底層有 component 增加了 api 呼叫，測試也是整組壞掉。 更別說 apollo 的 mock provider 有多難用，一定要跑非同步，就只能 wait DOM 出現正確的狀態。
長期來看可能還是整串拿起來測比較穩定啦，但是就是很花時間...然後設計一改又要全部洗牌 XD
每次只要有機會用到 micronaut, 就有一種清爽的感覺
小, 簡單, 又快. 然後還大部份和 spring 很像
如果 spring 沒有包伏然後重開機的話, 大概就是 micronaut. 而不是現在的 spring boot.
但是你就是知道它不會變 spring 成為主流, 所以只能在小專案玩玩而已...