編輯導語：作為一名產品經理，除了要關注你的產品需求和使用者需求，還要參與到每一個步驟裡；比如開發測試，參與到其中，才能更好的做到結合，完成專案的開發。本文作者介紹了在程式設計師寫程式碼時如何避免出錯。
有沒有覺得，有時候程式設計師哥哥的腦回路不同凡響，能自己想出一套邏輯，甚至寫一些讓你哭笑不得的BUG。
那有沒有思考過，怎麼樣讓他們少些BUG呢？
其實，我為此是操碎了心，在公司之前各方面都不不成熟，且沒有測試人員的時候，我是兼任測試的。
我在測試的時候，主要有以下三個問題。
- 我們以為達成共識的公共元件，開發哥哥們很容易因為文件需求沒有明確說明而進行自己新的一套東西；還美其名曰：我比你們產品想的多，我讓我們系統更加完美。但其實是他們美好的yy，很多東西的實現效果讓你覺得很反人類。
- 需求理解不一致，未真正達成共識，各自在各自的頻道，天馬行空；你以為你跟他說清楚了，他以為自己理解了，實際上就是雞同鴨講，誰也沒理解誰，最後導致開發出來的東西，使用者根本不能用。
- 粗心大意，考慮不全面，寫出了真正的BUG；這類BUG要麼很明顯，要麼就會藏得很深。
這三個問題，在我經歷了許多專案開發後發現，其實是能夠透過完善的文件和充足的軟體設計去避免的。
第一個問題，其實不止是元件，還有很多文件中並不明確的東西，這些都是能夠透過我們詳細需求文件描述或者詳細的原型設計去避免；如果是通用的東西，我們可以形成一套通用的規範說明，或者讓開發形成一套公共功能庫，通用或者公共的東西，不需要每次都單獨寫，只要按規範去做就好。
第二個問題，我們可以讓書面的描述，落成更直觀的邏輯圖、流程圖或是直接舉例的資料計算過程，讓程式設計師哥哥們可以多角度深刻的去理解；這樣做，不僅可以讓繁瑣複雜的文字表述文件變成更通俗易懂的圖形和資料，還可以檢查需求和邏輯的完整性。
也就是說這兩個問題，其實我們都可以透過詳細的軟體設計和規範的開發流程，儘量去避免。
那麼第三個問題呢？
第三個問題，則要從測試上入手。
在《人月神話》一書中，曾提到過“易除BUG 的設計”。
這所謂的“易除BUG 的設計”其實是透過三塊內容：測試規格說明、自下而上的設計和結構化程式設計。
一、測試規格說明在編寫程式碼之前提交測試規格說明，也就是我們常說的測試用例；以詳細的檢查和說明的完整性和明確性的文件，並組織專案組全體成員進行測試用例評審，以達到專案需求的真正共識。
這個過程中，也是對需求文件和原型的檢查，其中不免會對原需求文件和原型進行進一步的需求細化和存疑點的修改。
這一點非常考驗測試用例編寫人員對業務理解的能力和逆向思維能力，測試想要覆蓋全面，則需要深刻理解業務需求，且能對異常操作場景進行細化設計；資料類的測試，還需要資料用例去驗證邏輯。
因此，測試人員編寫測試用例只是第一步，想要測試用例覆蓋全面，做到大家真正達成共識，則需要大家群策群力，一起去完善；這一過程，可能是系統開發正確最關鍵的一步。
二、自下而上的設計將系統開發分為體系結構設計、設計實現和物理編碼實現，即精化步驟、細化任務。
這一點，其實就是在開發上入手，讓系統開發分步設計，這樣做，則有以下優點：
- 清晰的結構和表達方式，更容易對需求和模組功能進行精確的描述；
- 模組分割和模組獨立性，則避免系統級的BUG；
- 細節的抑制使結構上的缺陷更加容易識別；
- 設計在每個精化步驟上都是可以測試的，所以測試可以儘早開始，並且每個步驟的重點樂於放在合適的級別上。
將系統分為單元除錯和整合除錯。將相同的元件們作為某個單元，可以減少重複工作，也能控制變更；這樣不僅能夠方便測試，也可以階段化的迭代。
四、總結軟體的開發是所有參與人員共同朝著一個目標前進，每一個人都在為專案辛勤付出，都希望專案做到有結果，所以每個人都要為專案的質量、結果進行負責。
過程中大家要各司其職，也要互相幫助，儘量避免走歪路和出錯。
我們都要對整個軟體開發過程負責，因此，我們產品經理不僅僅只是把需求做得完美，還要協助開發測試，更好的完成專案開發目標，達成真正可用的系統。
本文由 @阿虛 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自 unsplash，基於 CC0 協議