在一線大廠，從需求提出到上線，整個(gè)流程是怎樣的？筆者結(jié)合騰訊的工作流和調(diào)研了阿里、字節(jié)等公司的項(xiàng)目開(kāi)發(fā)流程，發(fā)現(xiàn)大廠的工作流大同小異，總結(jié)了如下的整體流程圖。

下面將按照這個(gè)流程的每個(gè)節(jié)點(diǎn)，詳細(xì)闡述。全文3000多字，閱讀大概需要6分鐘～

目錄

1、需求階段

2、開(kāi)發(fā)階段

3、測(cè)試階段

4、發(fā)布階段

5、監(jiān)控階段

6、總結(jié)

1、需求階段

1.1 原型評(píng)審

需求提出后，產(chǎn)品一般會(huì)帶著原型圖，拉開(kāi)發(fā)、數(shù)據(jù)、設(shè)計(jì)一起開(kāi)需求評(píng)審會(huì)。

在這個(gè)會(huì)議中，大家如果對(duì)需求有什么建議/意見(jiàn)都可以提出，如果需求實(shí)現(xiàn)不了、改動(dòng)很大沒(méi)法向前兼容、開(kāi)發(fā)周期長(zhǎng)等問(wèn)題都可以在這個(gè)會(huì)議中拋出來(lái)，產(chǎn)品會(huì)做出相應(yīng)的調(diào)整。

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

大家對(duì)原型圖都沒(méi)有什么異議之后，就進(jìn)入下一流程了。當(dāng)設(shè)計(jì)出了設(shè)計(jì)稿之后，就拉著產(chǎn)品、前端一起評(píng)審交互設(shè)計(jì)稿。

這個(gè)評(píng)審會(huì)主要是看以下幾個(gè)方面：

(1) 交互設(shè)計(jì)稿跟產(chǎn)品邏輯有沒(méi)有一個(gè)比較大的出入；

(2) 組件風(fēng)格跟整體風(fēng)格是否統(tǒng)一；

(3) 在有產(chǎn)品上線有規(guī)定時(shí)間的條件下，UI還原復(fù)雜度如果占用開(kāi)發(fā)時(shí)間比較長(zhǎng)的話，會(huì)考慮讓設(shè)計(jì)協(xié)調(diào)一個(gè)降級(jí)的方案。（比如復(fù)用以前的功能類似組件）

2、開(kāi)發(fā)階段

2.1 概要設(shè)計(jì)&排期

交互設(shè)計(jì)評(píng)審?fù)曛?，開(kāi)發(fā)就可以開(kāi)始排期了。（前端同學(xué)要到這個(gè)階段才開(kāi)始排期，但是后臺(tái)、數(shù)據(jù)的同學(xué)一般原型評(píng)審?fù)旰缶涂梢耘牌诹耍?/p>

開(kāi)發(fā)是如何排期的呢？一般來(lái)說(shuō)，一個(gè)需求開(kāi)發(fā)出來(lái)到底需要多少時(shí)間，這個(gè)是不能百分之百準(zhǔn)確評(píng)估的，因?yàn)橛泻芏嗲闆r你沒(méi)發(fā)預(yù)料，

比如線上出現(xiàn)bug，這個(gè)bug你可能要花一天的時(shí)間才能找到并修復(fù)，

再比如在你開(kāi)發(fā)過(guò)程中，遇到一個(gè)難題，要花時(shí)間做調(diào)研等等。

所以開(kāi)發(fā)排期一般都會(huì)留給自己一些buff（緩沖時(shí)間）。

要評(píng)估一個(gè)需求開(kāi)發(fā)完需要花費(fèi)多少時(shí)間，一般我們會(huì)先做一個(gè)概要設(shè)計(jì)，啥是概要設(shè)計(jì)？

概要設(shè)計(jì)就是實(shí)現(xiàn)這個(gè)需求的一個(gè)大概方案。一般會(huì)考慮以下幾點(diǎn)：

(1) 考慮依賴

需求要實(shí)現(xiàn)依賴了哪些服務(wù)，包括第三方和我們自己的服務(wù)。

如果需要依賴第三方服務(wù)，需要調(diào)用第三方接口的話，可能還要去閱讀第三方服務(wù)的接口文檔和調(diào)用方式，也是需要一定的工作量的。

(2) 考慮復(fù)用

需求依賴的接口是否能復(fù)用，前端的組件是否能復(fù)用。如果組件可以復(fù)用的話，開(kāi)發(fā)工作量是可以減少的。

(3) 考慮兼容性

需求實(shí)現(xiàn)之后，對(duì)已經(jīng)存在的數(shù)據(jù)是否有沖突？對(duì)現(xiàn)有的功能是否有沖突？

比如說(shuō)一個(gè)平臺(tái)，以前用戶的昵稱是可以重復(fù)的，但最近產(chǎn)品提了一個(gè)需求是用戶昵稱不能重復(fù)，那么開(kāi)發(fā)就需要對(duì)以前的用戶昵稱數(shù)據(jù)做一個(gè)修復(fù)，這也是一個(gè)工作量。

(4) 考慮技術(shù)盲點(diǎn)

如果遇到了不了解的技術(shù)盲點(diǎn)，可以申請(qǐng)一個(gè)調(diào)研的時(shí)間。因?yàn)榧夹g(shù)選型也是需要調(diào)研和做競(jìng)品分析的 ，要找到最適合自己業(yè)務(wù)的技術(shù)選型。

概要設(shè)計(jì)一般會(huì)使用xmind等工具來(lái)把每一個(gè)功能涉及到的服務(wù)及影響寫出來(lái)。

同時(shí)，概要設(shè)計(jì)也會(huì)給到測(cè)試同學(xué)，測(cè)試同學(xué)會(huì)根據(jù)你的概要設(shè)計(jì)，評(píng)估影響范圍，新增、改動(dòng)的接口有哪些，可以更全面的去寫測(cè)試用例。

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

這個(gè)環(huán)節(jié)測(cè)試同學(xué)會(huì)把測(cè)試用例拿出來(lái)評(píng)審，這時(shí)開(kāi)發(fā)可以評(píng)估是否合理，或者有哪些點(diǎn)沒(méi)有考慮到，都可以提出來(lái)。

2.3 接口定義與開(kāi)發(fā)

如果這次需求涉及到新增、更改接口，是需要后端先定義一個(gè)接口協(xié)議的。比如一個(gè)查詢訂單的接口，需要提供哪些字段查詢，返回的數(shù)據(jù)結(jié)構(gòu)是怎樣的。

后端提前定義好協(xié)議之后前端開(kāi)發(fā)起來(lái)就順暢很多了，因?yàn)閿?shù)據(jù)結(jié)構(gòu)已經(jīng)都清楚了。

接下來(lái)開(kāi)發(fā)們就開(kāi)始寫代碼了。

2.4 開(kāi)發(fā)自測(cè)

開(kāi)發(fā)自測(cè)一般會(huì)在開(kāi)發(fā)過(guò)程中完成。一般會(huì)做單元測(cè)試，性能測(cè)試等，根據(jù)具體需求而定。

對(duì)于前端，因?yàn)楹笈_(tái)可能接口還沒(méi)開(kāi)發(fā)完成，但是這時(shí)又需要后臺(tái)接口來(lái)測(cè)試，那怎么辦呢？

我們一般會(huì)使用mock服務(wù)，mock就是模擬接口返回的服務(wù)。這樣就可以大大提高了開(kāi)發(fā)效率。

2.5 聯(lián)調(diào)

當(dāng)前后端都開(kāi)發(fā)完，就開(kāi)始聯(lián)調(diào)啦。聯(lián)調(diào)就是前端正式調(diào)用后臺(tái)發(fā)布到測(cè)試環(huán)境的接口。這個(gè)階段可能會(huì)出現(xiàn)后臺(tái)漏字段、字段名變更、接口返回異常等問(wèn)題。

在排期時(shí)聯(lián)調(diào)也是需要把時(shí)間算進(jìn)去的。

3、測(cè)試階段

3.1 靜態(tài)掃描

前后端聯(lián)調(diào)完之后，就可以把代碼發(fā)布到測(cè)試環(huán)境啦。測(cè)試環(huán)境是公司內(nèi)網(wǎng)才可以訪問(wèn)的環(huán)境。在發(fā)布到測(cè)試環(huán)境之前，會(huì)自動(dòng)觸發(fā)一個(gè)工具的靜態(tài)掃描。

靜態(tài)掃描是啥呢？其實(shí)就是一個(gè)檢測(cè)你的代碼的工具。

一般會(huì)檢查代碼是否符合規(guī)范、代碼是否有安全漏洞、依賴的第三方庫(kù)是否安全等等，如果掃描過(guò)程中出現(xiàn)問(wèn)題，會(huì)直接通知你，讓你改進(jìn)。

3.2 提測(cè)

代碼發(fā)布到測(cè)試環(huán)境后，測(cè)試同學(xué)就開(kāi)始測(cè)試?yán)?。遇到什么bug的話，就會(huì)在需求管理平臺(tái)給開(kāi)發(fā)提bug單，開(kāi)發(fā)收到之后就去解決。

這個(gè)階段的周期看開(kāi)發(fā)的質(zhì)量和需求的大小。

3.3 產(chǎn)品第一次體驗(yàn)

bug都修復(fù)完之后，產(chǎn)品就開(kāi)始在測(cè)試環(huán)境進(jìn)行產(chǎn)品的第一次體驗(yàn)啦。

體驗(yàn)階段，產(chǎn)品找出了bug，或者實(shí)現(xiàn)與需求有出入的地方都可以提給開(kāi)發(fā)。

對(duì)于有設(shè)計(jì)稿的需求，設(shè)計(jì)這時(shí)也會(huì)參與進(jìn)來(lái)走查還原度的問(wèn)題。

產(chǎn)品&設(shè)計(jì)驗(yàn)收ok后，需求就可以發(fā)布到預(yù)發(fā)布環(huán)境體驗(yàn)真實(shí)的場(chǎng)景啦。

3.4 預(yù)發(fā)布環(huán)境體驗(yàn)

什么是預(yù)發(fā)布環(huán)境？預(yù)發(fā)布環(huán)境是為了模擬線上真實(shí)環(huán)境的體驗(yàn)環(huán)境，它跟線上環(huán)境唯一的區(qū)別是網(wǎng)址不同，其他的都一致。

為什么要有這么個(gè)環(huán)節(jié)呢？原因主要有2個(gè)：

一是線上數(shù)據(jù)與測(cè)試環(huán)境數(shù)據(jù)不同，想用線上數(shù)據(jù)做一些測(cè)試。二是為保證萬(wàn)無(wú)一失，看看新功能增加后，在線上環(huán)境會(huì)不會(huì)暴露出一些隱藏問(wèn)題。

這個(gè)階段不是必須的。還是具體情況具體分析。

4、發(fā)布階段

4.1 制定發(fā)布計(jì)劃

一般上線前，后臺(tái)會(huì)找到相關(guān)的開(kāi)發(fā)同學(xué)，制定一個(gè)發(fā)布計(jì)劃。

因?yàn)楫?dāng)一個(gè)產(chǎn)品強(qiáng)大起來(lái)之后，它依賴的服務(wù)是非常多的，會(huì)涉及到一個(gè)發(fā)布順序和對(duì)線上服務(wù)不可用的問(wèn)題。

如果發(fā)布的是一個(gè)產(chǎn)品大版本，對(duì)線上完全不兼容，在服務(wù)發(fā)布時(shí)，如果線上有用戶在使用，可能會(huì)導(dǎo)致操作失敗或者引入臟數(shù)據(jù)。這都是我們不想要的結(jié)果。

對(duì)于這種情況，一般會(huì)采用2種方案，一種是暫時(shí)關(guān)閉線上服務(wù)，提示服務(wù)升級(jí)中。還有一種是關(guān)閉數(shù)據(jù)庫(kù)的寫操作，提示用戶稍后重試。

4.2 灰度/全量發(fā)布

如果產(chǎn)品沒(méi)有要求的話，默認(rèn)使用全量發(fā)布，即對(duì)所有用戶開(kāi)放。

什么情況下會(huì)使用灰度發(fā)布？

(1) 降低發(fā)布帶來(lái)的影響

雖然功能都在測(cè)試環(huán)境測(cè)過(guò)，但畢竟沒(méi)有發(fā)布到生產(chǎn)環(huán)境，如果先讓少部分用戶先使用新版本，提前發(fā)現(xiàn)bug，或者性能問(wèn)題，提前做好修復(fù)，就可以降低新版本帶來(lái)的影響。

(2) 通過(guò)對(duì)新老版本的對(duì)比，觀察新版本帶來(lái)的效果。

具體的灰度發(fā)布細(xì)節(jié)可以看我以前寫的這篇文章：大廠常用的幾種灰度發(fā)布方案

4.3 產(chǎn)品第二次驗(yàn)收

當(dāng)服務(wù)都發(fā)完后，產(chǎn)品需要到線上體驗(yàn)下新功能，看看有沒(méi)有什么問(wèn)題，保證萬(wàn)無(wú)一失。產(chǎn)品第二次驗(yàn)收完成后這個(gè)需求就算是完成了。

5、監(jiān)控階段

5.1 埋點(diǎn)統(tǒng)計(jì)

產(chǎn)品為了查看功能的使用情況，比如頁(yè)面停留時(shí)長(zhǎng)、點(diǎn)擊量、訪問(wèn)量等，前端一般都會(huì)做埋點(diǎn)統(tǒng)計(jì)。

5.2 錯(cuò)誤日志監(jiān)控&性能監(jiān)控

為了保證線上的穩(wěn)定性，前端、后臺(tái)都會(huì)接入錯(cuò)誤日志上報(bào)，比如接口返回出錯(cuò)1分鐘內(nèi)次數(shù)達(dá)到10次，那就會(huì)給開(kāi)發(fā)通知告警。

性能監(jiān)控主要是為了保證服務(wù)的可用性。比如服務(wù)內(nèi)存、cpu占用過(guò)大，或者某個(gè)接口在1秒內(nèi)調(diào)用頻率超過(guò)了限制，都會(huì)有告警。

6、總結(jié)

到這里就講完了，可能有的小伙伴會(huì)覺(jué)得這個(gè)過(guò)程很長(zhǎng)很復(fù)雜，有點(diǎn)小題大做了，有些節(jié)點(diǎn)沒(méi)必要。

當(dāng)然如果對(duì)于一些小需求，小改動(dòng)有些環(huán)節(jié)是可以省去的。但是對(duì)于常規(guī)的需求，都這樣規(guī)范起來(lái)的話，可以保證開(kāi)發(fā)效率和產(chǎn)品質(zhì)量。

我們可以看到一個(gè)需求從開(kāi)發(fā)到上線涉及到了需求管理、代碼管理、版本管理、發(fā)布管理、人員通知等關(guān)鍵節(jié)點(diǎn)，

在上古時(shí)期，這些節(jié)點(diǎn)之間是割裂的，沒(méi)有一個(gè)工具或者平臺(tái)可以把他們串起來(lái)，比如需求和代碼的關(guān)聯(lián)，代碼和發(fā)布版本的關(guān)聯(lián)。

而且，這些節(jié)點(diǎn)很多都可以用自動(dòng)化工具來(lái)管理起來(lái)，比如當(dāng)開(kāi)發(fā)提交代碼到測(cè)試分支后自動(dòng)發(fā)布，自動(dòng)通知產(chǎn)品驗(yàn)收。

在自動(dòng)化方面，一般大公司都有相應(yīng)的工具/平臺(tái)來(lái)管理，后面的文章將會(huì)講到自動(dòng)化管理項(xiàng)目方面的內(nèi)容。

---- end ----

---- 推薦閱讀 ----