程式碼越少越好？！

幾乎每一份工作主管都會交派我進行重構，所以對於重構需要的技能，我可以說是意外點齊，重構這件事比起開發，我可能再熟悉不過。

重構首先關注點是閱讀和理解程式碼的能力，關於這部分改天再談。

另外一個就是拆解程式碼，將功能盡可能抽象後單獨模組化。通常公司願意重構的專案都是「有在盈利」、「足夠複雜」的專案，但這種專案品質一定好嗎？可能千百種情況都說不準。

但重構過各種類型網站後最強烈的感受其實一反許多人的想法。可能大家都會說「聚合性要高，程式碼能越少越好維護。」但我接手多個需要重構專案的經驗卻告訴我，程式碼複用率越高，相比幾乎不複用的爛專案來得更難維護。

通常維護專案什麼最難？我認為是「理解程式碼的意圖」最困難，你要充分理解上下文表層目的與深層目的，它需要非常驚人的時間去理解與分析，特別是要重構的專案「通常沒有文件」這件事很習以為常。

我曾經遇過一個寫的還算不錯的專案，它用極端少量的程式碼，透過超高比率的重用完成龐大的業務邏輯。但接手的人的感受其實是⋯⋯整個專案黏踢踢的，根本無法執行部分重構，單一模組的依賴非常不明確，都吃到大範圍約定式依賴註冊，你很難去解耦後單獨重構和現有系統一起工作。它的封裝也是考慮到效能、重用性，但其實非常難以快速閱讀理解。

我體驗過這件事後，我再也不迷信所謂的「程式碼越少越好維護」，那其實帶來的是另一塊維護黑洞。我體驗過讓我好閱讀的都是「簡單」、「直白」、「獨立」的系統。雖然需求終究會遇上很噁心的功能，會遇到不得不全域溝通的上下文，但宣告明確清晰很重要，可能會大幅拉長「開發時程」，但確實回頭追蹤時簡直明確容易多了。