程式設計的首要原則是什麼？

半年前，JoelOnSoftware和CodingHorror合搞的stackoverflow.com剛上線不久，我興沖沖地跑過去扔了一個問題：

你們認為程式設計的首要原則是什麼？（此文還是作者寫於2009年的文章，這個問題是在2008年10月提交的）

作為我的學習原則的一個實踐：

學習一項知識，必須問自己三個重要問題：1. 它的本質是什麼。2. 它的第一原則是什麼。3. 它的知識結構是怎樣的。

5個月過去了，這個問題到現在還有人回覆，我得到了一大堆有意思的答案，忍不住翻譯過來與大家分享：

1. 獲得最多認同的答案：

KISS – Keep It Simple Stupid

DRY – Don’t Repeat Yourself

一點不感到意外吧？

注：DRY原則倒是比較好理解和實踐的。但KISS原則則是看上去直白，其實實踐起來不那麼容易的一個原則，因為simple和stupid的定義並不是每個人、在每個場景下都是一致且明顯的，一個人的simple可能是另一個人的stupid，一個人的stupid可能是另一個人的unnecessary。一旦一個標準取決於具體場景，事情就不那麼簡單了。所以我們經常要說“It depends”。

2. 獲得第二認同的答案：

寫程式碼時時刻設想你就是將來要來維護這坨程式碼的人。

在這個答案後面有人新增到：

最好設想你的程式碼會被一個揮著斧頭的精神病來維護。

有人接著又YY道：

而且這個揮著斧頭的精神病還知道你住在哪兒。¹

注：其實這個原則在設計API時也有用：

寫API時時刻設想你就是要去使用這坨API的人。

 

（伯樂線上編注：在編寫程式碼的時候，你要經常想著，那個最終維護你程式碼的人可能將是一個有暴力傾向的瘋子，並且他還知道你住在哪裡。—— 裡克·奧斯本 ）

3. 一些眾所不一定周知的答案：

先弄清你的問題是什麼！

弄清問題永遠是問題解決過程中的第一步和最重要的一步。

程式碼只是工具，不是手段。

不知道怎麼最好地解決你手頭的問題（注：需求、架構、演算法，技術選型，etc..），寫上一萬坨程式碼也是浪費位元。

知道什麼時候不該編碼。

（類似條目：YAGNI——“你並不需要編寫這坨程式碼！”，針對你的需求編碼，“寫你所需”，別做“聰明事”，為一個不確定的未來編碼。同時也注意模組化設計，以便能在未來新增需求時無痛擴充系統）

永遠不要假定你已經瞭解一切了！

不作沒有證據的推論。

想清楚了再編寫。類似條目：如果方案在你腦子裡面或者紙上不能工作，寫成程式碼還是不能工作。

4. 一些眾所很可能周知的答案：

越懶越好。

過早優化是一切罪惡的根源。

不要重新發明輪子。

測試通過前說什麼“它可以工作”都是純扯淡。

瞭解你的工具。

一切以使用者需求為導向。

利用分治、抽象，解開子問題之間的耦合。

5. 最幽默的答案：

咖啡進，程式碼出。（Coffee in, Code out）²

(伯樂線上編注：也有這樣一句俗語： Programmer – an organism that turns coffee into software. – Author Unknown 程式猿：一種把咖啡轉變成軟體的生物。—— 無名氏)

最後，整個問題的 thread 在這裡。

Footnotes:

1. 事實上後面有人指出這是 Martin Golding 的一句名言 [?]
2. 參見 Garbage in, Garbage out. [?]