欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

程序員編程十條戒律

 更新時間:2009年07月09日 14:33:22   作者:  
好的代碼審查應該不是當代碼完成的時候,而是在代碼編寫的過程中,不斷地迭代代碼審查。好的實踐的,無論代碼是否完成,代碼審核需要幾天一次地不斷地進行。
1.- DRY: Don't repeat yourself.
DRY 是一個最簡單的法則,也是最容易被理解的。但它也可能是最難被應用的(因為要做到這樣,我們需要在泛型設計上做相當?shù)呐?,這并不是一件容易的事)。它意味著,當我們在兩個或多個地方的時候發(fā)現(xiàn)一些相似的代碼的時候,我們需要把他們的共性抽象出來形一個唯一的新方法,并且改變現(xiàn)有的地方的代碼讓他們以一些合適的參數(shù)調用這個新的方法。

DRY 這一法則可能是編程屆中最通用的法則了,目前為止,應該沒有哪個程序員對這一法則存有異議。但是,我們卻能發(fā)現(xiàn),一些程序在編寫單元測試(unit testing)時忘記了這一法則:讓我們相像一下,當你改變一個類的若干接口,如果你沒有使用DRY,那么,那些通過調用一系例類的接口的unit test的程序,都需要被手動的更改。比如:如果你的unit test的諸多test cases中沒有使用一個標準共有的構造類的方法,而是每個test case自己去構造類的實例,那么,當類的構造函數(shù)被改變時,你需要修改多少個test cases啊。這就是不使用DRY法則所帶來的惡果。

2.- 短小的方法.
至少,我們有下面三個不錯的理由要求程序員們寫下短小的方法。

代碼會變得更容易閱讀。
代碼會變得更容易重用(短方法可以減少代碼間的耦合程度)
代碼會變得更容易測試。
3.- 良好的命名規(guī)范
使用不錯的統(tǒng)一的命名規(guī)范可以讓你的程序變得更容易閱讀和維護,當一個類,一個函數(shù),一個變量的名字達到了那種可以“望文生義”的境界話,我們就可以少一些文檔,少一些溝通。文章《編程中的命名設計那點事 》可以給你一些提示。

4.- 賦予每個類正確的職責
一個類,一個職責,這類規(guī)則可以參考一下類的SOLID 法則。但我們這里強調的不是一種單一的職責,而是一個正確的職責。如果你有一個類叫Customer,我們就不應該讓這個類有sales 的方法,我們只能讓這個類有和Customer有最直接關系的方法。

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

物理層組織:無論你使用什么樣的目錄,包(package)或名字空間(namespace)等的結構,你需要把你的類用一種標準的方法組織起來,這樣可以方便查找。這是一種物理性質的代碼組織。
邏輯層組織: 所謂邏輯層,主要是說,我們如果把兩個不同功能的類或方法通過某種規(guī)范聯(lián)系和組織起來。這里主要關注的是程序模塊間的接口。這就是我們經(jīng)常見到的程序模塊的架構。
6.- 創(chuàng)建大量的單元測試
單元測試是最接近BUG的地方,也是修改BUG成本最低的地方,同樣也是決定整個軟件質量好壞的成敗的地方。所以,只要有可能,你就應該寫更多的,更好的單元測試案例,這樣當你未來有相應代碼改變的時候,你可以很簡單知道你代碼的改變是否影響了其它單元。

7.- 經(jīng)常重構你的代碼
軟件開發(fā)是一種持續(xù)的發(fā)現(xiàn)的過程,從而讓你的代碼可以跟上最新的實際需求的變化。所以,我們要經(jīng)常重構自己的代碼來跟上這樣的變化。當然,重構是有風險的,并不是所有的重構都是成功的,也不是我們隨時都可以重構代碼。下面是兩個重構代碼的先要條件,以避免讓你引入更多的BUG,或是把本來就爛的代碼變得更爛。

有大量的單元測試來測試。正如前面所說,重構需要用大量的單元測試來做保障和測試。
每次重構都不要大,用點點滴滴的小的重構來代替那種大型的重構。有太多的時候,當我們一開始計劃重構2000行代碼,而在3個小時后,我們就放棄這個計劃并把代碼恢復到原始的版本。所以,我們推薦的是,重構最好是從點點滴滴積累起來的。
8.- 程序注釋是邪惡的
這一條一定是充滿爭議的,大多數(shù)程序員都認為程序注釋是非常好的,是的,沒錯,程序注釋在理論上是非常不錯的。但是,在實際過程序當中,程序員們寫出來的注釋卻是很糟糕的(程序員的表達能力很有問題),從而導致了程序注釋成為了一切邪惡的化身,也導致了我們在閱讀程序的時,大多數(shù)時候,我們都不讀注釋而直接讀代碼。所以,在這里,我們并不是鼓勵不寫注釋,而是——如果你的注釋寫得不夠好的話,那么,你還不如把更重要的時間花在重構一下你的代碼,讓你的代碼更加易讀,更加清楚,這比會比注釋更好。

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

10.- 代碼審查機制
所有人都會出錯,一個人出錯的概率是很大的,兩個人出錯的概率就會小一些,人多一些,出錯的概率就會越來越小。因為,人多了,就能夠從不同的角度看待一個事情,雖然這樣可能導致無效率的爭論,但比起軟件產(chǎn)品release后出現(xiàn)問題的維護成本,這點成本算是相當值得的。所以,這就是我們需要讓不同的人來 reivew代碼,代碼審查機制不但是一種發(fā)現(xiàn)問題的最有效的機制,同時也是一種可以知識共享的機制。當然,對于Code Review來說,下面有幾個基本原則:

審查者的能力一定要大于或等于代碼作者的能力,不然,代碼審查就成了一種對新手的training。
而且,為了讓審查者真正負責起來,而不是在敷衍審查工作,我們需要讓審查者對審查過的代碼負主要責任,而不是代碼的作者。
另外,好的代碼審查應該不是當代碼完成的時候,而是在代碼編寫的過程中,不斷地迭代代碼審查。好的實踐的,無論代碼是否完成,代碼審核需要幾天一次地不斷地進行。

相關文章

  • PHP學習 mysql

    PHP學習 mysql

    數(shù)據(jù)庫的基本概念data 數(shù)據(jù)database 數(shù)據(jù)庫 DBMS 數(shù)據(jù)庫管理系統(tǒng)DBS 數(shù)據(jù)庫系統(tǒng)sql 是結構化查詢語言
    2008-06-06
  • 基于PHP+MySQL的聊天室設計

    基于PHP+MySQL的聊天室設計

    MySQL并發(fā)能力強、響應速度快,是性能優(yōu)異的數(shù)據(jù)庫軟件;PHP是功能強大的服務器端腳本語言
    2006-10-10
  • PHP的FTP學習(二)[轉自奧索]

    PHP的FTP學習(二)[轉自奧索]

    PHP的FTP學習(二)[轉自奧索]...
    2006-10-10
  • PHP也可以當成Shell Script

    PHP也可以當成Shell Script

    PHP也可以當成Shell Script...
    2006-10-10
  • php預定義常量

    php預定義常量

    php預定義常量...
    2006-12-12
  • PHP Pear 安裝及使用

    PHP Pear 安裝及使用

    關于PHP Pear 安裝及使用
    2009-03-03
  • PHP 第一節(jié) php簡介

    PHP 第一節(jié) php簡介

    PHP是一種在電腦上運行的腳本語言,她的創(chuàng)始人是拉斯姆斯·勒多夫,最早的兩個PHP版本就是由此人開發(fā)的;開發(fā)PHP語言的初衷比較簡單,是為了維護個人網(wǎng)頁、統(tǒng)計流量等。在1995年6月8日作者為了加速發(fā)展和優(yōu)化,發(fā)布了她,也就是開源了
    2012-04-04
  • 用cookies來跟蹤識別用戶

    用cookies來跟蹤識別用戶

    用cookies來跟蹤識別用戶...
    2006-10-10
  • PHP學習之PHP運算符

    PHP學習之PHP運算符

    PHP學習之PHP運算符...
    2006-10-10
  • PHP 數(shù)組實例說明

    PHP 數(shù)組實例說明

    今天突然碰到了php的問題,發(fā)現(xiàn)這篇文章,很老的文章了,但很實用,下一篇我將整理更新的php5的數(shù)組
    2008-08-08

最新評論