《程式設計師修煉之道》筆記八

第八章注重實效的專案

隨著你的專案開動，我們需要從個體的哲學和編碼問題轉向討論更大的、專案級的問題。我們將不深入專案管理的具體細節，而是要討論能使專案成功或失敗的幾個關鍵區域。

1. 注重實效的團隊

書中前面的內容都是幫助個體成為更好的程式設計師，這些方法在對團隊來說仍然有效。

a) 不要留破窗戶。質量是乙個團隊的問題。最勤勉的開發者如果被派到不在乎質量的團隊裡，也會發現自己很難保持修正瑣碎問題所需的熱情。團隊作為乙個整體，不應該容忍破窗戶——那些小小的、無人修正的不完美。

b) 煮青蛙。在專案開發高漲的熱度裡，很難再用乙隻眼睛注意周圍的環境，所以作為整體的團隊甚至更容易被煮熟。即使是目的最明確的團隊對專案中的重大改動可能也會很健忘。團隊每個人都應該主動監視環境的變化，也可以指定專人負責檢查範圍的擴大、時間標度的縮減、新增特性、新環境之類任何不在最初約定中的東西。

c) 交流。對外界而言，沉悶寡言、文件混亂的團隊是糟糕的團隊。而傑出的團隊有著截然不同的個性，他們製作的文件準確、一致，團隊用乙個聲音說話，甚至還可能有幽默感。可以使用乙個營銷的訣竅，來幫助團隊作為整體與外界交流：創立品牌。在啟動專案時，給它取乙個不尋常的名字，這會給團隊乙個用於建設的身份標識。

d) dry。交流有助於消除團隊間的重複，此外可以安排專案成員分工擔任專案不同部分的資料管理員（比如資料庫schema、日期處理等）。

e) 正交性。要圍繞功能、而不是工作職務組織小團隊，這些小團隊分別負責最終系統的特定方面的功能，每個團隊都按照他們約定的承諾，對專案中的其他團隊負有責任。這種分組方式能夠極大地減少各個開發者的工作之間的相互影響。但是這種方法只有在專案擁有負責的開發者、以及強有力的專案管理時才會有效。

f) 自動化。自動化可以確保團隊所做的每件事情一致、準確。編輯器為**自動布局、夜間自動構建測試，這些都是很好地方式。自動化是每個專案團隊的必要組成部分。

g) 知道何時停止繪畫。團隊由個體組成，要給他們足夠的能夠閃亮的空間，以支援他們，同時要把握足夠好的軟體，抵抗不斷畫下去的**，確保專案的交付能夠符合需求。

2. 無情的測試

a) 早測試、常測試，自動測試。尋找bug有點像是用網捕魚。我們用纖小的網（單元測試）捕捉小魚，用粗大的網（整合測試）來捕捉大魚。有時魚會設法逃跑，所以為了抓住在我們專案池塘裡游動的、越來越狡猾的缺陷，要補上我們發現的任何漏洞。

與手動執行的測試計畫相比，隨每次構建執行的測試要有效的多。

bug發現得越早，進行修補的成本就越低。要「編一點，測一點」，在編寫產品**的同時編寫測試**。

只有通過全部測試，編碼才算完成。好的專案擁有的測試**可能比產品**還要多。但編寫這些測試**所花的時間是值得的。長遠來看，它最後會便宜得多，而你有希望製作出接近零缺陷的產品。此外，通過了所有測試將給你高度的自信：一段**已經「完成」了。

專案範圍測試的三個方面：測試什麼、怎樣測試、何時測試

b) 測試什麼

單元測試，這是所有其它形式測試的基礎。所有模組都必須通過單元測試，才能繼續前進。

整合測試，用來驗證專案的主要子系統能否工作，並很好地協同。是單元測試的一種擴充套件，測試整個子系統是否遵守其合約。

驗證和校驗。就算沒有bug，但回答的問題本身是錯誤的，這樣的系統也不會有用。需要校驗回答乙個重要的問題是：這是使用者需要的嗎？要注意使用者的訪問模式與開發者所用測試資料的不同。

資源耗盡、錯誤及恢復。雖然在理想的條件下軟體會正常執行，但在現實執行環境下，還有記憶體、磁碟空間、cpu頻寬、網路頻寬、螢幕解析度等種種限制。

效能測試、壓力測試或負載測試有時也很有必要，要測試軟體能夠滿足現實條件下的效能需求，如預期的使用者數、連線數、每秒事務數、可伸縮性。有時需要用專門模擬現實環境進行測試。

可用性測試。可用性測試是由真正的使用者、在真實的環境條件下進行的。軟體最好能像是手的延伸一樣順手。可用性測試也要盡早進行，以保證有時間更正，否則沒能滿足可用性標準就像是除零錯誤，是重大bug。

c) 怎樣測試

回歸測試，把當前測試的輸出與先前或已知的值進行對比，以確定今天對bug的修復沒有破壞昨天可以工作的**。效能、合約、有效效能等都可以進行回歸測試。

測試資料。資料分為兩種，現實世界的資料和合成的資料。

現實世界的資料代表典型的使用者資料，有助於揭示出需求分析中的缺陷和誤解。

合成資料在需要大量資料、需要測試邊界條件、展示特定統計屬性時很有用。

演練gui系統。對於涉及到gui的部分，你的設計應該足夠地解耦，以使你無需使用gui就能對應用邏輯進行測試。從這一點來看，winform那種介面與**的組合方式是不好的。

徹底測試。衡量測試的覆蓋率不能單單只從**行的覆蓋情況，尤其是對於迴圈、迭代之類的**。重要的是程式可能具有的狀態數。而且即使具有良好的**覆蓋，測試資料、遍歷**的次序對結果也有重大影響。

d) 何時進行測試。任何產品**一旦存在，就需要進行測試。大多數測試應該自動完成，並盡可能地頻繁測試，

e) 乙個bug只抓一次。bug一旦被發現，就應該是最後一次被發現，應該對自動化測試進行修改，從此每次都檢查那個特定的bug，不存在例外，不要覺得它不會再次發生。

《程式設計師修煉之道》筆記 八