點贊再看，養(yǎng)成習(xí)慣，微信搜索【三太子敖丙】關(guān)注這個互聯(lián)網(wǎng)茍且偷生的程序員。

本文 GitHub https://github.com/JavaFamily 已收錄，有一線大廠面試完整考點和系列文章。

前言

我的讀者好像學(xué)生居多，然后大家最近問的比較多的一個話題就是大廠的研發(fā)流程，都比較好奇，整個流程是怎么操作的。

我也不多BB了，那下面就跟隨暖男的腳步，走進大廠研發(fā)流程吧。

正文

我們先看看一個產(chǎn)品有哪些研發(fā)流程，帥丙就用自己接觸的阿里系的研發(fā)流程舉例了，這也基本上是互聯(lián)網(wǎng)大廠的研發(fā)流程了，可能細節(jié)有出入，但是絕對大同小異。

我問了下字節(jié)，多多，騰訊的朋友出入不大，所以還是具有代表性。

看完流程我們就一個個點的去看看每個環(huán)節(jié)干了些啥，我們開發(fā)同學(xué)在這個環(huán)節(jié)需要做啥，以及在每個環(huán)節(jié)的職能。

需求提出：

這個環(huán)節(jié)主要是產(chǎn)品爸爸給我們提需求，每個需求都是他們從用戶，或者自己絞盡腦汁想出來的，但是產(chǎn)品爸爸還拿不準，不能直接敲定，所以就需要我們大家（產(chǎn)品，UI，前端，后端，客戶端和測試）一起討論一下，看看這個需求是否合理，或者這個需求是否有意義，能否達到預(yù)期，技術(shù)實現(xiàn)的成本，周期等等。

一旦聊成了，他們就會進入下一個階段，聊不成他會想方設(shè)法讓你答應(yīng)，然后進入下個階段，知道我為啥叫產(chǎn)品爸爸了吧？

需求PRD提出：

這個階段，產(chǎn)品爸爸會根據(jù)第一版聊下來的結(jié)果，大致出一個Demo版本的PRD，會畫出初版的原型圖，并且配上文字說明，所有涉及到的業(yè)務(wù)，還有交互細節(jié)都會羅列出來。

大致就是下圖這樣：

這個時候大家又會圍繞這一版本去開會討論，敲定細節(jié)，這個環(huán)節(jié)會久點，因為細節(jié)比較認真，邏輯也不能出錯，還有UI稿子也得敲定，這里如果不敲定邏輯，UI提前去畫原型圖，后面假如邏輯推翻，一切重來就會浪費大量時間。

這一環(huán)節(jié)大家都會把細節(jié)問清楚，不了解的點也會去了解，測試，開發(fā)，UI我們都會在會議上提出自己的觀點，自己的意見，然后等產(chǎn)品反饋，最后意見一致之后，產(chǎn)品當天就回改出敲定版本。

UI就會按照產(chǎn)品爸爸的意思去作圖，接下來就是交互設(shè)計評審了。

交互設(shè)計評審：

UI會畫出客戶端，前端，H5開發(fā)所需要的UI圖，基本上就是我們看到的產(chǎn)品的樣子了，不過還是要敲定細節(jié)，比如按鈕合理不，或者上面數(shù)據(jù)是否在這展示，或者這里展示的數(shù)據(jù)是否合理。

這個環(huán)節(jié)會比較快，只要UI按照之前敲定的邏輯開發(fā)，出入不會很大，一般都是小改。

但是也不乏很多，之前敲定了情況，等UI按照敲定版本出了圖，但是卻發(fā)現(xiàn)出圖之后有些不合理的點，比如是否應(yīng)該在這里展示GMV（銷售總額），或者是否這樣展示活動規(guī)則啥的，會有這種情況，不過是小概率事件，改動也不會特別大。

UI界面：

大家看到的這種操作界面，按鈕，圖標的各種位置和圖案，都是UI在這個階段設(shè)計好的。（我什么都沒暗示，不用關(guān)注我的B站）

大家敲定后就進入我們開發(fā)人員的回合了。

概要設(shè)計：

概要設(shè)計，這個是大廠程序員需求下來之后基本上都會做的一步，不過看需求大小，可能很多小需求直接就詳細設(shè)計了，也有啥設(shè)計都不用做的小改動，具體需求具體分析嘛。

很多不了解的同學(xué)可能會問，需要設(shè)計什么呢？為什么要設(shè)計呢？

問得好，經(jīng)常看我文章的都知道，技術(shù)是把雙刃劍，你用了技術(shù)之后你是不是需要列出他的優(yōu)點缺點，出問題之后的解決方案，還有可能出現(xiàn)的問題，注意點等等。

這么是為了讓你能有把控力，比如你這個需求接入了新技術(shù)Es（Elasticsearch）你什么都不管你就是要接入它，你把他開發(fā)好了上線了，但是有啥坑你知道么？上線崩了怎么辦？

不主動，不拒絕，不負責(zé)，這是渣男的行徑，我們需要負起責(zé)任。

這個環(huán)節(jié)你需要考慮這個需求涉及到哪些服務(wù)了，需要新增哪些接口，修改哪些接口，表有現(xiàn)場的還是要新建表，字段要新建么？

其實遠遠不止這些問題，這就是我們做設(shè)計的主要原因，也是大家工作里面能成長的途徑之一，你以為大佬們的經(jīng)驗是怎么來的？

推薦工具：Xmind/ProcessOn

• Xmind官網(wǎng)地址： https://www.xmind.cn
• ProcessOn在線作圖地址：https://www.processon.com

ProcessOn是我使用最頻繁的工具了，我身邊也有很多小伙伴在用，也推薦大家都使用：

大家在學(xué)習(xí)，看書等等的時候做個腦圖，后面學(xué)習(xí)和復(fù)習(xí)的時候思路會很清晰，而且效率瞬間高很多，形成知識體系。

概要設(shè)計一般就是做個大概，給大家看一下我自己在設(shè)計ES相關(guān)的需求的時候的概設(shè)，比較粗糙看個大概就好了：

這個設(shè)計好了，就需要給Leader看，看理解程度，一兩次返工是有可能的，如果你像或者像敖丙一樣笨的話，是有可能會被打回N次的，這里我得提一下，好好做設(shè)計好處大大的有，自己體會。

然后會進行一輪測試用例評審，比如你涉及哪些服務(wù)，新增了哪些接口，改了哪些接口，都是要同步出來的，至于為啥？

是因為測試會依據(jù)這個數(shù)據(jù)，評估影響范圍，方便他寫測試用例，后面會提到。

詳細設(shè)計

小伙伴又要問了啥是詳細設(shè)計呀帥丙？

傻瓜，簡單呀，見名知意嘛，概要設(shè)計是大概的設(shè)計，詳細設(shè)計是詳細的設(shè)計。

我們研發(fā)的時候整個流程往往很復(fù)雜，如果你理解不對直接就寫代碼，最后容易造成返工，延期，加班，被罵，心情差，回家吵架，離家出走，露宿街頭，饑寒交迫，被迫吃野味，然后全國。。。。

看到不做詳細設(shè)計的后果了吧，其實大家花點時間做詳細設(shè)計很有必要，你思路完全清晰了，寫代碼那就是分分鐘的事情，不是嘛？

那再看看帥丙的一個小設(shè)計吧，之前文章中大量的流程圖，時序圖都來自它，主要是這玩意還是在線的，都不用下載很方便啊。

詳細設(shè)計的工具我用的就是之前提到的在線作圖神器：ProcessOn https://www.processon.com

還是我自己之前設(shè)計的一些流程圖，大家可以看看：

這個環(huán)節(jié)一樣重要，這個地方如果你能想好很多細節(jié)，開發(fā)的時候效率會高很多，像我上面的一些點，基本上就是看著圖開發(fā)了。

這個環(huán)節(jié)一般上不需要Leader參與，但是如果你有疑問或者不了解的點還是要提出來的。

測試用例評審：

上面我們說過，測試會根據(jù)你的概要設(shè)計，評估你的影響范圍，你的影響點，新增和改動的接口啥的，去編寫自己的測試用例。

測試用例，主要是為了把改動點影響點都考慮到，測全一點，免得上線了影響別的現(xiàn)有業(yè)務(wù)，也是為了把你開發(fā)的功能可能出現(xiàn)的bug給排除了。

我拿個小破站的小用例大家看看，這個比較粗糙但是也有點那味了。

這個環(huán)節(jié)也會開會討論，也是細節(jié)的確定，比如他寫的是否合理，或者有什么點沒考慮到，大家有沒有補充的。

接口定義&開發(fā)&前后端聯(lián)調(diào)

這個環(huán)節(jié)其實比較好理解，啥都敲定了，那就開發(fā)唄，開發(fā)差不多了，就得前后端聯(lián)調(diào)了。

這里有個小細節(jié)還是想說一下，一般開發(fā)前我們都會提前定義數(shù)據(jù)類型，接口名稱，然后在公司的接口工具上給出鏈接和參數(shù)，方便前端爸爸mock數(shù)據(jù)。

他總不能等我們后端開發(fā)完了，才去開發(fā)嘛，這樣效率打折扣，所以都是后端先定義好，然后前后端并行開發(fā)的。

后端開發(fā)好，一般都是會發(fā)布到聯(lián)調(diào)環(huán)境，我們有哪些環(huán)境，聯(lián)調(diào)環(huán)境在我們所有的環(huán)境中處于哪個地位呢？

大家可以看到我列出了我們開發(fā)的所有環(huán)境。

Tip：日常環(huán)境不能由開發(fā)人員發(fā)布，是因為測試流程比較久，所以不能中斷，如果你一直發(fā)布會影響測試的效率，在發(fā)布期間他們是沒辦法干活的，而且很多部門涉及相同的服務(wù)，你發(fā)布還會影響別人。

測試發(fā)布之前，在測試群里問問可以發(fā)某個服務(wù)么，大家覺得不影響，那么就可以發(fā)了，懂了吧。

預(yù)發(fā)環(huán)境，也叫灰度環(huán)境，這是跟線上數(shù)據(jù)一樣的一個環(huán)境，只是只能內(nèi)網(wǎng)訪問，一般這一步是防止很多是因為日常的數(shù)據(jù)量不夠真實，數(shù)據(jù)級別達不到線上的量級無法測出的bug。

扯遠了，聯(lián)調(diào)完了就是代碼Review了。

代碼Review：

codeReview環(huán)節(jié)，畫一下重點，這可能是整個研發(fā)流程中，讓你成長最快的一個環(huán)節(jié)，讓組員和Leader Review你的代碼，往往他們能給你很多業(yè)務(wù)上和技術(shù)上的建議和意見。

過來人的經(jīng)驗?zāi)憔驼f香不香吧，以前老大經(jīng)常沒時間，但是我就是煩著他要Review，后來他說不用review了，但是我還是要組員大佬review，因為我很享受別人對我提建議的時候，這不就是成長，掃盲的好時機嘛。

提測&灰度發(fā)布&產(chǎn)品第一次驗收

這一階段就是把代碼都發(fā)到日常環(huán)境，然后等測試爸爸測試，這個環(huán)節(jié)開發(fā)同學(xué)如果沒BUG是比較輕松的，等著就好了，可以看看丙丙的文章啊，看看丙丙的B站視頻什么的。

但是如果你BUG多，那我覺得你可能會生不如死，因為有的bug真的找很久很久的，調(diào)用鏈路又長，特別是跨服務(wù)又涉及消息隊列，或者第三方的接口什么的。

img

總之你也不知道會出現(xiàn)什么bug，我看身邊的大神也只能用經(jīng)驗避免常見的吭，孰能生巧吧。

發(fā)布計劃

敲黑板，這個確實是比較重要的環(huán)節(jié)，這個環(huán)節(jié)主要是開發(fā)同學(xué)和前端同學(xué)說好一個發(fā)布時間，然后制定一個發(fā)布計劃，為啥要發(fā)布計劃呢?

我們開發(fā)一個需求，可能涉及到N個服務(wù)，這些服務(wù)是有依賴關(guān)系的，那就需要打包，比如訂單系統(tǒng)，依賴人員系統(tǒng)。優(yōu)惠券系統(tǒng)，也依賴人員系統(tǒng)，然后訂單系統(tǒng)還依賴優(yōu)惠券系統(tǒng)，是不是有點亂了？

我們看圖：

打包和發(fā)布順序原則上是一樣的，從沒完全依賴的服務(wù)按照順序發(fā)布到最后一個服務(wù)。

生成環(huán)境上線：

這就是神圣而莊嚴的上線環(huán)節(jié)，一般在這個環(huán)節(jié)丙丙都是要洗手洗澡，然后才點下那個神圣的發(fā)布按鈕。

一般現(xiàn)在都是自動化發(fā)布，界面上點點就好了，記得丙丙大學(xué)發(fā)布都是進服務(wù)器一個個kill進程，替換jar包然后重啟。

現(xiàn)在都是分布式的集群，這樣發(fā)無疑會累死，我之前負責(zé)的系統(tǒng)有50多臺機器，一般都是4臺4臺發(fā)布。

日志觀察&產(chǎn)品第二次驗收

一般發(fā)布第一批之后不會馬上發(fā)布第二批，而是觀察錯誤日志，看看是否正常，有時候會發(fā)現(xiàn)還是會出現(xiàn)異常情況的，那就保留錯誤日志，然后回滾。

知道解決了再發(fā)布，順利的話就沒啥錯誤，一口氣發(fā)完了，看了下時間凌晨了，那發(fā)完差不多也得回家了。

一次發(fā)布可能涉及服務(wù)多的話，真的有可能發(fā)布這么久，但是沒辦法，線上出問題就是掉腦袋的事情。

日志觀察一般公司都有錯誤日志搜集系統(tǒng)，或者自己登錄跳板機查看就好了。

沒問題，發(fā)完之后告訴產(chǎn)品大大就好了。

需求結(jié)束

至此基本上一個需求可能就結(jié)束了，其實還是很不容易的，短的需求幾天，長的需求幾個月，中間涂涂改改，BUG，技術(shù)難點都是你要面對的，不過沒啥大問題，我們技術(shù)人嘛皮實能頂。

總結(jié)

產(chǎn)品研發(fā)流程大家是不是覺得有點復(fù)雜，或者覺得很多點有點小題大做了，不瞞你說，剛開始我也這么認為的，但是隨著時間的推移，你會發(fā)現(xiàn)有時候越是這樣規(guī)范，越是提升了效率，也提升了產(chǎn)品質(zhì)量。

對自己設(shè)計的嚴苛也會讓你的業(yè)務(wù)能力提升，開發(fā)考慮的點也越來越廣泛，我想大佬應(yīng)該都是這樣走過去的，那沒啥好說的，我們也走。

最后給大家看看我自己搞的一個項目管理模板吧，基本上能適用大部分項目了，要xmind格式的公眾號回復(fù)【項目】即可。

我是敖丙，一個在互聯(lián)網(wǎng)茍且偷生的程序員。

創(chuàng)作不易，不想被白嫖，各位的「三連」就是丙丙創(chuàng)作的最大動力，我們下篇文章見！

---

文章持續(xù)更新，可以微信搜索「 三太子敖丙 」第一時間閱讀，回復(fù)【資料】【面試】【簡歷】有我準備的一線大廠面試資料和簡歷模板，本文 GitHub https://github.com/JavaFamily 已經(jīng)收錄，有大廠面試完整考點，歡迎Star。

你知道的越多，你不知道的越多

總結(jié)

以上是生活随笔為你收集整理的阿里面试官问我，你们的需求研发/开发流程是怎样的？我？？？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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