超碰人人人人人,色婷婷综合久久久久中文一区二区,国产-第1页-浮力影院,欧美老妇另类久久久久久

    原則14：把相關(guān)的定義放在一起。設(shè)計(jì)代碼結(jié)構(gòu)時(shí)，確保高度相關(guān)的部分放在一起，有可能放在同一個(gè)類中。這是面向?qū)ο笤O(shè)計(jì)方法在封裝方面的一條標(biāo)準(zhǔn)原則。理想情況下，某個(gè)類之外的所有代碼不需要知道內(nèi)部運(yùn)行的細(xì)節(jié)。有些開發(fā)人員喜歡將細(xì)節(jié)分散在多個(gè)文件中，以便按不同方式加以組織：比如為了把所有相同的數(shù)據(jù)類型放在一起，或者按字母順序進(jìn)行組織。比方說，把一個(gè)類中所有常量放在與使用它們的包不同的另一個(gè)包當(dāng)中，就會(huì)增加不必要的程序復(fù)雜性。指導(dǎo)原則應(yīng)該是按相關(guān)性進(jìn)行分組，那樣可以隱藏復(fù)雜性。

    原則15：始終在簽入代碼之前運(yùn)行測試。這條準(zhǔn)則會(huì)幫助你滿足“千萬不要破壞編譯版本”的準(zhǔn)則。

    原則16：倉促優(yōu)化是萬惡之源。程序教父don knuth的這句名言今天依然適用。應(yīng)當(dāng)精心編寫代碼，避免微觀層面出現(xiàn)不必要的浪費(fèi)，但應(yīng)該等到基于實(shí)際的最終用戶用例對(duì)整個(gè)程序進(jìn)行壓力測試，再進(jìn)行單個(gè)方法層面之外的優(yōu)化。要是僅僅基于對(duì)代碼的靜態(tài)了解，就憑直覺判斷什么對(duì)整體性能來說很重要，幾乎肯定出錯(cuò)。相反，要度量整個(gè)系統(tǒng)的行為，找出真正影響性能的那1%的代碼，并關(guān)注這部分代碼。

    原則17：盡量減少積壓下來的沒有完成的編碼任務(wù)。開發(fā)人員開始編寫某個(gè)用例時(shí)，所有已被修改、但沒有完成及測試的代碼會(huì)發(fā)生成本。沒有完成的變更積壓幾天或幾周，會(huì)大大增加因改寫而導(dǎo)致浪費(fèi)的風(fēng)險(xiǎn)。設(shè)想一下有三個(gè)任務(wù)，每個(gè)任務(wù)估計(jì)需要一天。同時(shí)開始這三個(gè)任務(wù)，同時(shí)工作三天就需要累計(jì)9個(gè)“單位”的成本。但如果按順序處理每個(gè)任務(wù)，一個(gè)任務(wù)完成后開始下一個(gè)，那么只需要3個(gè)“單位”的成本。這并不直觀。直覺告訴我們：我們?cè)谔幚砣蝿?wù)時(shí)，最好還是同時(shí)做三件事。但軟件不像實(shí)體構(gòu)造。短小、快速、完整的任務(wù)不但可以減輕認(rèn)知負(fù)荷，還能減小未完成工作與另一個(gè)人的未完成工作發(fā)生沖突的可能性。

    原則18：千萬不要過于強(qiáng)調(diào)代碼的通用性。這就是有名的yagni，即“你不會(huì)需要它”。程序員在編寫某個(gè)特定類時(shí)，喜歡認(rèn)為：只要稍加改動(dòng)，該類可用于另外幾個(gè)用途。如果當(dāng)前用例需要這些用途，那很好；但是程序員通常會(huì)考慮還沒有發(fā)明出來的用途，或者是實(shí)際上根本不需要的用途。（這個(gè)話題老是讓我想到宣傳某款產(chǎn)品既是地板蠟、又是甜食配料的搞笑電視節(jié)目。）

    原則19：能用兩行代碼，就堅(jiān)決不要用三行。每當(dāng)別人要讀代碼時(shí)，簡單的代碼總是一目了然。但也不要把代碼簡化到人家很難讀懂的地步。與冗長代碼相比，簡潔代碼更容易維護(hù)，也更容易發(fā)現(xiàn)其中的錯(cuò)誤。始終要盡量簡化，但避免簡化過頭。

    原則20：千萬不要用行數(shù)來度量代碼。就完成特定任務(wù)所需的代碼行數(shù)而言，不同的程序員和編程風(fēng)格會(huì)造成很大的差異。代碼行數(shù)說明不了代碼有多全面、質(zhì)量有多好。代碼質(zhì)量有可能千差萬別；與代碼質(zhì)量相比，代碼行數(shù)顯得沒有太大的意義。而是應(yīng)統(tǒng)計(jì)切實(shí)可行的用例有多少。

    原則21：持續(xù)不斷地重新設(shè)計(jì)和重構(gòu)。運(yùn)用這條原則要慎重，因?yàn)橛行┐a很脆弱、很難改變，但一般而言，你用不著害怕更改代碼以符合實(shí)際用例。某個(gè)數(shù)據(jù)成員過去可能是整數(shù)，但是當(dāng)用例要求它是浮點(diǎn)數(shù)時(shí)，不要害怕更改。

    原則22：刪除無用代碼。說到并不完全了解的大段代碼，人們往往采取“別惹事生非”的做法。一個(gè)例子就是，為某個(gè)類增加一種新方法以替換另一種舊方法，而開發(fā)人員往往讓舊方法留在那里，僅僅為了“以防萬一”。應(yīng)當(dāng)花一番工夫，看看需不需要該方法；如果沒有證據(jù)表明需要它，就刪除。最糟糕的做法莫過于注釋掉了大段代碼，卻任由這些注釋代碼留在原處。一旦你知道測試完畢，就應(yīng)當(dāng)刪除注釋代碼，當(dāng)然要在簽入之前。隨時(shí)添加代碼很容易，隨時(shí)刪除代碼卻很難。因此，如果你清楚不需要某部分代碼，那么只需下一點(diǎn)力氣，核實(shí)并消除此代碼就能讓代碼庫維護(hù)起來更容易。

    原則23：不要發(fā)明新語言。程序員喜歡讓驅(qū)動(dòng)功能的文本文件在運(yùn)行時(shí)可以靈活配置。有好多配置文件在不重新編譯的情況下能夠改變程序的行為。xml的出現(xiàn)讓一批專門定制的“腳本語言”層出不窮：有了這些語言，最終用戶不必編譯，就能夠“編程”以實(shí)現(xiàn)功能。這種推論的缺陷在于，要是離開了具體實(shí)現(xiàn)的環(huán)境，就幾乎根本無法明確規(guī)定操作行為的精確定義；而這些類型的腳本語言主要只適用于那些對(duì)相應(yīng)代碼的內(nèi)部運(yùn)行有深入了解的人。因此，并不詳細(xì)了解內(nèi)部運(yùn)行的實(shí)際最終用戶永遠(yuǎn)不可能知道如何才能預(yù)料到復(fù)雜的命令組合會(huì)帶來什么影響。腳本語言是有用，也不能被抹殺，但是設(shè)計(jì)者必須采取一種極其保守的態(tài)度，盡可能使用現(xiàn)有語言，避免發(fā)明新的語言。

    原則24：等準(zhǔn)備好了實(shí)現(xiàn)并測試實(shí)現(xiàn)代碼，再進(jìn)行設(shè)計(jì)。你應(yīng)該總體上對(duì)工作方向有一些了解，并大致了解爭取建立的系統(tǒng)架構(gòu)。但在進(jìn)入到可以實(shí)現(xiàn)及測試該設(shè)計(jì)的開發(fā)迭代階段之前，不要做詳細(xì)設(shè)計(jì)，也不要編寫功能實(shí)現(xiàn)的詳細(xì)描述。詳細(xì)設(shè)計(jì)應(yīng)當(dāng)只涉及處理當(dāng)前用例所需的那部分。軟件開發(fā)中造成浪費(fèi)的最主要根源在于，把時(shí)間花在設(shè)計(jì)不需要、或者因?yàn)樵O(shè)計(jì)方面某些錯(cuò)誤的假定而需要重新設(shè)計(jì)的部分上。

    原則25：設(shè)計(jì)是可塑的。不像實(shí)體構(gòu)造，軟件可以輕而易舉地進(jìn)行重大改變。事實(shí)上，有許多證據(jù)可以證明：軟件比描述軟件的設(shè)計(jì)規(guī)格更容易改變。此外，軟件比規(guī)格更有效地傳達(dá)了設(shè)計(jì)思想。因此，你應(yīng)當(dāng)把時(shí)間花在直接實(shí)現(xiàn)設(shè)計(jì)上，以便客戶能看到設(shè)計(jì)的具體細(xì)節(jié)。如果你缺少某些功能、因而要改變?cè)O(shè)計(jì)，改變軟件會(huì)比改變規(guī)格來得容易。但最重要的是，客戶看到代碼運(yùn)行后，你就能非常清楚地知道客戶想要什么。

    原則26：花些時(shí)間編寫代碼來完整描述發(fā)現(xiàn)和報(bào)告異常情況的代碼中的問題。程序員往往很懶惰，對(duì)拋出的異常情況只給出簡單膚淺的描述，說明哪里出了錯(cuò)。以為只有他們自己才會(huì)看到這個(gè)問題；只要借助含糊籠統(tǒng)的描述，就會(huì)記得該問題的意思。但實(shí)際上，因錯(cuò)誤報(bào)告不準(zhǔn)確或不完整而浪費(fèi)在客戶支持情景上的時(shí)間比其他任何原因都要多。要編寫每一個(gè)錯(cuò)誤消息，就好像你向剛走入房間、對(duì)代碼毫無經(jīng)驗(yàn)的某個(gè)人說明情況。畢竟，客戶以及客戶支持團(tuán)隊(duì)對(duì)代碼是毫無經(jīng)驗(yàn)的。