|
|
寫于2009-3-9
半年前，JoelOnSoftware和CodingHorror合搞的stackoverflow.com剛上線不久，我興沖沖地跑過去扔了一個問題：
你們認(rèn)為編程的首要原則是什么？
作為我的學(xué)習(xí)原則的一個實踐：
8. 學(xué)習(xí)一項知識，必須問自己三個重要問題：1. 它的本質(zhì)是什么。2. 它的第一原則是什么。3. 它的知識結(jié)構(gòu)是怎樣的。
5個月過去了，這個問題到現(xiàn)在還有人回復(fù)，我得到了一大堆有意思的答案，忍不住翻譯過來與大家分享：
1. 獲得最多認(rèn)同的答案：
KISS – Keep It Simple Stupid
DRY – Don’t Repeat Yourself
一點不感到意外吧？
注：DRY原則倒是比較好理解和實踐的。但KISS原則則是看上去直白，其實實踐起來不那么容易的一個原則，因為simple和stupid的定義并不是每個人、在每個場景下都是一致且明顯的，一個人的simple可能是另一個人的stupid，一個人的stupid可能是另一個人的unnecessary。一旦一個標(biāo)準(zhǔn)取決于具體場景，事情就不那么簡單了。所以我們經(jīng)常要說“It depends”。
2. 獲得第二認(rèn)同的答案：
寫代碼時時刻設(shè)想你就是將來要來維護這坨代碼的人。
在這個答案后面有人添加到：
最好設(shè)想你的代碼會被一個揮著斧頭的精神病來維護。
有人接著又YY道：
而且這個揮著斧頭的精神病還知道你住在哪兒。1
注：其實這個原則在設(shè)計API時也有用：
寫API時時刻設(shè)想你就是要去使用這坨API的人。
3. 一些眾所不一定周知的答案：
先弄清你的問題是什么！
弄清問題永遠(yuǎn)是問題解決過程中的第一步和最重要的一步。
代碼只是工具，不是手段。
不知道怎么最好地解決你手頭的問題（注：需求、架構(gòu)、算法，技術(shù)選型，etc..），寫上一萬坨代碼也是浪費比特。
知道什么時候不該編碼。
（類似條目：YAGNI——“你并不需要編寫這坨代碼！”，針對你的需求編碼，“寫你所需”，別做“聰明事”，為一個不確定的未來編碼。同時也注意模塊化設(shè)計，以便能在未來新增需求時無痛擴充系統(tǒng)）
永遠(yuǎn)不要假定你已經(jīng)了解一切了！
不作沒有證據(jù)的推論。
想清楚了再編寫。類似條目：如果方案在你腦子里面或者紙上不能工作，寫成代碼還是不能工作。
4. 一些眾所很可能周知的答案：
越懶越好。
過早優(yōu)化是一切罪惡的根源。
不要重新發(fā)明輪子。
測試通過前說什么“它可以工作”都是純扯淡。
了解你的工具。
一切以用戶需求為導(dǎo)向。
利用分治、抽象，解開子問題之間的耦合。
5. 最幽默的答案：
咖啡進，代碼出。（Coffee in, Code out）2
最后，整個問題的 thread 在這里。
Footnotes:
- 事實上后面有人指出這是 Martin Golding 的一句名言 [?]
- 參見 Garbage in, Garbage out. [?]
it知識庫：編程的首要原則(s)是什么？，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
