程式員修煉之道（通俗版）——第八章

《程式員修煉之道》這本書中的内容挺不錯，裡面包含了很多精華，但一些句子很拗口，是以我就根據國人的閱讀習慣，在不改變原意的情況下對詞句稍加修改，标題中的“通俗版”就是這麼來的。

1、我們喜歡按照功能劃分的團隊。把你的人劃分成小團隊，分别負責系統特定方面的功能。讓各團隊按照各人的能力，在内部自行組織。每個團隊都按照他們約定的承諾，對項目中的其他團隊負有責任。承諾的确切内容随項目而變化，團隊間的人員配置設定也是如此。

這樣按功能組織有什麼好處？使用我們用于組織代碼的相同技術，去用像合約、解耦、正交性這樣的技術組織我們的各種資源，有助于使團隊作為整體與變化的各種效應隔離開來。如果使用者突然決定變更資料庫供應商，應該隻有資料庫團隊受影響。如果市場部突然決定使用現成工具來實作日程安排功能，隻有日程小組會受影響。适當地加以運用，這種分組方式能夠極大地減少各個開發者之間的互相影響。縮短時間标度、提高品質、并減少缺陷的數目。這種途徑還能帶來更願意付出的開發者，每個團隊都知道他們要對特定的功能負責，是以他們更會覺得自己是他們的工作成果的主人。

2、人的重複性并不像計算機那麼好。shell腳本或批處理檔案能以相同的次序、反複執行同樣的指令。它們能被置于源碼控制之下，你因而也可以檢查流程的修改曆史（“昨天還能工作……”）

Linux中一個特别受歡迎的自動化工具是cron（或Windows NT上的“at”）。它允許我們安排無人照管的任務周期性地運作——通常是在午夜。例如下面的crrontab檔案指定，每天午夜過後5分鐘運作項目的nightly指令，每個工作日的淩晨3:15進行備份，每月第一天的午夜運作expense_reports

3、在“重複的危害”中，我們提倡生成代碼，以根據公共來源派生知識。我們可以利用make的依賴分析機制，讓這一過程變得更容易。給makefile增加規則，根據其他來源自動生成檔案，是一件相當簡單的事情。例如，我們想要根據一個XML檔案生成一個Java檔案，并編譯所得結果。

.SUFFIXES: .Java .class .xml

.xml .java:

perl convert .pl $< >[email protected]

.Java .class

$(JAVAC) $(JAVAC_FLAGS) $<

敲入make test.class，make就會自動查找名為test.xml的檔案，通過運作Perl腳本建構一個.java檔案，然後編譯該檔案，産生test.class。

這看起來不錯，有機會得試一下。

4、如果程式員能夠把他們的所有時間投入實際程式設計，那不是很好嗎？遺憾的是，難得有這樣的情況。有E-mail要回複，有書面工作要完成，有文檔要釋出到Web上，等等。你可以建立一個shell腳本來完成一些煩人的工作，但你仍然要記得在需要時運作這個腳本。

因為記憶是随着你的年齡增長而喪失的第二種東西，我們不想過分依賴它。我們可以運作腳本，讓他們基于源碼和文檔的内容，自動為我們完成各種流程。我們的目标是維持自動、無人照管、内容驅動的工作流。

5、讓計算機去做重複、庸常的事情——它會做得比我們更好。我們有更重要、更困難的事情要做。

6、尋找bug有點像是用網捕魚。我們用纖小的網（單元測試）捕捉小魚，用粗大的網（內建測試）捕捉吃人的鲨魚。有時魚會設法逃跑，是以為了抓住在我們的項目裡遊動地、越來越狡猾的缺陷，要補上我們發現的任何漏洞。

許多團隊都會為他們的項目精心制定測試計劃，但實際上，使用自動測試的團隊更容易成功。

7、編碼完成的标志不是你已經寫完了這段代碼，而是你寫完的這段代碼已經通過了全部測試。

8、回歸測試把目前測試的輸出與先前的（或已知的）值進行對比。我們可以确定我們今天對bug的修正沒有破壞昨天可以工作的代碼。這是一個重要的安全網，它能減少令人不快的意外。

我們到目前為止提到過的所有測試都可以作為回歸測試運作，確定我們在開發新代碼時沒有損失任何領地。我們可以運作回歸測試，對性能、合約、有效性等進行校驗。

9、一旦測試人員找到了某個bug，這應該是測試人員最後一次發現這個bug。應該對自動化測試進行修改，從此每次都檢查那個特定的bug，沒有例外，不管多瑣碎，也不管開發者怎樣抱怨說：“哦，那絕不會再發生了。”

因為它會再次發生，而我們完全沒必要花時間去追蹤自動化測試本可以為我們找到的bug。我們必須把時間花在編寫代碼——以及新的bug——上。

10、一般而言，注釋應該讨論為何要做某事、它的目的和目标。代碼已經說明了它是怎樣完成的，是以再為此加上注釋是多餘的——而且違反了DRY原則。

注釋可以讓你把項目的那些難以描述、容易忘記，卻又不能記載到其他地方的東西記載下來：工程上的權衡、為何要做出某些決策、放棄了哪些替代方案，等等。

11、在源檔案裡應該出現的最重要的資訊之一是作者的姓名——不一定是最後編輯檔案的人，可以是檔案的所有者。使責任和義務與源碼聯系起來，能夠奇迹般地使人保持誠實。

12、以一種類似的方式使用像JavaDoc和DOC++這樣的工具，我們可以根據源碼生成API級的文檔。模型是源碼：模型的一種視圖可以編譯；其他視圖可用于列印或在Web上檢視。我們的目标是總在模型上工作——不管模型是代碼自身還是某種其他文檔，并且讓所有視圖自動更新。突然間，文檔沒那麼糟糕了。

這聽起來很不錯，值得我們玩一下。

13、在抽象意義上，應用如果能正确實作其規範，就是成功的。遺憾的是，這種事隻活在夢裡。

在現實中，項目的成功是由它在多大程度上滿足了使用者的期望來衡量的。不符合使用者預期的項目注定是失敗的，不管你認為傳遞的産品有多好。