1.- DRY: Don't repeat yourself.
DRY 是一個最簡單的法則，也是最容易被理解的。但它也可能是最難被應用的（因為要做到這樣，我們需要在泛型設計上做相當的努力，這並不是一件容易的事）。它意味著，當我們在兩個或多個地方的時候發現一些相似的代碼的時候，我們需要把他們的共性抽像出來形一個唯一的新方法，並且改變現有的地方的代碼讓他們以一些合適的參數呼叫這個新的方法。
DRY 這法則可能是程式設計屆中最通用的法則了，目前為止，應該沒有哪個程式設計師對這法則存有異議。但是，我們卻能發現，一些程式在編寫單元測試（unit testing）時忘記了這一法則：讓我們相像一下，當你改變一個類的若干接口，如果你沒有使用DRY，那麼，那些通過調用一系例類別的介面的unit test的程序，都需要被手動的更改。例如：如果你的unit test的諸多test cases中沒有使用一個標準共有的建構類別的方法，而是每個test case自己去建構類別的實例，那麼，當類別的建構子被改變時，你需要修改多少個test cases啊。這就是不使用DRY法則所帶來的惡果。
2.- 短小的方法.
至少，我們有以下三個不錯的理由要求程式設計師寫下短小的方法。
程式碼會變得更容易閱讀。
程式碼會變得更容易重複使用（短方法可以減少程式碼間的耦合程度）
程式碼會變得更容易測試。
3.- 良好的命名規範
使用不錯的統一的命名規範可以讓你的程序變得更容易閱讀和維護，當一個類，一個函數，一個變量的名字達到了那種可以“望文生義」的境界話，我們就可以少一些文檔，少一些溝通。文章《程式設計中的命名設計那點事 》可以給你一些提示。
4.- 賦予每個類正確的職責
一個類，一個職責，這類規則可以參考一下類的SOLID 法則。但我們這裡強調的不是單一的職責，而是一個正確的職責。如果你有一個類別叫Customer，我們就不應該讓這個類別有sales 的方法，我們只能讓這個類別有和Customer有最直接關係的方法。
5.- 把程式碼組織起來
把程式碼組織起來有兩具層次。
物理層組織：無論你使用什麼樣的目錄，包(package)或名字空間(namespace)等的結構，你需要把你的類別用一種標準的方法組織起來，這樣可以方便查找。這是一種物理性質的代碼組織。
邏輯層組織： 所謂邏輯層，主要是說，我們如果把兩個不同功能的類別或方法透過某種規範連結和組織起來。這裡主要關注的是程式模組間的介面。這就是我們經常見到的程式模組的架構。
6.- 創建大量的單元測試
單元測試是最接近BUG的地方，也是修改BUG成本最低的地方，同樣也是決定整個軟體品質好壞的成敗的地方。所以，只要有可能，你就應該寫更多的，更好的單元測試案例，這樣當你未來有相應程式碼改變的時候，你可以很簡單知道你程式碼的改變是否影響了其它單元。
7.- 經常重構你的程式碼
軟體開發是一種持續的發現的過程，從而讓你的程式碼可以跟上最新的實際需求的變化。所以，我們要常常重構自己的程式碼來跟上這樣的變化。當然，重構是有風險的，並不是所有的重構都是成功的，也不是我們隨時都可以重構程式碼。以下是兩個重構程式碼的先要條件，避免讓你引入更多的BUG，或是把本來就爛的程式碼變得更爛。
有大量的單元測試來測試。如前面所說，重構需要用大量的單元測試來做保障和測試。
每次重構都不要大，用點點滴滴的小的重構來代替那種大型的重構。有太多的時候，當我們一開始計畫重構2000行程式碼，而在3個小時後，我們就放棄這個計畫並把程式碼還原到原始的版本。所以，我們推薦的是，重構最好是從點點滴滴累積起來的。
8.- 程式註解是邪惡的
這條一定是充滿爭議的，大多數程式設計師都認為程式註解是非常好的，是的，沒錯，程式註解在理論上是非常不錯的。但是，在實際過程式當中，程式設計師寫出來的註解卻是很糟糕的（程式設計師的表達能力很有問題），從而導致了程式註解成為了一切邪惡的化身，也導致了我們在閱讀程式的時，大多數時候，我們都不讀註解而直接讀程式碼。所以，在這裡，我們並不是鼓勵不寫註釋，而是──如果你的註解寫得不夠好的話，那麼，你不如把更重要的時間花在重構一下你的程式碼，讓你的程式碼更易讀，更清楚，這比會比註解更好。
9.- 注重接口，而不是實現
這是一個最經典的規則了。介面注重的是－－「What」是抽象，實作注重的是－－「How」是細節。介面相當於一種合約契約，而實際的細節相當於對這種合約契約的一種運作和實現。運作是可以很彈性的，而合約契約則需要是相對需要穩定和不變的。如果，一個介面沒有設計好而需要經常性的變化的話，那我們可以試想一下，這代來的後果，這絕對會是一件成本很大的事情。所以，在軟體開發和調設中，介面是重中之重，而不是實作。然而我們的程式設計師總是專注於實作細節，所以他們局部的程式碼寫的非常不錯，但軟體整體卻設計得相對較差。這一點需要我們多注意。
10.- 程式碼審查機制
所有人都會出錯，一個人出錯的機率是很大的，兩個人出錯的機率就會小一些，人多一些，出錯的機率就會越來越小。因為，人多了，就能夠從不同的角度看待一個事情，雖然這樣可能導致無效率的爭論，但比起軟體產品release後出現問題的維護成本，這點成本算是相當值得的。所以，這就是我們需要讓不同的人來 reivew程式碼，程式碼審查機制不但是一種發現問題的最有效的機制，同時也是一種可以知識共享的機制。當然，對於Code Review來說，以下有幾個基本原則：
審查者的能力一定要大於或等於程式碼作者的能力，不然，程式碼審查就成了一種對新手的training。
而且，為了讓審查者真正負責起來，而不是在敷衍審查工作，我們需要讓審查者對審查過的程式碼負主要責任，而不是程式碼的作者。
另外，好的程式碼審查應該不是當程式碼完成的時候，而是在程式碼編寫的過程中，不斷地迭代程式碼審查。好的實踐的，無論程式碼是否完成，程式碼審核都需要幾天一次地不斷地進行。
以上就介紹了程式設計師共同開發網 程式設計師程式設計十條戒律，包括了程式設計師共同開發網方面的內容，希望對PHP教程有興趣的朋友有所幫助。
