第八章 注重實效的項目

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

?

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，不存在例外，不要覺得它不會再次發生。

?

轉載于:https://www.cnblogs.com/zhixin9001/p/6822409.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的《程序员修炼之道》笔记(八)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。