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