脫離重構的輪迴

 在最近開發的過程中，發現了每次增加新的 feature 就要來重構，想要歸納一下每次我在做的事情。

我想我每次重構的心得如下：

1. inner static class 最後好像還是會被抽取出來
1. 在一開始，必然是先用簡單的變數組合來代表某一觀念。
2. 然後會組成 static class ，概念是不必要讓這個類別暴露給其他類別知曉。
3. 然後在功能越加越多的時候， static class 一定會被獨立出來。而通常有兩個原因：
1. static class 變得過大。如果一個 inner class 的內容與他的 outer class 內容差不多多的話，那還是不要放在一起喧賓奪主了。
2. static class 會被第三個類別存取。在這種情況下，當初的封裝變得多此一舉了。
4. 那也許一開始就不要用 inner class ？
2. Strategy Pattern 終究會被引入
1. 在一開始通常沒有這需求，等到差異性顯現出來時，不抽成抽象方法而是使用 interface 作為參數傳入。
2. 這在美感上也比較討喜，將兩件權責劃分開來，測試的時候的排列組合更少。（個人想法）
3. 終究會抽出更多短方法。
1. 在一開始寫的過程中，總會覺得這段邏輯抽成方法太冗。
2. 但在重構的時候，卻又反而會覺得他不易理解。
3. 「不要輕易相信自己的記憶」？同一段程式碼在過一段時間回頭看仍需要重新理解它？
4. static / non-static 來回切換。
1. 在最後總有些東西好像擺在 static 也行  non-static 也不錯，這時候會經歷來回切換的時期，不過或許在更之後，重新審視就會覺得這個東西應該是無懸念的  static 或 non-static。
5. 方法的參數過多，通常會被拆開。
1. 這個確實就是所謂的壞程式碼的味道，幾乎一定會需要被拆開。
6. 盡可能地多命名。
1. 這跟第三點很像，每次回來還是需要重新理解，所以第二次第三次回來看的時候，都會再給所有暫存變數更好的名字。
7. 終究第一次取的名字就是不好，第二次的也差不多活不久。
1. 在新暫存變數、新功能引入的時候，不免會有與現有命名重疊、或不一致的情況發生。所以第一次和第二次的命名大概以後都會被爆改。
8. 終究會引入 stream。
1. 有時候只是沒有把判斷式寫成方法，就直覺得寫 for loop ，但重新回頭看，用 stream 這樣有點 transcation 概念的解決，總是令人比較安心。
9. 複雜的 for loop 終究會被改動。
1. 如果一個流程要參照複雜的狀態追蹤，這些狀態最好還是可以寫進 for loop 的三個區塊中。
2. 這個不是必然要做的事，但就我的個性來說是必然。
10. lombok 要用。
1. 這不用多說，拯救人類的時間的救星。

先這樣，之後有更多心得再寫。

把這些東西寫下來，是因為我意識到我常常會覺得「我重構還做得挺不錯的呀！」，但這樣似乎不是好事情。不好的地方不是「我做的挺不錯的」，而是「常常」，畢竟重構還是花時間的。我喜歡那種「這程式碼還真是無懈可擊，so neat，多一行太多，少一行不行」的感覺，所以我對重構並不排斥。但想想我終究愛的還是那整潔感，而不是打掃的過程。

這些我在重構的時候做的事情，如果可以在第一次寫的時候就完成，那感覺還挺好的。