點贊再看，養成習慣，微信搜索【三太子敖丙】關注這個互聯網茍且偷生的程序員。

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

前言

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

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

正文

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

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

看完流程我們就一個個點的去看看每個環節干了些啥，我們開發同學在這個環節需要做啥，以及在每個環節的職能。

需求提出：

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

一旦聊成了，他們就會進入下一個階段，聊不成他會想方設法讓你答應，然后進入下個階段，知道我為啥叫產品爸爸了吧？

需求PRD提出：

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

大致就是下圖這樣：

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

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

UI就會按照產品爸爸的意思去作圖，接下來就是交互設計評審了。

交互設計評審：

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

這個環節會比較快，只要UI按照之前敲定的邏輯開發，出入不會很大，一般都是小改。

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

UI界面：

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

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

概要設計：

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

很多不了解的同學可能會問，需要設計什么呢？為什么要設計呢？

問得好，經常看我文章的都知道，技術是把雙刃劍，你用了技術之后你是不是需要列出他的優點缺點，出問題之后的解決方案，還有可能出現的問題，注意點等等。

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

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

這個環節你需要考慮這個需求涉及到哪些服務了，需要新增哪些接口，修改哪些接口，表有現場的還是要新建表，字段要新建么？

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

推薦工具：Xmind/ProcessOn

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

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

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

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

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

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

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

詳細設計

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

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

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

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

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

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

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

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

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

測試用例評審：

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

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

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

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

接口定義&開發&前后端聯調

這個環節其實比較好理解，啥都敲定了，那就開發唄，開發差不多了，就得前后端聯調了。

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

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

后端開發好，一般都是會發布到聯調環境，我們有哪些環境，聯調環境在我們所有的環境中處于哪個地位呢？

大家可以看到我列出了我們開發的所有環境。

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

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

預發環境，也叫灰度環境，這是跟線上數據一樣的一個環境，只是只能內網訪問，一般這一步是防止很多是因為日常的數據量不夠真實，數據級別達不到線上的量級無法測出的bug。

扯遠了，聯調完了就是代碼Review了。

代碼Review：

codeReview環節，畫一下重點，這可能是整個研發流程中，讓你成長最快的一個環節，讓組員和Leader Review你的代碼，往往他們能給你很多業務上和技術上的建議和意見。

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

提測&灰度發布&產品第一次驗收

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

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

img

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

發布計劃

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

我們開發一個需求，可能涉及到N個服務，這些服務是有依賴關系的，那就需要打包，比如訂單系統，依賴人員系統。優惠券系統，也依賴人員系統，然后訂單系統還依賴優惠券系統，是不是有點亂了？

我們看圖：

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

生成環境上線：

這就是神圣而莊嚴的上線環節，一般在這個環節丙丙都是要洗手洗澡，然后才點下那個神圣的發布按鈕。

一般現在都是自動化發布，界面上點點就好了，記得丙丙大學發布都是進服務器一個個kill進程，替換jar包然后重啟。

現在都是分布式的集群，這樣發無疑會累死，我之前負責的系統有50多臺機器，一般都是4臺4臺發布。

日志觀察&產品第二次驗收

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

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

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

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

沒問題，發完之后告訴產品大大就好了。

需求結束

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

總結

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

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

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

我是敖丙，一個在互聯網茍且偷生的程序員。

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

---

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。