大廠需求研發流程，進去前了解一波？-有解無憂

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

本文 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格式的公眾號回復【專案】即可，

大廠需求研發流程，進去前了解一波？

前言

正文