當(dāng)我加入Ansible團(tuán)隊(duì)之后,，我決定寫下多年來所學(xué)到的軟件工程實(shí)踐和原理方面的經(jīng)驗(yàn),。我的激情是測(cè)試，因?yàn)槲蚁嘈帕己玫臏y(cè)試既可以確保最低質(zhì)量標(biāo)準(zhǔn)（可惜很多軟件產(chǎn)品都缺乏這一點(diǎn)）,，也可以指導(dǎo)和塑造開發(fā)過程本身,。以下許多建議與測(cè)試有關(guān)，其中一些原則甚至特定于Python,，但絕大多數(shù)不是,。（對(duì)于Python程序員，PEP 8應(yīng)該是編程風(fēng)格和指南的第一站,。）

1、不要編寫你認(rèn)為以后可能需要但目前不需要的代碼,。這是對(duì)未來想象的用例的編碼,，并且這種代碼一定會(huì)成為死碼或需要重寫，因?yàn)槲磥淼挠美偸桥c程序員的想象略有不同,。

注釋代碼也是如此,，如果一段注釋的代碼正在進(jìn)行發(fā)布，它不應(yīng)該存在,。YAGNI是編程的核心要素,，最佳參考資料是極限編程解析（Extreme Programming Explained）。

2,、不進(jìn)行多余的測(cè)試,。基礎(chǔ)設(shè)施,，框架和庫是需要測(cè)試的,，不要測(cè)試瀏覽器或外部庫，除非你真的需要,。測(cè)試你自己編寫的代碼,，而不是其他人寫的代碼。

3、多次重復(fù)出現(xiàn)的代碼不需要測(cè)試,。輔助功能不需要測(cè)試,，當(dāng)你把它們分開并重新使用時(shí)，需要測(cè)試,。如果反復(fù)編寫類似代碼多次時(shí),，您通常會(huì)很清楚正在解決的問題。

圖片源于網(wǎng)絡(luò)

4、關(guān)于API設(shè)計(jì)（外部面向?qū)ο驛PI）：簡單的事情盡量簡單完成,，復(fù)雜的事情盡力優(yōu)化,。首先為簡單案例設(shè)計(jì)，如果可能的話,，優(yōu)選為零配置或參數(shù)化,。Addoptions或附加的API方法，用于更復(fù)雜和更靈活的用例（根據(jù)需要）,。

5,、盡早檢查無意義的輸入或無效狀態(tài)，最好是異?；蝈e(cuò)誤響應(yīng),，這將使程序員很清楚問題的確切信息。（除非真的需要,，否則不要進(jìn)行輸入驗(yàn)證類型的檢查）,。

6、在可能的情況下,，將測(cè)試對(duì)象視為黑盒子,，通過公共API進(jìn)行測(cè)試，這就不需要調(diào)用私有方法或修改狀態(tài),。

對(duì)于一些復(fù)雜的場景,，編寫測(cè)試真的是有幫助的，因?yàn)檫@迫使程序員考慮代碼的行為以及在編寫代碼之后如何進(jìn)行測(cè)試,。測(cè)試首先鼓勵(lì)更小,、更模塊化的代碼單元，這通常意味著更好的代碼,。

7,、對(duì)于單元測(cè)試（包括基礎(chǔ)架構(gòu)測(cè)試），應(yīng)測(cè)試所有代碼路徑,。 100％的覆蓋是一個(gè)良好的開端,。除非你無法覆蓋所有可能的排列/組合的狀態(tài)，只有一個(gè)非常好的理由才能使代碼路徑不全部經(jīng)過測(cè)試,，以時(shí)間為借口早晚會(huì)浪費(fèi)更多時(shí)間,。

8,、代碼是敵人：可能出錯(cuò)，需要維護(hù),。盡量有更少的代碼實(shí)現(xiàn)必需的功能,，刪除不必要的代碼。

9,、努力通過良好的命名規(guī)范和已知的編程風(fēng)格使代碼可讀和形成自我記錄,。通常隨著時(shí)間的推移，很多程序員都不認(rèn)識(shí)自己寫的代碼了,。

10,、代碼注釋——對(duì)一些無法明確的代碼，請(qǐng)盡早提供注釋,，說明為什么要這么寫,，有無其他方法等。

11,、編碼過程中務(wù)必想想可能出現(xiàn)的問題,，無效輸入會(huì)發(fā)生什么，哪些情況會(huì)導(dǎo)致失敗,，這將有助于程序員在發(fā)生錯(cuò)誤之前捕獲更多錯(cuò)誤,。

12、簡單的邏輯易進(jìn)行單元測(cè)試,，將邏輯分解為單獨(dú)的函數(shù),，而不是將邏輯混合為有狀態(tài)和有副作用填充代碼。（測(cè)試的開銷越少意味著測(cè)試更快）,。

13,、使用對(duì)象可能比使用復(fù)雜的數(shù)據(jù)結(jié)構(gòu)更好。使用Python的內(nèi)置類型及其方法將比編寫自己的類型更快（除非您在C中編寫）,。如果考慮性能,，請(qǐng)嘗試了解如何使用標(biāo)準(zhǔn)內(nèi)置類型而不是自定義對(duì)象。

14,、依賴注入是一個(gè)有用的編碼模式,，用于程序員搞清楚依賴關(guān)系以及它們來自哪里（有對(duì)象，方法等作為參數(shù)接收它們的依賴關(guān)系,，而不是實(shí)例化新對(duì)象本身）,。關(guān)于依賴注入的文章可參考Martin Fowler的“Inversion of Control Containers and the Dependency Injection Pattern”。

15,、代碼越多,，代碼越差。程序員的目標(biāo)應(yīng)該是小型的可測(cè)試單元，以及更高級(jí)的集成和功能測(cè)試,，以測(cè)試單元是否正確合作,。

圖片源于網(wǎng)絡(luò)

16,、設(shè)計(jì)API時(shí)應(yīng)該考慮到以后可能會(huì)遇到的更改,，并考慮到未來的用例——真的很重要。改變API對(duì)程序員和用戶而言都是一種痛苦,，并且創(chuàng)建向后的不兼容性是可怕的（盡管有時(shí)不可避免）,。

17、如果函數(shù)或方法超過30行代碼,，請(qǐng)考慮將其分解,。最大模塊尺寸為500行，測(cè)試文件往往比這更長,。

18,、不要在對(duì)象構(gòu)造函數(shù)中工作,，這很難測(cè)試,。不要將代碼放在__init__.py中（除了用于命名空間的導(dǎo)入）。 __init__.py不是程序員通常期望找到代碼的地方,。

19,、在測(cè)試中，單個(gè)測(cè)試文件的可讀性比可維護(hù)性更重要（打破可重用的塊）,。這是因?yàn)闇y(cè)試被單獨(dú)執(zhí)行和讀取,，而不是自己成為較大系統(tǒng)的一部分，顯然過多的重復(fù)意味著可以為了方便而創(chuàng)建可重復(fù)使用的組件,，這不僅僅是生產(chǎn)問題,。

20、盡可能使用重構(gòu),。編程是抽象的,，越接近問題域，代碼越容易理解和維護(hù),。隨著系統(tǒng)的發(fā)展,，用例的結(jié)構(gòu)需要改變和擴(kuò)展。一本關(guān)于重構(gòu)和測(cè)試的書是Michael Feathers的Working Effectively with Legacy Code,。

21,、在處理性能問題時(shí)，請(qǐng)務(wù)必在修復(fù)之前進(jìn)行配置,。如果你已經(jīng)剖析并證明代碼實(shí)際上是值得的,，編寫一個(gè)測(cè)試隨時(shí)對(duì)代碼進(jìn)行分析，并且保留在測(cè)試套件中以防止性能回歸。（添加時(shí)間碼總是會(huì)改變代碼的性能特征,，使性能成為更令人沮喪的任務(wù)之一）,。

22、更小,，更嚴(yán)格的單位測(cè)試在失敗時(shí)提供更有價(jià)值的信息,。通常，運(yùn)行超過0.1秒的測(cè)試不是單元測(cè)試,。單元測(cè)試可以提供更具體的錯(cuò)誤信息,，關(guān)于單元測(cè)試實(shí)踐一本不錯(cuò)的書是Gary Bernhardt的Fast Test, Slow Test。

23,、遵循YAGNI原則：編寫我們需要的特定代碼,，而不是不需要的、復(fù)雜性的通用代碼,。

24,、共享代碼所有權(quán)是目標(biāo)。不分享或許就發(fā)現(xiàn)不了更好的編寫方式,，比如分享出來,，大家集思廣益。

25,、最后,，可以告訴產(chǎn)品經(jīng)理或開發(fā)商，一味地增加功能并不是好事,，確保核心功能的高效率工作就可以了,。