程式碼的 「因式分解」

長度不是判斷程式優劣難易的唯一絕對標準; 但完成同樣功能的幾個程式, 若長度相差太多 (例如兩倍以上), 通常較長的版本很可能是遜腳所寫的。 好的程式, 要適當地精簡化。

就像代數裡面, 多項式可以透過因式分解等等方式, 整理成比較清楚漂亮的表達方式。 程式的精簡化, 稱為 code refactoring。 縮短長度, 不是 code refactoring 唯一的好處。 把重複的程式碼萃取出來, 在其他各處用一句話重複使用它, 也有助於除錯﹑ 維持一致性﹑ 完整反應功能改進。 其實 「文書處理第零課」 ( 2009 版; 2001 版) 也是基於相同的概念。 用一個共通的原則來看, 就是我在 「長線投資的電腦學習策略」 裡面所提到的: 讓你的學習投資 (或程式碼撰寫投資) 發揮 相乘的效果 而不是相加的效果。

嗯, 越講越抽象了。 具體的方法, 請見 Code Refactoring 一文。 特別推薦 "What's that smell" 一節 -- 留意某些跡象, 你也可以嗅出有怪味的程式碼, 找到可以進行/需要進行 code refactoring 的部分。 最明顯的就是重複出現﹑ 類似的程式碼。

雖然我很少提自己過去寫程式的豐功偉業, 其實我還蠻敢大言不慚地說自己的程式寫得不錯。 正是因為 (1) 感受到程式撰寫的市場有劣幣逐良幣/ 黃鐘毀棄，瓦釜雷鳴 的現象 (2) 發現了自由軟體的存在, 所以近年來更加認為 「寫程式」 並不是一個值得鼓勵學生投入的行業。 它是一個很值得培養的興趣。 如果你對它真的有興趣, 你不會太在意有沒有人付你錢。 (我寫 algotutor 演算法/資料結構教學程式, 也沒人付我錢呀) 到了那個地步, 再來談靠寫程式賺錢, 才有意思。 順著這個邏輯去思考, 你也會理解為什麼我認為熱門自由軟體的品質, 勝過多數的專屬軟體。 再搭配這帖的主題, 你也就更能理解: 為什麼隨身碟上 2.4 的 linux, 能做的事遠超過硬碟裡 10G 的 Windows。

總之, 請盡量撿現成的程式來用; 請因為興趣而不是因為想賺錢而寫程式。 我的部落格過去很少談論如何寫程式; 將來也一樣。 只是正好幾位同學都對寫程式有興趣, 所以寫這一帖給 「真正對寫程式有興趣」 的同學們參考。