怎麼樣能讓程序員少寫BUG

有沒有覺得，有時候程序員哥哥的腦回路不同凡響，能自己想出一套邏輯，甚至寫一些讓你哭笑不得的BUG。

那有沒有思考過，怎麼樣讓他們少些BUG呢？

其實，我為此是操碎了心，在公司之前各方面都不不成熟，且沒有測試人員的時候，我是兼任測試的。

我在測試的時候，主要有以下三個問題。

1. 我們以為達成共識的公共組件，開發哥哥們很容易因為文檔需求沒有明確説明而進行自己新的一套東西；還美其名曰：我比你們產品想的多，我讓我們系統更加完美。但其實是他們美好的yy，很多東西的實現效果讓你覺得很反人類。
2. 需求理解不一致，未真正達成共識，各自在各自的頻道，天馬行空；你以為你跟他説清楚了，他以為自己理解了，實際上就是雞同鴨講，誰也沒理解誰，最後導致開發出來的東西，用户根本不能用。
3. 粗心大意，考慮不全面，寫出了真正的BUG；這類BUG要麼很明顯，要麼就會藏得很深。

這三個問題，在我經歷了許多項目開發後發現，其實是能夠通過完善的文檔和充足的軟件設計去避免的。

第一個問題，其實不止是組件，還有很多文檔中並不明確的東西，這些都是能夠通過我們詳細需求文檔描述或者詳細的原型設計去避免；如果是通用的東西，我們可以形成一套通用的規範説明，或者讓開發形成一套公共功能庫，通用或者公共的東西，不需要每次都單獨寫，只要按規範去做就好。

第二個問題，我們可以讓書面的描述，落成更直觀的邏輯圖、流程圖或是直接舉例的數據計算過程，讓程序員哥哥們可以多角度深刻的去理解；這樣做，不僅可以讓繁瑣複雜的文字表述文檔變成更通俗易懂的圖形和數據，還可以檢查需求和邏輯的完整性。

也就是説這兩個問題，其實我們都可以通過詳細的軟件設計和規範的開發流程，儘量去避免。

那麼第三個問題呢？

第三個問題，則要從測試上入手。

在《人月神話》一書中，曾提到過“易除BUG 的設計”。

這所謂的“易除BUG 的設計”其實是通過三塊內容：測試規格説明、自下而上的設計和結構化編程。

一、測試規格説明

在編寫代碼之前提交測試規格説明，也就是我們常説的測試用例；以詳細的檢查和説明的完整性和明確性的文檔，並組織項目組全體成員進行測試用例評審，以達到項目需求的真正共識。

這個過程中，也是對需求文檔和原型的檢查，其中不免會對原需求文檔和原型進行進一步的需求細化和存疑點的修改。

這一點非常考驗測試用例編寫人員對業務理解的能力和逆向思維能力，測試想要覆蓋全面，則需要深刻理解業務需求，且能對異常操作場景進行細化設計；數據類的測試，還需要數據用例去驗證邏輯。

因此，測試人員編寫測試用例只是第一步，想要測試用例覆蓋全面，做到大家真正達成共識，則需要大家羣策羣力，一起去完善；這一過程，可能是系統開發正確最關鍵的一步。

二、自下而上的設計

將系統開發分為體系結構設計、設計實現和物理編碼實現，即精化步驟、細化任務。

這一點，其實就是在開發上入手，讓系統開發分步設計，這樣做，則有以下優點：

• 清晰的結構和表達方式，更容易對需求和模塊功能進行精確的描述；
• 模塊分割和模塊獨立性，則避免系統級的BUG；
• 細節的抑制使結構上的缺陷更加容易識別；
• 設計在每個精化步驟上都是可以測試的，所以測試可以儘早開始，並且每個步驟的重點樂於放在合適的級別上。

三、結構化編程

將系統分為單元調試和集成調試。將相同的組件們作為某個單元，可以減少重複工作，也能控制變更；這樣不僅能夠方便測試，也可以階段化的迭代。

四、總結

軟件的開發是所有參與人員共同朝着一個目標前進，每一個人都在為項目辛勤付出，都希望項目做到有結果，所以每個人都要為項目的質量、結果進行負責。

過程中大家要各司其職，也要互相幫助，儘量避免走歪路和出錯。

我們都要對整個軟件開發過程負責，因此，我們產品經理不僅僅只是把需求做得完美，還要協助開發測試，更好的完成項目開發目標，達成真正可用的系統。

本文由 @阿虛 原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 unsplash，基於 CC0 協議