《程序員修鍊之道：專業程序員必知的33個技巧》節選之敲打代碼

事後敲打是常見的工作方式，行業占統治地位的瀑布開發方法就是這樣：規格說明、設計、構建、測試。測試是最後的步驟。產品來到測試部門，很快就崩潰了。於是，又回到工程部門，修復Bug。接著，把另一版提交給測試部門，又由於其他原因崩潰。就這樣，來來回回，許多月（甚至是數年）流逝。

在程序員們深入具體實踐之前，我們會從技巧1——敲打代碼開始，幫你建立正確的思維方式。

你可能認為編寫可靠代碼是再明顯不過的工作要求了。招工廣告上不可能寫：「急聘：具備良好工作態度、團隊合作精神和桌上足球技巧的程序員。有則更佳：會編寫可靠的代碼。」可有問題的程序還是有這麼多，怎麼回事？

在深入探討保證代碼質量的日常實踐之前，讓我們先討論「編寫可靠代碼」的含義。它不僅僅是一份實踐清單，它還是一種思維方式。在把產品交到客戶手中之前，你必須敲打自己的代碼和整個產品。

客戶終究敲打你的產品，以一種你不曾預料到的方式使用它。他們用它的時間會很長，而且會在你沒有測試過的環境里用它。你必須考慮的問題是：打算讓客戶發現多少Bug？

你現在對代碼敲打的次數越多，在交到客戶手中之前，能清除掉的Bug就越多，留給客戶的Bug就越少。

質量保證的形式

1.代碼評審

保證代碼質量最簡單的方法就是讓另一個程序員去讀它。別出心裁的評審過程並沒有必要，而且就連結對編程也算是一種形式的實時代碼評審。團隊將利用代碼評審捕獲Bug，貫徹編程風格和標準，同時在團隊成員間傳播知識。我們將在「技巧8：代碼評審要早且多」中討論代碼評審。

2.單元測試

在你一個類接著一個類、一個方法接著一個方法地構建應用的業務邏輯時，驗證代碼的最佳方式就是單元測試。這種內部零件級的測試被設計用來對邏輯的各部分單獨驗證。

3.接受測試

單元測試立足於由內而外地審視產品，接受測試則被設計成模擬真實世界的用戶，代表他們與系統交互。理想狀況下，它們是自動執行的，而且以某種敘述式的風格書寫出來。例如，某銀行自動櫃員機應用會有類似這樣的接受故事：若我的活期存款為0，當我在ATM的「活期存款」中選擇「取款」時，那麼我應該看到「對不起，今天的晚餐吃泡麵吧。」

它不像莎翁著作那樣文采飛揚，但這些測試操練了整個系統：從用戶界面一直到業務邏輯。無論它們是自動執行的，還是人工執行的，你的公司需要知道—在任何客戶使用它之前—所有系統組件正在像預期的那樣協調工作。

4.負載測試

負載測試將產品置於真實的壓力條件下，然後度量它的響應。例如，某網站可能需要在資料庫有100萬條記錄的條件下在100毫秒內展示指定頁面。這些測試將揭示正確但不恰當的行為，如需要線性伸縮但卻以指數級別伸縮的代碼。

5.定向探索測試

接受測試覆蓋了產品的所有指定行為，它可能來自於產品需求文檔或會議。但程序員通常還是有辦法使之崩潰—總有些黑暗角落被規格說明疏忽掉。定向探索測試就是要將這些邊界情況挖出來。

這種測試通常是人工執行的，可能是程序員自己，用於探索和發現問題。但最初探索之後，任何有用的測試就會被加到接受測試套件之中。

該測試有一個專業化的變種，如安全審計。在這些情況下，專業測試人員會利用他們的領域知識（可能也包括代碼評審）來指導他們的測試。

6.機構測試

硬體產品需要不同的機構認證：FCC度量電磁輻射，確保產品不會導致無線電干擾；美國保險商實驗室（UL）檢查當你將產品置於火上或舔電池電極時會發生什麼。這些測試都在新產品發布之前進行，每次硬體變化都會影響認證。

7.環境測試

硬體產品的運行溫度和濕度也需要在推至極限時測試。這些測試是用環境室來完成的，它可以同時控制這兩個因素；當產品在其間運行時，它會經歷所有四種極限條件。

8.兼容性測試

一旦產品需要跟其他產品進行互操作（如某字處理程序需要跟其他字處理程序交換文檔），這些兼容性的論斷就需要定期驗證。它們可能會訪問一組已保存的文檔，也可能會實時地將你的產品連接到其他產品上。

9.耐久性測試

你會注意到這裡提到的大多數測試都是盡量頻繁且快速地運行。可有些Bug只會在一段時間的使用之後現身。前面提到的49.7天的Bug很好說明了這一點—它源於每毫秒遞增的32位計數器，在49.7天之後，它會從最大值反轉成0。測試若不持續運行上一會兒，你就無法發現類似Bug。

分享之前我還是要推薦下我自己的前端學習群：180442230，不管你是小白還是大牛，小編我都挺歡迎，不定期分享乾貨，包括我自己整理的一份2017最新的前端資料和零基礎入門教程，送給大家，歡迎初學和進階中的小夥伴

10.Beta測試

產品在這一階段被送到了真實客戶手中—他們知道自己要參加測試，並同意發現問題時提交報告。Beta測試的目的就在於我們在本技巧一開始討論的：Beta測試者將以你意想不到的方式使用產品，試用它一段時間，並在你沒有測試過的環境中測試產品。

11.運行中測試

公司可能會在產品上市之後繼續測試。尤其是硬體產品，如偶爾從製造線上拔掉一個單元並證明製造線能工作正常是一種很有用的方法。這些運行中測試的設計目的就是為了捕獲因零件或裝配過程中的變化而導致的問題。

實踐 VS 思維方式

你的團隊可能採用類似「所有代碼都必須有單元測試」或「所有代碼必須先評審后檢入（check in）」的實踐。但這些實踐沒有一個能保證代碼堅若磐石。想想若公司根本就沒有採用一個質量實踐，這種狀況下該怎麼做，即你將如何敲打代碼以保證它的可靠性？

這是在繼續深入之前你需要建立的思維方式。提交可靠的代碼。質量實踐只是達到目的的一種手段—最終的裁判是客戶手中產品的可靠性。你想讓你的名字跟市面上滿是Bug的垃圾產品掛鉤嗎？不，當然不想。

行動指南

在上述所有形式的測試中，你的公司採用了哪些？在源代碼中尋找單元測試，向測試部門詢問接受測試計劃，問問Beta測試是如何進行的以及向哪個部門提交反饋。再問下資深工程師：這是否足以保證客戶有一個平滑的體驗？

在定向探索測試上多花些時間，哪怕你的「方向」有點兒模糊。實際用一下產品，看看你是否可以讓它崩潰。如果可以，那就相應地記下Bug報告。