怎樣去構建一個可以維護的專案

前提

你要知道一個專案，當前存在什麼問題，導致爛掉的。

小記錄（前後端）

• this 傳來傳去
• 傳大物件
• 底層和高層分離
• 拼寫錯誤
• 長方法
• 沒測試
• 可讀性差
• magic number
• mutable
• 靜態方法過多

好專案

傳大物件

很明顯違反了最少知識原則。對於被呼叫方，通常知道的越少越好，這樣被呼叫方，做的事情就會非常有限，方法就會變得很小。 如果給個大物件。。

底層和高層分離

底層抽象過高，使用層和低層要有一層類似於膠水層的東西。

對比前端

有個基礎組建庫的底層高階抽象層， UI層和抽象的底層之間有一層抽象去讓底層不那麼抽象。通常是小元件。

對比後端

有人給你封裝了一套資料庫操作的介面， controller層直接用，沒有service層去當膠水層。

拼寫錯誤

這個問題，初看覺得問題不大，但是時間長了，「破窗效應」就出現了，隨著時間越長，雪球也會越滾越大。

長方法

方法過大導致的問題，老生長談了。 這裡就不提了。

沒測試

這是最要命的，這是導致專案快速爛掉的最佳方式。誰都不敢動，動了就有可能產生bug。

可讀性差

這不就是爛程式碼的標準表現嗎！

也是「破窗效應」的表現。

magic number

類似於

class SomeClass {
    // 性別欄位
    // 1 代表男， 2 代表女
    private Integer gender;
}
 

這種 magic number 是不是很痛苦，用個列舉不香嗎？？？

「破窗效應」。。。

mutable 可變物件

面向物件的Java，一切皆物件，一切皆引用。一切皆可變， 一不小心就會修改物件的引用。

所有的方法都可以變成為返回值為 void, 然後去搞「騷操作」。

這麼做是沒有太大問題的，只是程式碼不太容易閱讀而已。

但是又一個致命的問題，就是測試比較難寫。

如何這個物件穿的層次比較深，傳了兩層以上。 測試只需要測試當前的一層，但是依賴的另一層對原始物件的修改，另一層又是mock的，因為當前測試不關心。

於是就沒法寫單元測試，只能寫整合測試。

靜態方法過多

靜態方法過多，並且靜態方法乾的事情，比較複雜，測試寫起來也是比較難的。

總結

聊了一些自己在專案中遇到的問題，以及導致的後果，希望對別人有些幫助吧。