高效能研發的四個習慣

文章首發於公衆號 松花皮蛋的黑板報

做者就任於京東,在穩定性保障、敏捷開發、高級JAVA、微服務架構有深刻的理解

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

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

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

案例三： 測試同事和你對功能影響存在信息誤差，測試經過可是上線後其餘功能受到牽連。

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

上面說起的四個案例，都是咱們平常工做中容易遇到的問題，這些問題會形成沒必要要的時間消耗。那咱們在平常開發中須要注意哪些點，才能避免相似問題，成爲一個高效能的研發呢？今天我將分享一些知識和經驗，但願能幫助到你。

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

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

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

編寫對外服務時是先寫文檔仍是先開發再寫文檔呢？我以前提了一個需求給別人，要求觸發某個邏輯時，發送一個消息MQ給我，消息體須要包括業務信息。聯調時，我沒法對消息體進行正常的反序列化，由於包括了編程語言中的關鍵字，可是他們編寫使用的是其餘編程語言，對他們來講，那根本不算關鍵字。說到這，前面的問題答案已經很明顯了。開發對外服務時，咱們要先定義好接口(服務)文檔，而且要求使用方對接口(服務)文檔進行確認，達成一致再進行開發，避免聯調時形成字段缺失或者字段名不合適問題。

剛說到的接口文檔也是有規範可言的，一般包括功能說明、使用場景說明、協議規範、請求規範、響應規範、服務字段描述、響應字段描述、示例，一般還會包括文檔的編寫維護人、產品人員信息、測試人員信息，方便其餘人反饋或者提需，甚至還會包括脫敏後的業務背景、業務規則說明、調用方信息。消息MQ規範其實和接口規範類似，不過須要注意提醒使用方作好兼容性測試，同時確保後續新增字段不受影響。

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

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

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

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

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

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

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

文章來源：www.liangsonghua.me

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