松花皮蛋的黑板報
  • 分享在京東工作的技術感悟,還有JAVA技術和業內最佳實踐,大部分都是務實的、能看懂的、可復現的

掃一掃
關注公眾號

高效能研發的四個習慣

博客首頁文章列表 松花皮蛋me 2019-10-20 14:55

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

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

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

案例三: 測試同事和你對功能影響存在信息偏差,測試通過但是上線后其他功能受到牽連。

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

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

第一點,接到需求任務時,需要注意什么呢?

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

第二點,編寫一個對外服務前,需要注意什么呢?

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

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

第三點,功能迭代或者缺陷修復時,需要注意什么呢?

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

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

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

第四點,需求提測時,需要注意什么呢?

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

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

黑龙江6+1开奖结果查询