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

2021-06-05 22:49:23 字數 2017 閱讀 1045

半年前,joelonsoftware和codinghorror合搞的stackoverflow.com剛上線不久,我興沖沖地跑過去扔了

乙個問題:

你們認為程式設計的首要原則是什麼?

作為我的學習原則的乙個實踐:

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

1. 獲得最多認同的答案

kiss – keep it ****** stupid

dry – don』t repeat yourself

一點不感到意外吧?

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

2. 獲得第二認同的答案

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

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

最好設想你的**會被乙個揮著斧頭的精神病來維護。

有人接著又yy道:

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

注:其實這個原則在設計api時也有用:

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

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

先弄清你的問題是什麼!

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

**只是工具,不是手段。

知道什麼時候不該編碼

(類似條目:yagni——「你並不需要編寫這坨**!」,針對你的需求編碼,「寫你所需」,別做「聰明事」,為乙個不確定的未來編碼。同時也注意模組化設計,以便能在未來新增需求時**擴充系統)

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

不作沒有證據的推論。

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

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

越懶越好。

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

不要重新發明輪子。

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

了解你的工具。

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

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

5.最幽默的答案

咖啡進,**出。(coffee in, code out)2

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

footnotes:

事實上後面有人指出這是 martin golding 的一句名言 [↩]

參見 garbage in, garbage out. [↩]

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

半年前,joelonsoftware和codinghorror合搞的stackoverflow.com剛上線不久,我興沖沖地跑過去扔了乙個問題 你們認為程式設計的首要原則是什麼?作為我的學習原則的乙個實踐 8.學習一項知識,必須問自己三個重要問題 1.它的本質是什麼。2.它的第一原則是什麼。3.它的...

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

半年前,joelonsoftware和codinghorror合搞的stackoverflow.com剛上線不久,我興沖沖地跑過去扔了乙個問題 你們認為程式設計的首要原則是什麼?作為我的學習原則的乙個實踐 8.學習一項知識,必須問自己三個重要問題 1.它的本質是什麼。2.它的第一原則是什麼。3.它的...

單一職責原則是什麼?

單一職責原則是物件導向設計原則中的一條 舉個簡單的例子,假設,在工廠中,一款產品從無到有需要經過10種機器。我們是讓10個人,每個人拿著原材料從第一台操作到第十臺比較快,還是每個機器有乙個單獨的人專門處理這台機器比較快。答案是顯而易見的。因此工廠在實現分工後,效率有了大幅度的提高。這就是企業管理中的...