程式設計十誡

1.- DRY: Don’t repeat yourself.

DRY 是一個最簡單的法則，也是最容易被了解的。但它也可能是最難被應用的（因為要做到這樣，我們需要在泛型設計上做相當的努力，這并不是一件容易的事）。它意味着，當我們在兩個或多個地方的時候發現一些相似的代碼的時候，我們需要把他們的共性抽象出來形一個唯一的新方法，并且改變現有的地方的代碼讓他們以一些合适的參數調用這個新的方法。

2.- 短小的方法.

至少，我們有下面三個不錯的理由要求程式員們寫下短小的方法。

代碼會變得更容易閱讀。 

代碼會變得更容易重用（短方法可以減少代碼間的耦合程度） 

代碼會變得更容易測試。 

3.- 良好的命名規範

4.- 賦予每個類正确的職責

5.- 把代碼組織起來

把代碼組織起來有兩具層次。

實體層組織：無論你使用什麼樣的目錄，包(package)或名字空間(namespace)等的結構，你需要把你的類用一種标準的方法組織起來，這樣可以友善查找。這是一種實體性質的代碼組織。 

邏輯層組織： 所謂邏輯層，主要是說，我們如果把兩個不同功能的類或方法通過某種規範聯系群組織起來。這裡主要關注的是程式子產品間的接口。這就是我們經常見到的程式子產品的架構。 

6.- 建立大量的單元測試

單元測試是最接近BUG的地方，也是修改BUG成本最低的地方，同樣也是決定整個軟體品質好壞的成敗的地方。是以，隻要有可能，你就應該寫更多的，更好的單元測試案例，這樣當你未來有相應代碼改變的時候，你可以很簡單知道你代碼的改變是否影響了其它單元。

7.- 經常重構你的代碼

軟體開發是一種持續的發現的過程，進而讓你的代碼可以跟上最新的實際需求的變化。是以，我們要經常重構自己的代碼來跟上這樣的變化。當然，重構是有風險的，并不是所有的重構都是成功的，也不是我們随時都可以重構代碼。下面是兩個重構代碼的先要條件，以避免讓你引入更多的BUG，或是把本來就爛的代碼變得更爛。

有大量的單元測試來測試。正如前面所說，重構需要用大量的單元測試來做保障和測試。 

每次重構都不要大，用點點滴滴的小的重構來代替那種大型的重構。有太多的時候，當我們一開始計劃重構2000行代碼，而在3個小時後，我們就放棄這個計劃并把代碼恢複到原始的版本。是以，我們推薦的是，重構最好是從點點滴滴積累起來的。 

8.- 程式注釋是邪惡的

這一條一定是充滿争議的，大多數程式員都認為程式注釋是非常好的，是的，沒錯，程式注釋在理論上是非常不錯的。但是，在實際過程式當中，程式員們寫出來的注釋卻是很糟糕的（程式員的表達能力很有問題），進而導緻了程式注釋成為了一切邪惡的化身，也導緻了我們在閱讀程式的時，大多數時候，我們都不讀注釋而直接讀代碼。是以，在這裡，我們并不是鼓勵不寫注釋，而是——如果你的注釋寫得不夠好的話，那麼，你還不如把更重要的時間花在重構一下你的代碼，讓你的代碼更加易讀，更加清楚，這比會比注釋更好。

9.- 注重接口，而不是實作

這是一個最經典的規則了。接口注重的是——“What”是抽象，實作注重的是——“How”是細節。接口相當于一種合同契約，而實際的細節相當于對這種合同契約的一種運作和實作。運作是可以很靈活的，而合同契約則需要是相對需要穩定和不變的。如果，一個接口沒有設計好而需要經常性的變化的話，那我們可以試想一下，這代來的後果，這絕對會是一件成本很大的事情。是以，在軟體開發和調設中，接口是重中之重，而不是實作。然而我們的程式員總是注重于實作細節，是以他們局部的代碼寫的非常不錯，但軟體整體卻設計得相對較差。這點需要我們多多注意。

10.- 代碼審查機制

所有人都會出錯，一個人出錯的機率是很大的，兩個人出錯的機率就會小一些，人多一些，出錯的機率就會越來越小。因為，人多了，就能夠從不同的角度看待一個事情，雖然這樣可能導緻無效率的争論，但比起軟體産品release後出現問題的維護成本，這點成本算是相當值得的。是以，這就是我們需要讓不同的人來reivew代碼，代碼審查機制不但是一種發現問題的最有效的機制，同時也是一種可以知識共享的機制。當然，對于Code Review來說，下面有幾個基本原則：

審查者的能力一定要大于或等于代碼作者的能力，不然，代碼審查就成了一種對新手的training。 

而且，為了讓審查者真正負責起來，而不是在敷衍審查工作，我們需要讓審查者對審查過的代碼負主要責任，而不是代碼的作者。  

另外，好的代碼審查應該不是當代碼完成的時候，而是在代碼編寫的過程中，不斷地疊代代碼審查。好的實踐的，無論代碼是否完成，代碼稽核需要幾天一次地不斷地進行。 

（我以我個人的語言叙述本文，并加入了我個人的經曆，是以，請你在轉載時請注意作者和出處，并且，請勿用于商業用途）

本文轉自 haoel 51CTO部落格，原文連結：http://blog.51cto.com/haoel/163821，如需轉載請自行聯系原作者