不知道讀者有沒有下面的這些體驗。

案例一: 產品需求預評審、正式評審時，一些看似簡單的需求，我們習慣簡單思考後就答覆，實現是沒問題的，保證能按時按質完成任務，然而在開發過程或者測試過程還會拉上產品溝通困惑點，甚至驗收時無法達到一致。

案件二： 和服務使用方聯調時，別人覺得你的參數不合理，或者對他來說過於麻煩，最後不得不再去修改程式碼、發布、自測。

案例三： 測試同事和你對功能影響存在資訊偏差，測試通過但是上線後其他功能受到牽連。

案例四： 你新接手一個項目， 但是時間很快被新需求給佔用了，對舊功能實現和演進過程了解甚微，最後自己一邊製造雷區一邊掉進前人的坑。

上面提及的四個案例，都是我們日常工作中容易遇到的問題，這些問題會造成不必要的時間消耗。那我們在日常開發中需要注意哪些點，才能避免類似問題，成為一個高效能的研發呢？今天我將分享一些知識和經驗，希望能幫助到你。

第一點，接到需求任務時，需要注意什麼呢？

你可能首先想到的是技術方案調研或者確定技術方案，不過直覺多數是錯的。當接到需求任務時，我們應該先定好驗收標準，包括正常的和異常的流程，避免對”需求完成”的定義產生分歧。如果對描述有異議，儘早和各方充分溝通，達成一致，然後讓產品更新PRD，並且將資訊及時同步給所有需求任務參與者。也就是說，不管產品修改的只是關於前端的還是只關於後端的，都應該全量同步，而不是只通知一方，避免修改了邏輯之後只有一方知道。

第二點，編寫一個對外服務前，需要注意什麼呢？

編寫對外服務時是先寫文檔還是先開發再寫文檔呢？我之前提了一個需求給別人，要求觸發某個邏輯時，發送一個消息MQ給我，消息體需要包括業務資訊。聯調時，我無法對消息體進行正常的反序列化，因為包括了程式語言中的關鍵字，但是他們編寫使用的是其他程式語言，對他們來說，那根本不算關鍵字。說到這，前面的問題答案已經很明顯了。開發對外服務時，我們要先定義好介面(服務)文檔，並且要求使用方對介面(服務)文檔進行確認，達成一致再進行開發，避免聯調時造成欄位缺失或者欄位名不合適問題。

剛說到的介面文檔也是有規範可言的，通常包括功能說明、使用場景說明、協議規範、請求規範、響應規範、服務欄位描述、響應欄位描述、示例，通常還會包括文檔的編寫維護人、產品人員資訊、測試人員資訊，方便其他人回饋或者提需，甚至還會包括脫敏後的業務背景、業務規則說明、調用方資訊。消息MQ規範其實和介面規範相似，不過需要注意提醒使用方做好兼容性測試，同時確保後續新增欄位不受影響。

第三點，功能迭代或者缺陷修復時，需要注意什麼呢？

大部分情況下，你為什麼要修改這個功能、修改的邏輯是什麼、需要注意什麼地方，只有你清楚而已。換一個人來修改其周邊邏輯，他得花時間確定修改影響範圍，同時你碰到的坑，他可能還會陷進去一次。前者有可能是注釋沒寫好，後者有可能是沒有將過程數據化。

針對前者，我們寫好注釋就行。但是，總有人在注釋中長篇大論，描述這個功能是怎麼實現的，而不是描述做什麼的。最後，功能確確實實在迭代，文字注釋卻原地不動，注釋成了撒謊機，成了誤導性的文字。業內有個經典名言，最好的注釋是沒有注釋，用程式碼表達意圖。要達到這點，必須保證每一次修改，程式碼都比之前更乾淨。換言之，好讀、好懂、好改的高品質程式碼才能促進生產力。

針對後者，我們可以使用程式碼倉庫GIT中的ISSUE管理功能迭代和缺陷管理，然後及時更新狀態，同時描述解決過程的思路、嘗試過的解決方案等等。這種方式能促進團隊透明，方便事後回顧總結。還能讓我們通過數據來衡量效率，跟蹤進度，也能方便其他人了解功能實現和演進過程。

第四點，需求提測時，需要注意什麼呢？

測試同事和你對需求的理解肯定是有偏差的，這也是為什麼人們慢慢開始接受測試驅動開發理念，不過距離落地還有一定距離。我比較推薦的做法是，開發前編寫好涉及到的場景步驟、直觀結果、影響範圍，並且將其同步給測試人員，作為提測模板，當功能完成後補充資訊提測即可。這樣做的好處，一來是能提前校驗大家對需求的理解是否是一致的，二來是避免修改非本次需求而是其他人想順便修改的邏輯，我們內部稱之為接私活，這是絕對禁止的。

總結一下今天的重點，想清楚、對齊清楚再做，做的過程多記錄，往往不會有壞處，畢竟磨刀不誤砍柴功。好，今天的分享就到這裡，如果有幫助到你，歡迎分享給你的朋友們或者點擊在看。

文章來源：www.liangsonghua.me

作者介紹：京東資深工程師-梁松華，在穩定性保障、敏捷開發、JAVA高級、微服務架構方面有深入的理解