7個(gè)軟件開(kāi)發(fā)原則

一無(wú)所有

7個(gè)軟件開(kāi)發(fā)原則　
關(guān)于代碼重復(fù)最著名的單詞是Kent Beck的Once And Only Once，也就是說(shuō)軟件操作的任何一個(gè)片斷--不管是一個(gè)算法，一個(gè)常量集合，用于閱讀的文檔或者其他東西--應(yīng)當(dāng)只出現(xiàn)一次。
軟件重復(fù)出現(xiàn)至少會(huì)導(dǎo)致以下問(wèn)題：
· 其中的一個(gè)版本會(huì)過(guò)期
· 代碼的責(zé)任會(huì)四處散開(kāi)，導(dǎo)致代碼難以理解
· 當(dāng)你修改代碼時(shí)，需要重復(fù)修改很多地方，一不小心就會(huì)遺漏
· 你不能很好地進(jìn)行性能優(yōu)化

我以前的一位老板曾經(jīng)跟我夸耀過(guò)他手下編程的能力：“他只要把一份模版代碼拷過(guò)去，稍加修改，就可以完成一個(gè)新的模塊“。我驚訝這位程序員思路清晰的同時(shí)也懷疑這樣的程序除了他自己以外還有誰(shuí)能維護(hù)，我想可能連他自己也無(wú)法做到。
重復(fù)代碼的產(chǎn)生由各種各樣的原因，上面的例子就是一個(gè)，我經(jīng)�？吹匠绦騿T把幾行或一整段代碼從這里復(fù)制到這里，然后少加修改，就變成了一份新的代碼。這里的原因是程序員可以通過(guò)極少的努力就完成代碼重用，但是我們可以來(lái)看看DavidHooker提出的7個(gè)軟件開(kāi)發(fā)原則:
1.第一原則：存在的理由(Pattern: TheReason)
一個(gè)軟件系統(tǒng)存在的理由就是：為它的用戶提供價(jià)值。你所有的決定都取決于這一點(diǎn)。在指定一個(gè)系統(tǒng)需求，在寫下一段系統(tǒng)功能，在決定硬件平臺(tái)和開(kāi)發(fā)過(guò)程之前，問(wèn)你自己一個(gè)問(wèn)題，“這樣做會(huì)為系統(tǒng)增加價(jià)值嗎？“，如果答案是”yes”，做。如果是”No”,不做。這個(gè)原則是其他原則的原則。
2．第二原則（能簡(jiǎn)單就簡(jiǎn)單，愚蠢�。㎏ISS (Pattern: KeepItSimple)
軟件設(shè)計(jì)不是一個(gè)輕描淡寫的過(guò)程。在做任何一個(gè)設(shè)計(jì)時(shí)，你必須考慮很多因素。所有設(shè)計(jì)應(yīng)當(dāng)盡可能簡(jiǎn)單，但是不要再比這簡(jiǎn)單了。這樣產(chǎn)生的系統(tǒng)才是可以理解和容易維護(hù)的。這并不是說(shuō)很多由意義的特性，因?yàn)檫@種簡(jiǎn)單性也要被拋棄。確實(shí)很多更優(yōu)雅的設(shè)計(jì)往往更簡(jiǎn)單，但簡(jiǎn)單并不意味著“quick and dirty."。事實(shí)上，簡(jiǎn)單是通過(guò)許多思考和一次一次的反復(fù)修改才達(dá)到的。這些努力的匯報(bào)就是更容易維護(hù)，代碼錯(cuò)誤更少。 （看看是否違反）
3．第三原則 ：保持遠(yuǎn)見(jiàn)(Pattern: MaintainTheVision)
清晰的遠(yuǎn)見(jiàn)是一個(gè)軟件項(xiàng)目成功的基礎(chǔ)。. 沒(méi)有這樣的遠(yuǎn)見(jiàn)，項(xiàng)目開(kāi)發(fā)最后就變成天天為一個(gè)不好的設(shè)計(jì)做補(bǔ)丁。Brooks說(shuō)過(guò)：
概念的完整性是系統(tǒng)設(shè)計(jì)中最重要的問(wèn)題。
Stroustrup 也說(shuō)：
有一個(gè)干凈的內(nèi)部結(jié)構(gòu)識(shí)構(gòu)建一個(gè)可理解、可辨識(shí)、可維護(hù)
、可測(cè)試系統(tǒng)的基礎(chǔ)。
Booch則總結(jié)道：
只有當(dāng)你對(duì)系統(tǒng)的體系由一個(gè)清晰的感覺(jué)，才可能去發(fā)現(xiàn)通用的抽象和機(jī)制。開(kāi)發(fā)這種通用性最終導(dǎo)致系統(tǒng)更簡(jiǎn)單，因此更小，更可靠
如果你不斷地復(fù)制、粘貼、修改代碼，最終你將陷入一個(gè)大泥潭(the Big Mud),你永遠(yuǎn)不可能對(duì)系統(tǒng)有一個(gè)清晰的認(rèn)識(shí)。
4.第四原則：你制造的，別人會(huì)消費(fèi) (Pattern: WhatYouProduceTheyConsume)
軟件系統(tǒng)不是在真空中使用的。其他人會(huì)使用、維護(hù)、文檔你的系統(tǒng)。這依賴于對(duì)你系統(tǒng)的理解。所以，你設(shè)計(jì)、實(shí)現(xiàn)的東西應(yīng)當(dāng)能夠讓別人理解。要記住，你寫的代碼并非只給計(jì)算機(jī)看，你要時(shí)時(shí)記住，代碼還要給人看。(Kent Beck)
如果到處泛濫似是而非的代碼，別人如何能夠辨別這些代碼的相似和不同，如何去理解這些代碼之間具有何種關(guān)系。
5．第五原則：對(duì)將來(lái)開(kāi)放( Pattern BuildForTodayDesignForTomorrow)
一個(gè)成功的軟件有很長(zhǎng)的生命期。你必須能夠使得軟件能夠適應(yīng)這樣和那樣的變化。所以，一開(kāi)始就不要軟件設(shè)計(jì)到死角上去。請(qǐng)總是問(wèn)一下自己“如果這樣，那么。。？“這個(gè)問(wèn)題，你要考慮到各種各樣的可能性，而不光光是圖省事。復(fù)制，粘貼一下即可。
6．第六原則：為重用做好計(jì)劃
軟件模式是重用計(jì)劃的一種。不斷重復(fù)的代碼顯然不是這樣的計(jì)劃。
(See CommentsOnSix)
7．第七原則：思考！
在采取任何動(dòng)作之前首先做一個(gè)清晰、完整的考慮，這樣才能產(chǎn)生更好的結(jié)果。如果你考慮了，但還是產(chǎn)生錯(cuò)誤的結(jié)果，那么這種努力也是值得的。在你學(xué)習(xí)或研究類似的問(wèn)題時(shí)，更容易理解和掌握。

這些原則告訴我們輕松地復(fù)制、粘貼和修改代碼不可能產(chǎn)生好的，也就是容易理解、維護(hù)、重用的代碼。但請(qǐng)不要走極端。
我一直認(rèn)為，一個(gè)好的軟件系統(tǒng)是各種因素權(quán)衡的結(jié)果，也就是你如何把握一個(gè)度的問(wèn)題。重復(fù)代碼產(chǎn)生的另外一個(gè)主要原因就是做得太多，XP有一個(gè)基本原則叫做You Arent Gonna Need It，它是說(shuō)“只實(shí)現(xiàn)你真正需要的東西，從來(lái)不去實(shí)現(xiàn)你預(yù)期需要的東西“。如果你去實(shí)現(xiàn)你現(xiàn)在認(rèn)為將來(lái)需要的東西，不一定就是你以后真正需要的東西。你處于現(xiàn)在的環(huán)境中可能無(wú)法理解你要實(shí)現(xiàn)東西究竟是什么樣子的。你會(huì)浪費(fèi)大量的時(shí)間去構(gòu)造這樣不知道是否必須的可能性。同時(shí)，當(dāng)你真正實(shí)現(xiàn)的時(shí)候就可能產(chǎn)生重復(fù)代碼。

Martin Fowler在它的Refactoring一書中有很多用來(lái)處理代碼重復(fù)，包括：
1． 同一個(gè)類的兩個(gè)方法中有相同的表達(dá)式,使用Extract method，然后大家都調(diào)用該method;
2． 兩個(gè)兄弟子類之間有相同的表達(dá)式，那么在這兩個(gè)子類中使用Extract Method,接著使用pull up field,移到共同的超類
3． 如果結(jié)構(gòu)相似而并非完全相同，用Extract method把相同部分和不同部分分開(kāi)。然后使用form Template method.
4． 如果方法使用不同的算法做相同的事情，那么使用substitute algorithm
5． 如果在兩個(gè)不相干的類中有重復(fù)代碼，那么在一個(gè)類中使用Extract class，然后在其他類中使用該class對(duì)象作為元素。
等等。

重復(fù)代碼需要refactoring是毫無(wú)疑問(wèn)的，關(guān)鍵在于，你如何找到重復(fù)代碼，如果所有的重復(fù)代碼都是死板的重復(fù)，那問(wèn)題是很容易解決的。但是軟件開(kāi)發(fā)的復(fù)雜因素可能往往使重復(fù)代碼表現(xiàn)為相似性而并非完全的重復(fù)。這些相似性可能并非一眼就能看出來(lái)。而是需要經(jīng)過(guò)其它的Refactory步驟和一定的先見(jiàn)之明。
另一個(gè)問(wèn)題就是排除重復(fù)代碼的粒度，只有大段的重復(fù)代碼有價(jià)值去排除，還是即使是小小的2、3句重復(fù)代碼就應(yīng)該去排除。重復(fù)代碼排除的基本方法是建立自己?jiǎn)为?dú)的方法，如果系統(tǒng)中許許多多的方法都很小，方法之間相互調(diào)用的開(kāi)銷就會(huì)增加，它同時(shí)也增加了維護(hù)的開(kāi)銷。
但是，這些開(kāi)銷是值得的。方法是覆蓋的最小粒度，能夠被覆蓋的粒度越小，能夠重用的范圍和成都就愈廣。但在這個(gè)問(wèn)題上也不要走極端，只有當(dāng)一個(gè)方法實(shí)現(xiàn)一個(gè)具體的可以用Intent Revealing Name(揭示意圖的名字)命名時(shí)，一段代碼才值得稱為一個(gè)方法，而不是考慮其代碼的多少。

Martin Fowler在他的refactoring中描述了很多這樣的例子，Kent Beck則在Smalltalk Best Practice Pattern中更基礎(chǔ)地揭示了隱含在這些refactoing下的意圖。
下面是一個(gè)實(shí)際的例子，來(lái)自于Martin Fowler在ACM上的設(shè)計(jì)專欄：
class Invoice...
String asciiStatement() {

StringBuffer result = new StringBuffer();
result.append(“Bill for “ + customer + “\n”);
Iterator it = items.iterator();
while(it.hasNext()) {
LineItem each = (LineItem) it.next();
result.append(“\t” + each.product() + “\t\t”
+ each.amount() + “\n”);
}
result.append(“total owed:” + total + “\n”);
return result.toString();
}
String htmlStatement() {
StringBuffer result = new StringBuffer();
result.append(“
Bill for ” + customer + “

”);
result.append(“”);
Iterator it = items.iterator();
while(it.hasNext()) {
LineItem each = (LineItem) it.next();
result.append(“ ” + each.product()
+ “ ” + each.amount() + “
”);
}
result.append(“ ”);
result.append(“
total owed:” + total + “

”);
return result.toString();
}
}
asciiStatement和htmlStatement具有類似的基礎(chǔ)結(jié)構(gòu)，但是它們的實(shí)際步驟卻有所不同。他們都完成三件事情：
1． 打印發(fā)票頭
2． 循環(huán)每一個(gè)項(xiàng)目，并打印
3． 打印發(fā)票尾部
這種結(jié)構(gòu)的相似性和意圖馬上上我們使用composed method(也就是Martin Fowler的Extract method):

interface Printer {
String header(Invoice iv);
String item(LineItem line);
String footer(Invoice iv);
}
static class AsciiPrinter implements Printer {
public String header(Invoice iv) {
return “Bill for “ + iv.customer + “\n”;
}
public String item(LineItem line) {
return “\t” + line.product()+ “\t\t” + line.amount() +“\n”;
}
public String footer(Invoice iv) {
return “total owed:” + iv.total + “\n”;
}
}
象html則可以實(shí)現(xiàn)htmlPrinter.
class Invoice...
public String statement(Printer pr) {
StringBuffer result = new StringBuffer();
result.append(pr.header(this));
Iterator it = items.iterator();
while(it.hasNext()) {
LineItem each = (LineItem) it.next();
result.append(pr.item(each));
}
result.append(pr.footer(this));
return result.toString();
}
class Invoice...
public String asciiStatement2() {
return statement (new AsciiPrinter());
}

現(xiàn)在，statement包含一個(gè)通用的結(jié)構(gòu)，重復(fù)性已經(jīng)被排除。更重要的是，你可以實(shí)現(xiàn)其它的Printer,XXXPrinter,從而能夠輕易地?cái)U(kuò)展系統(tǒng)。
BTW,Martin Fowler在這里使用了Dispatched Interpretation模式，statement隱瞞了內(nèi)部的細(xì)節(jié)，它隱藏內(nèi)部的數(shù)據(jù)和表示，當(dāng)它需要Printer做一件事情時(shí)，它負(fù)責(zé)解碼內(nèi)部的數(shù)據(jù)結(jié)構(gòu)，然后反過(guò)來(lái)把消息傳給Printer.

參見(jiàn)：Martin Fowler:Refactoring:Improve the design of Existing Code
Kent Beck : Smalltalk Best Pratice Pattern
ACM: Martin Fowler Design column:Reduce repetation
Kent Beck: Extreme Programming Explained

mmhh516

好��！學(xué)習(xí)！。。。。

一無(wú)所有

希望是可以給大家一些啟示，
   最重要的是要去做。

jack79_cn

好好學(xué)習(xí)吧﹐沒(méi)辦法。。。。。

linbird

原帖由 "一無(wú)所有" 發(fā)表：
希望是可以給大家一些啟示，
   最重要的是要去做。

無(wú)雙

很不錯(cuò)
支持一個(gè)

torrent

我好像覺(jué)得說(shuō)的道理都對(duì)，但是實(shí)際編程的時(shí)候，卻不容易；特別是“對(duì)將來(lái)開(kāi)放”

軒轅砍刀

汗～～ 怎么這么多，看來(lái)我今后還有很多東西要注意的

nile

很多時(shí)候， 是因?yàn)槔习宓拇叽倩蚴瞧渌�技術(shù)之外的問(wèn)題， 才導(dǎo)致下面的人用快卻不是最優(yōu)的方法來(lái)實(shí)現(xiàn)。

一個(gè)項(xiàng)目，一個(gè)系統(tǒng)的很多問(wèn)題的根源其實(shí)在與程序之外。 責(zé)任和解決的任務(wù)也不能推給技術(shù)人員。 計(jì)算機(jī)解決不料體制或者決策的錯(cuò)誤。

這是我個(gè)人的觀點(diǎn)。

iddv

同意樓上。
技術(shù)和管理應(yīng)當(dāng)有較為公平的位置，
方便溝通