編程十誡

原文： http://cocre.com/?p=1007 （酷殼）

 

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。 並且，爲了讓審查者真正負責起來，而不是在敷衍審查工做，咱們須要讓審查者對審查過的代碼負主要責任，而不是代碼的做者。  另外，好的代碼審查應該不是當代碼完成的時候，而是在代碼編寫的過程當中，不斷地迭代代碼審查。好的實踐的，不管代碼是否完成，代碼審覈須要幾天一次地不斷地進行。 （我以我我的的語言敘述本文，並加入了我我的的經歷，因此，請你在轉載時請注意做者和出處，而且，請勿用於商業用途）