|
|
DRY 是一個(gè)最簡(jiǎn)單的法則，也是最容易被理解的。但它也可能是最難被應(yīng)用的（因?yàn)橐龅竭@樣，我們需要在泛型設(shè)計(jì)上做相當(dāng)?shù)呐?，這并不是一件容易的事）。它意味著，當(dāng)我們?cè)趦蓚€(gè)或多個(gè)地方的時(shí)候發(fā)現(xiàn)一些相似的代碼的時(shí)候，我們需要把他們的共性抽象出來(lái)形一個(gè)唯一的新方法，并且改變現(xiàn)有的地方的代碼讓他們以一些合適的參數(shù)調(diào)用這個(gè)新的方法。
DRY 這一法則可能是編程屆中最通用的法則了，目前為止，應(yīng)該沒(méi)有哪個(gè)程序員對(duì)這一法則存有異議。但是，我們卻能發(fā)現(xiàn)，一些程序在編寫(xiě)單元測(cè)試（unit testing）時(shí)忘記了這一法則：讓我們相像一下，當(dāng)你改變一個(gè)類(lèi)的若干接口，如果你沒(méi)有使用DRY，那么，那些通過(guò)調(diào)用一系例類(lèi)的接口的unit test的程序，都需要被手動(dòng)的更改。比如：如果你的unit test的諸多test cases中沒(méi)有使用一個(gè)標(biāo)準(zhǔn)共有的構(gòu)造類(lèi)的方法，而是每個(gè)test case自己去構(gòu)造類(lèi)的實(shí)例，那么，當(dāng)類(lèi)的構(gòu)造函數(shù)被改變時(shí)，你需要修改多少個(gè)test cases啊。這就是不使用DRY法則所帶來(lái)的惡果。
2.- 短小的方法.
至少，我們有下面三個(gè)不錯(cuò)的理由要求程序員們寫(xiě)下短小的方法。
代碼會(huì)變得更容易閱讀。
代碼會(huì)變得更容易重用（短方法可以減少代碼間的耦合程度）
代碼會(huì)變得更容易測(cè)試。
3.- 良好的命名規(guī)范
使用不錯(cuò)的統(tǒng)一的命名規(guī)范可以讓你的程序變得更容易閱讀和維護(hù)，當(dāng)一個(gè)類(lèi)，一個(gè)函數(shù)，一個(gè)變量的名字達(dá)到了那種可以“望文生義”的境界話，我們就可以少一些文檔，少一些溝通。文章《編程中的命名設(shè)計(jì)那點(diǎn)事 》可以給你一些提示。
4.- 賦予每個(gè)類(lèi)正確的職責(zé)
一個(gè)類(lèi)，一個(gè)職責(zé)，這類(lèi)規(guī)則可以參考一下類(lèi)的SOLID 法則。但我們這里強(qiáng)調(diào)的不是一種單一的職責(zé)，而是一個(gè)正確的職責(zé)。如果你有一個(gè)類(lèi)叫Customer，我們就不應(yīng)該讓這個(gè)類(lèi)有sales 的方法，我們只能讓這個(gè)類(lèi)有和Customer有最直接關(guān)系的方法。
5.- 把代碼組織起來(lái)
把代碼組織起來(lái)有兩具層次。
物理層組織：無(wú)論你使用什么樣的目錄，包(package)或名字空間(namespace)等的結(jié)構(gòu)，你需要把你的類(lèi)用一種標(biāo)準(zhǔn)的方法組織起來(lái)，這樣可以方便查找。這是一種物理性質(zhì)的代碼組織。
邏輯層組織： 所謂邏輯層，主要是說(shuō)，我們?nèi)绻褍蓚€(gè)不同功能的類(lèi)或方法通過(guò)某種規(guī)范聯(lián)系和組織起來(lái)。這里主要關(guān)注的是程序模塊間的接口。這就是我們經(jīng)常見(jiàn)到的程序模塊的架構(gòu)。
6.- 創(chuàng)建大量的單元測(cè)試
單元測(cè)試是最接近BUG的地方，也是修改BUG成本最低的地方，同樣也是決定整個(gè)軟件質(zhì)量好壞的成敗的地方。所以，只要有可能，你就應(yīng)該寫(xiě)更多的，更好的單元測(cè)試案例，這樣當(dāng)你未來(lái)有相應(yīng)代碼改變的時(shí)候，你可以很簡(jiǎn)單知道你代碼的改變是否影響了其它單元。
7.- 經(jīng)常重構(gòu)你的代碼
軟件開(kāi)發(fā)是一種持續(xù)的發(fā)現(xiàn)的過(guò)程，從而讓你的代碼可以跟上最新的實(shí)際需求的變化。所以，我們要經(jīng)常重構(gòu)自己的代碼來(lái)跟上這樣的變化。當(dāng)然，重構(gòu)是有風(fēng)險(xiǎn)的，并不是所有的重構(gòu)都是成功的，也不是我們隨時(shí)都可以重構(gòu)代碼。下面是兩個(gè)重構(gòu)代碼的先要條件，以避免讓你引入更多的BUG，或是把本來(lái)就爛的代碼變得更爛。
有大量的單元測(cè)試來(lái)測(cè)試。正如前面所說(shuō)，重構(gòu)需要用大量的單元測(cè)試來(lái)做保障和測(cè)試。
每次重構(gòu)都不要大，用點(diǎn)點(diǎn)滴滴的小的重構(gòu)來(lái)代替那種大型的重構(gòu)。有太多的時(shí)候，當(dāng)我們一開(kāi)始計(jì)劃重構(gòu)2000行代碼，而在3個(gè)小時(shí)后，我們就放棄這個(gè)計(jì)劃并把代碼恢復(fù)到原始的版本。所以，我們推薦的是，重構(gòu)最好是從點(diǎn)點(diǎn)滴滴積累起來(lái)的。
8.- 程序注釋是邪惡的
這一條一定是充滿爭(zhēng)議的，大多數(shù)程序員都認(rèn)為程序注釋是非常好的，是的，沒(méi)錯(cuò)，程序注釋在理論上是非常不錯(cuò)的。但是，在實(shí)際過(guò)程序當(dāng)中，程序員們寫(xiě)出來(lái)的注釋卻是很糟糕的（程序員的表達(dá)能力很有問(wèn)題），從而導(dǎo)致了程序注釋成為了一切邪惡的化身，也導(dǎo)致了我們?cè)陂喿x程序的時(shí)，大多數(shù)時(shí)候，我們都不讀注釋而直接讀代碼。所以，在這里，我們并不是鼓勵(lì)不寫(xiě)注釋?zhuān)迁D―如果你的注釋寫(xiě)得不夠好的話，那么，你還不如把更重要的時(shí)間花在重構(gòu)一下你的代碼，讓你的代碼更加易讀，更加清楚，這比會(huì)比注釋更好。
9.- 注重接口，而不是實(shí)現(xiàn)
這是一個(gè)最經(jīng)典的規(guī)則了。接口注重的是――“What”是抽象，實(shí)現(xiàn)注重的是――“How”是細(xì)節(jié)。接口相當(dāng)于一種合同契約，而實(shí)際的細(xì)節(jié)相當(dāng)于對(duì)這種合同契約的一種運(yùn)作和實(shí)現(xiàn)。運(yùn)作是可以很靈活的，而合同契約則需要是相對(duì)需要穩(wěn)定和不變的。如果，一個(gè)接口沒(méi)有設(shè)計(jì)好而需要經(jīng)常性的變化的話，那我們可以試想一下，這代來(lái)的后果，這絕對(duì)會(huì)是一件成本很大的事情。所以，在軟件開(kāi)發(fā)和調(diào)設(shè)中，接口是重中之重，而不是實(shí)現(xiàn)。然而我們的程序員總是注重于實(shí)現(xiàn)細(xì)節(jié)，所以他們局部的代碼寫(xiě)的非常不錯(cuò)，但軟件整體卻設(shè)計(jì)得相對(duì)較差。這點(diǎn)需要我們多多注意。
10.- 代碼審查機(jī)制
所有人都會(huì)出錯(cuò)，一個(gè)人出錯(cuò)的概率是很大的，兩個(gè)人出錯(cuò)的概率就會(huì)小一些，人多一些，出錯(cuò)的概率就會(huì)越來(lái)越小。因?yàn)?，人多了，就能夠從不同的角度看待一個(gè)事情，雖然這樣可能導(dǎo)致無(wú)效率的爭(zhēng)論，但比起軟件產(chǎn)品release后出現(xiàn)問(wèn)題的維護(hù)成本，這點(diǎn)成本算是相當(dāng)值得的。所以，這就是我們需要讓不同的人來(lái) reivew代碼，代碼審查機(jī)制不但是一種發(fā)現(xiàn)問(wèn)題的最有效的機(jī)制，同時(shí)也是一種可以知識(shí)共享的機(jī)制。當(dāng)然，對(duì)于Code Review來(lái)說(shuō)，下面有幾個(gè)基本原則：
審查者的能力一定要大于或等于代碼作者的能力，不然，代碼審查就成了一種對(duì)新手的training。
而且，為了讓審查者真正負(fù)責(zé)起來(lái)，而不是在敷衍審查工作，我們需要讓審查者對(duì)審查過(guò)的代碼負(fù)主要責(zé)任，而不是代碼的作者。
另外，好的代碼審查應(yīng)該不是當(dāng)代碼完成的時(shí)候，而是在代碼編寫(xiě)的過(guò)程中，不斷地迭代代碼審查。好的實(shí)踐的，無(wú)論代碼是否完成，代碼審核需要幾天一次地不斷地進(jìn)行。
php技術(shù)：程序員編程十條戒律，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
