點贊再看，養成習慣，微信搜尋【三太子敖丙】關注這個網際網路苟且偷生的程式設計師。

本文 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真的找很久很久的，呼叫鏈路又長，特別是跨服務又涉及訊息佇列，或者第三方的介面什麼的。

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

釋出計劃

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

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

我們看圖：

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

生成環境上線：

這就是神聖而莊嚴的上線環節，一般在這個環節丙丙都是要洗手洗澡，然後才點下那個神聖的釋出按鈕。

一般現在都是自動化釋出，介面上點點就好了，記得丙丙大學釋出都是進伺服器一個個kill程序，替換jar包然後重啟。

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

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

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

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

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

日誌觀察一般公司都有錯誤日誌蒐集系統，或者自己登入跳板機檢視就好了。

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

需求結束

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

總結

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

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

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

相關資料

準備了很多學習資料給大家https://pan.baidu.com/s/1gM4Ea11ygHuMomT2VQ2aNQ

我是敖丙，一個在網際網路苟且偷生的程式設計師。

你知道的越多，你不知道的越多，人才們的 【三連】 就是丙丙創作的最大動力，我們下期見！

注：如果本篇部落格有任何錯誤和建議，歡迎人才們留言！

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