你們認爲編程的首要原則是什麼?
作爲我的學習原則的一個實踐:
8. 學習一項知識,必須問自己三個重要問題: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道:
而且這個揮着斧頭的精神病還知道你住在哪兒。1
注:其實這個原則在設計API時也有用:
寫API時時刻設想你就是要去使用這坨API的人。
3. 一些衆所不一定周知的答案:
先弄清你的問題是什麼!
弄清問題永遠是問題解決過程中的第一步和最重要的一步。
代碼只是工具,不是手段。
不知道怎麼最好地解決你手頭的問題(注:需求、架構、算法,技術選型,etc..),寫上一萬坨代碼也是浪費比特。
知道什麼時候不該編碼。
(類似條目:YAGNI——“你並不需要編寫這坨代碼!”,針對你的需求編碼,“寫你所需”,別做“聰明事”,爲一個不確定的未來編碼。同時也注意模塊化設計,以便能在未來新增需求時無痛擴充系統)
永遠不要假定你已經瞭解一切了!
不作沒有證據的推論。
想清楚了再編寫。類似條目:如果方案在你腦子裏面或者紙上不能工作,寫成代碼還是不能工作。
4. 一些衆所很可能周知的答案:
越懶越好。
過早優化是一切罪惡的根源。
不要重新發明輪子。
測試通過前說什麼“它可以工作”都是純扯淡。
瞭解你的工具。
一切以用戶需求爲導向。
利用分治、抽象,解開子問題之間的耦合。
5. 最幽默的答案:
咖啡進,代碼出。(Coffee in, Code out)2
最後,整個問題的 thread 在這裏。
Footnotes:
- 事實上後面有人指出這是 Martin Golding 的一句名言 [↩]
- 參見 Garbage in, Garbage out. [↩]