我一直從事云信業(yè)務(wù)中臺(tái)的后端開發(fā)工作。云信的業(yè)務(wù)發(fā)展迅速，產(chǎn)品的需求層出不窮，團(tuán)隊(duì)成員不斷壯大。如何快速滿足產(chǎn)品需求，同時(shí)保證線上系統(tǒng)的穩(wěn)定迭代，以及小團(tuán)隊(duì)如何協(xié)同？接下來我會(huì)從開發(fā)規(guī)范、開發(fā)流程、項(xiàng)目管理、如何敏捷等方面講述一些我的心路歷程，以供參考。

開發(fā)規(guī)范

云信業(yè)務(wù)中臺(tái)團(tuán)隊(duì)由最開始的2人，發(fā)展到最多時(shí)6人。前期階段只關(guān)注需求如何快速迭代上線，沒有過多關(guān)注代碼規(guī)范。隨著代碼數(shù)量增加，逐漸發(fā)現(xiàn)迭代和維護(hù)的難度越來越大，每位程序員都有自己的編碼習(xí)慣，十幾萬行的系統(tǒng)代碼，看起來就像一堆“屎山”。此時(shí)，必須引入代碼規(guī)范，讓寫代碼和讀代碼的程序員都能夠心情愉悅。

代碼規(guī)范，直接借鑒的《阿里巴巴java開發(fā)手冊(cè)》，手冊(cè)里詳細(xì)制定了編碼、異常日志、單元測(cè)試、安全規(guī)約、MYSQL數(shù)據(jù)庫、工程結(jié)構(gòu)等的相關(guān)規(guī)范，大家可以網(wǎng)上下載閱讀。

有了規(guī)范，大家如何有效地執(zhí)行？

統(tǒng)一IDE代碼模板

約定了IDEA/Eclipse IDE代碼的統(tǒng)一模板，新建類、方法，格式化全部統(tǒng)一。避免不同的開發(fā)同學(xué)使用不同的模板帶來的差異化，以及增加merge的成本。可以使用eclipse-java-google-style模板。在提交代碼時(shí)使用Alibaba Java Coding Guidelines插件，對(duì)不符合規(guī)范的代碼進(jìn)行提醒，修改后再提交。

分支管理

最開始，團(tuán)隊(duì)使用的SVN來管理源碼，隨著git的流行，后來全部切換到git。針對(duì)分支開發(fā)，制定了以下規(guī)范：

分支的定義（master、develop、release、hotfix、feature），不同分支會(huì)有不同的權(quán)限。

checkout、merge request流程，merge時(shí)還可以做一次code review；

提測(cè)、上線流程，不同階段使用不同的分支測(cè)試和發(fā)布，上線完成后打tag，方便回滾；

統(tǒng)一工具與框架

對(duì)于業(yè)務(wù)中使用到的公共工具類和方法，統(tǒng)一抽象和封裝到二方庫，比如JedisUtil、httpClient、日期格式的轉(zhuǎn)換、文件讀寫導(dǎo)出等。所有系統(tǒng)統(tǒng)一框架和版本，比如spring、spring boot，mybatis、dubbo、MQ等，讓開發(fā)同學(xué)能將主要精力放在業(yè)務(wù)模塊的開發(fā)上。

注釋和文檔

讓程序員既要寫得一手好代碼，又要寫得一手好文檔，并且保證代碼和文檔的同步，面對(duì)時(shí)間緊、需求多的情況下，實(shí)現(xiàn)起來不現(xiàn)實(shí)。那如何做到文檔與代碼同步？作為程序員，簡(jiǎn)單直接的方法的就是寫好注釋。在類、方法、屬性前加上適當(dāng)?shù)淖⑨?#xff0c;對(duì)于難以解釋的代碼加上必要的注釋。Controller層的api可以使用spring-swagger來保持同步，減少因修改代碼而維護(hù)文檔的成本。

如何做到敏捷？

敏捷這個(gè)詞早在90年代初就提出了，據(jù)統(tǒng)計(jì)，2018年90%的軟件開發(fā)都采用了敏捷開發(fā)。下面這段話很好的解釋了什么是敏捷？

敏捷開發(fā)（agile development）是非常流行的軟件開發(fā)方法，敏捷開發(fā)的核心是迭代開發(fā)，

迭代開發(fā)其實(shí)就是"重復(fù)開發(fā)"。它將開發(fā)過程拆分成多個(gè)小周期，即一次"大開發(fā)"變成多次"小開發(fā)"，每次小開發(fā)都是同樣的流程。

其實(shí)這里所謂的同樣的流程，就是傳統(tǒng)的瀑布開發(fā)模式，包括幾個(gè)重要的環(huán)節(jié)。我在實(shí)際的開發(fā)過程中，主要有以下幾個(gè)重要的里程碑節(jié)點(diǎn)：

需求評(píng)審

我們的需求主要來源于產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理通過給開發(fā)、測(cè)試講解本次版本的需求背景、詳細(xì)說明、完成后的效果，讓相關(guān)同學(xué)理解需求。同時(shí)，開發(fā)評(píng)估需求的合理性、可行性，可以對(duì)需求有所調(diào)整。這個(gè)環(huán)節(jié)必不可少。當(dāng)然，需求也可以來自開發(fā)，測(cè)試，也需要與相關(guān)人員溝通。

設(shè)計(jì)評(píng)審

這里的設(shè)計(jì)評(píng)審，不是視覺和交互評(píng)審，是技術(shù)實(shí)現(xiàn)的設(shè)計(jì)評(píng)審。

如果本次迭代的需求在技術(shù)方案上需要評(píng)估，則需要對(duì)詳細(xì)設(shè)計(jì)做一個(gè)評(píng)估，避免開發(fā)過程或上線后造成缺陷和遺漏。如果只是常規(guī)迭代，則可以省略這一步。

編碼

實(shí)現(xiàn)本次迭代的需求

測(cè)試用例評(píng)審

測(cè)試用例和編碼應(yīng)該是同步的，對(duì)測(cè)試寫的用例進(jìn)行評(píng)估，可能會(huì)發(fā)現(xiàn)測(cè)試遺漏點(diǎn)，并將其補(bǔ)充完整。

發(fā)布計(jì)劃評(píng)審

如果本次迭代涉及的變更復(fù)雜或需要跨部門合作，有前后依賴的關(guān)系，需要寫一個(gè)發(fā)布計(jì)劃，寫清楚上線的時(shí)間、步驟、注意事項(xiàng)，以免造成上線混亂。同時(shí)，要有發(fā)布失敗的回滾方案。

上線

按照發(fā)布計(jì)劃，進(jìn)行系統(tǒng)的發(fā)布上線。

復(fù)盤

如果本次迭代有發(fā)生重大失誤，造成發(fā)布失敗或發(fā)布后引起嚴(yán)重的線上問題，則需要產(chǎn)品、測(cè)試、開發(fā)等相關(guān)同學(xué)一起復(fù)盤本次迭代，總結(jié)經(jīng)驗(yàn)，避免下次再發(fā)生同樣的事情。

按照這個(gè)瀑布模式進(jìn)行迭代，覺得步驟是不是有點(diǎn)多？太浪費(fèi)時(shí)間?和所謂的敏捷相違背？但實(shí)際是，多少實(shí)踐經(jīng)驗(yàn)告訴我，這些流程避免不了。比如沒有需求評(píng)審，開發(fā)完成了，發(fā)現(xiàn)效果不是產(chǎn)品想要的。沒有測(cè)試評(píng)審，開發(fā)有修改的地方，測(cè)試沒有測(cè)試到，導(dǎo)致測(cè)試遺漏。

除了這些重要的里程碑，其實(shí)還有一些關(guān)鍵節(jié)點(diǎn)，比如視覺、交互評(píng)審，產(chǎn)品走查，冒煙測(cè)試，預(yù)發(fā)布驗(yàn)證等。

根據(jù)敏捷開發(fā)的價(jià)格觀和十二條原則，我們團(tuán)隊(duì)做了如下調(diào)整：

少開會(huì)

讓產(chǎn)品、測(cè)試、開發(fā)盡量坐在一起，如果有任何問題，直接使用面對(duì)面交流的方式，解決問題。避免使用郵件、即時(shí)通訊軟件帶來的信息滯后。如果要開會(huì)，可以使用站會(huì)的形式，簡(jiǎn)潔溝通。如果必須開會(huì)，則盡量控制開會(huì)時(shí)間，說重點(diǎn)和問題，高效解決。

控制迭代節(jié)奏

每次迭代主要解決優(yōu)先級(jí)最高或比較緊急的需求，控制一次迭代的周期在2~3周，從而達(dá)到不斷可持續(xù)的交付。

定期復(fù)盤

針對(duì)一段時(shí)間內(nèi)，系統(tǒng)出現(xiàn)的問題，流程的問題等進(jìn)行復(fù)盤和總結(jié)。技術(shù)實(shí)現(xiàn)上，如果用合理的方案快速實(shí)現(xiàn)。流程上，如何優(yōu)化，才能更高效。

如何用好敏捷，打造高效團(tuán)隊(duì)，以上均是本人工作實(shí)踐總結(jié)，純屬個(gè)人見解，如有疑問，歡迎拍磚。

總結(jié)

以上是生活随笔為你收集整理的【网易中台实践】云信业务中台的敏捷开发的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。