1、量兩次，切壹次(Measure twice and cut once)
如果妳只能從這篇文章中學到壹個原則且最重要的壹個，那麽就是這個。 開發人員，架構師和經理人經常因為個人情緒、以及其他問題而難以集中註意力。?
就工程師來說，這個原則意味著選擇正確的解決方案，選擇正確的方法來解決問題，選擇正確的工具來解決問題，對建立的解決方案必須充滿信心。
選擇這裏意味著投入壹些思考，找到必要的資源，組建合適的團隊，思考設計，思考方法，設定任務，控制結果，並為此承擔責任。 這就是“活在當下”。 我認為我自己還沒有準備好用正確的詞匯來描述它。
2、不要重復自己(Don't Repeat Yourself)
這是壹個相當簡單但非常有用的原則，它說在不同的地方重復同樣的事情是非常糟糕的。 首先，它涉及到進壹步支持和修改代碼的必要性。 如果某個代碼片段在程序中的幾個地方被復制，那麽很有可能出現兩種災難性的情況:
當對源代碼進行哪怕是很小的改動時，您需要在幾個地方更改相同的代碼。 這需要額外的時間、精力和註意力，而這件事件通常也非常不容易。
第壹項緊隨第二項。 團隊中的其他開發人員可能會意外地錯過其中壹個更改(只合並了控制系統中的分支) ，並將面對應用程序中隨後出現的壹系列錯誤。 這些 bug 可能會讓您感到沮喪，因為您已經聽說這樣的 bug 似乎已經被修復了。
在這方面，有壹個建議ーー如果在清單中發現任何代碼超過兩次，則應以單獨的方式來處置。 這是通用做法。 事實上，即使再次遇到重復的bug，您也應該考慮創建壹個單獨的方法。
3、奧卡姆剃刀(Occam’s Razor)
這是壹個非常普遍的想法，它來自於哲學編程。 這個原則得名於奧克姆的英國修道士威廉。 這壹原則表明: ”沒有必要，不得增加實體”。?
在工程學中，這壹原則被解釋為: 沒有必要創建不必要的實體。 因此，首先考慮添加另壹個方法 / 類 / 工具 / 流程等的好處不見得總是壹個好主意。 畢竟，如果您添加了另壹個方法 / 類 / 工具 / 流程等等，除了增加復雜性之外，您沒有得到任何其他好處，那還有什麽意義呢？
4、保持足夠簡單(Keep It Simple Stupid )
這是壹個與上面非常類似的原則，但它的含義略有不同。 這個原則要求代碼必須盡可能簡單，不能有復雜的結構，否則會使代碼的調試和維護復雜化。?
此外，對於另壹個程序員來說，理解代碼的邏輯將會更加困難，這反過來也將需要額外的時間和精力。 這就是為什麽您應該始終嘗試使用簡單的構造來盡可能多地解決問題，而不需要使用大量的分支、深層嵌套和過度重載的類結構。?
通過這樣做，妳將使自己和同事的生活更加輕松，因為復雜性會產生錯誤。 記住 Peter Hintiens 說過的話: “簡單永遠比功能好”。
5、妳不會需要它（You Aren’t Gonna Need It ）
這是許多程序員都會遇到的問題。 從項目壹開始就希望立即實現所有必要的(有時甚至是不必要的)功能。 也就是說，當開發人員從壹開始就將所有可能的方法添加到類中並實現它們時，甚至可能在未來永遠不會使用它們。?
因此，根據這個建議，首先，只實現您需要的東西，然後，如果必要的話，再擴展相應功能。 這樣，您就可以節省調試代碼的工作量、時間以及精力，而實際上這些代碼卻並不需要。