【網易中臺實踐】雲信業務中臺的敏捷開發

我一直從事雲信業務中臺的後端開發工做。雲信的業務發展迅速，產品的需求層出不窮，團隊成員不斷壯大。如何快速知足產品需求，同時保證線上系統的穩定迭代，以及小團隊如何協同？接下來我會從開發規範、開發流程、項目管理、如何敏捷等方面講述一些個人心路歷程，以供參考。

開發規範

雲信業務中臺團隊由最開始的2人，發展到最多時6人。前期階段只關注需求如何快速迭代上線，沒有過多關注代碼規範。隨着代碼數量增長，逐漸發現迭代和維護的難度愈來愈大，每位程序員都有本身的編碼習慣，十幾萬行的系統代碼，看起來就像一堆「屎山」。此時，必須引入代碼規範，讓寫代碼和讀代碼的程序員都可以心情愉悅。

代碼規範，直接借鑑的《阿里巴巴java開發手冊》，手冊裏詳細制定了編碼、異常日誌、單元測試、安全規約、MYSQL數據庫、工程結構等的相關規範，你們能夠網上下載閱讀。

有了規範，你們如何有效地執行？

統一IDE代碼模板

約定了IDEA/Eclipse IDE代碼的統一模板，新建類、方法，格式化所有統一。避免不一樣的開發同窗使用不一樣的模板帶來的差別化，以及增長merge的成本。可使用eclipse-java-google-style模板。在提交代碼時使用Alibaba Java Coding Guidelines插件，對不符合規範的代碼進行提醒，修改後再提交。

分支管理

最開始，團隊使用的SVN來管理源碼，隨着git的流行，後來所有切換到git。針對分支開發，制定瞭如下規範：

• 分支的定義（master、develop、release、hotfix、feature），不一樣分支會有不一樣的權限；
• checkout、merge request流程，merge時還能夠作一次code review；
• 提測、上線流程，不一樣階段使用不一樣的分支測試和發佈，上線完成後打tag，方便回滾。

統一工具與框架

對於業務中使用到的公共工具類和方法，統一抽象和封裝到二方庫，好比JedisUtil、httpClient、日期格式的轉換、文件讀寫導出等。全部系通通一框架和版本，好比spring、spring boot，mybatis、dubbo、MQ等，讓開發同窗能將主要精力放在業務模塊的開發上。

註釋和文檔

讓程序員既要寫得一手好代碼，又要寫得一手好文檔，而且保證代碼和文檔的同步，面對時間緊、需求多的狀況下，實現起來不現實。那如何作到文檔與代碼同步？做爲程序員，簡單直接的方法的就是寫好註釋。在類、方法、屬性前加上適當的註釋，對於難以解釋的代碼加上必要的註釋。Controller層的api可使用spring-swagger來保持同步，減小因修改代碼而維護文檔的成本。

如何作到敏捷？

敏捷這個詞早在90年代初就提出了，據統計，2018年90%的軟件開發都採用了敏捷開發。下面這段話很好的解釋了什麼是敏捷？

敏捷開發（agile development）是很是流行的軟件開發方法，敏捷開發的核心是迭代開發，

迭代開發其實就是"重複開發"。它將開發過程拆分紅多個小週期，即一次"大開發"變成屢次"小開發"，每次小開發都是一樣的流程。

其實這裏所謂的一樣的流程，就是傳統的瀑布開發模式，包括幾個重要的環節。我在實際的開發過程當中，主要有如下幾個重要的里程碑節點：

需求評審

咱們的需求主要來源於產品經理，產品經理經過給開發、測試講解本次版本的需求背景、詳細說明、完成後的效果，讓相關同窗理解需求。同時，開發評估需求的合理性、可行性，能夠對需求有所調整。這個環節必不可少。固然，需求也能夠來自開發，測試，也須要與相關人員溝通。

設計評審

這裏的設計評審，不是視覺和交互評審，是技術實現的設計評審。

若是本次迭代的需求在技術方案上須要評估，則須要對詳細設計作一個評估，避免開發過程或上線後形成缺陷和遺漏。若是隻是常規迭代，則能夠省略這一步。

編碼

實現本次迭代的需求

測試用例評審

測試用例和編碼應該是同步的，對測試寫的用例進行評估，可能會發現測試遺漏點，並將其補充完整。

發佈計劃評審

若是本次迭代涉及的變動複雜或須要跨部門合做，有先後依賴的關係，須要寫一個發佈計劃，寫清楚上線的時間、步驟、注意事項，以避免形成上線混亂。同時，要有發佈失敗的回滾方案。

上線

按照發布計劃，進行系統的發佈上線。

覆盤

若是本次迭代有發生重大失誤，形成發佈失敗或發佈後引發嚴重的線上問題，則須要產品、測試、開發等相關同窗一塊兒覆盤本次迭代，總結經驗，避免下次再發生一樣的事情。

按照這個瀑布模式進行迭代，以爲步驟是否是有點多？太浪費時間?和所謂的敏捷相違背？但實際是，多少實踐經驗告訴我，這些流程避免不了。好比沒有需求評審，開發完成了，發現效果不是產品想要的。沒有測試評審，開發有修改的地方，測試沒有測試到，致使測試遺漏。

除了這些重要的里程碑，其實還有一些關鍵節點，好比視覺、交互評審，產品走查，冒煙測試，預發佈驗證等。

敏捷實踐

根據敏捷開發的價格觀和十二條原則，咱們團隊作了以下調整：

少開會

讓產品、測試、開發儘可能坐在一塊兒，若是有任何問題，直接使用面對面交流的方式，解決問題。避免使用郵件、即時通信軟件帶來的信息滯後。若是要開會，可使用站會的形式，簡潔溝通。若是必須開會，則儘可能控制開會時間，說重點和問題，高效解決。

控制迭代節奏

每次迭代主要解決優先級最高或比較緊急的需求，控制一次迭代的週期在2~3周，從而達到不斷可持續的交付。

按期覆盤

針對一段時間內，系統出現的問題，流程的問題等進行復盤和總結。技術實現上，若是用合理的方案快速實現。流程上，如何優化，才能更高效。

如何用好敏捷，打造高效團隊，以上均是本人工做實踐總結，純屬我的看法，若有疑問，歡迎拍磚。