大廠研發需求流程，沒想到這麼複雜吧？

https://mp.weixin.qq.com/s/SB3aHvalAmZ3_RVwjhpekg

大廠研發需求流程，沒想到這麼複雜吧？

收錄於話題

#程序員 1567

 

#阿里巴巴 554

 

#大廠面經 14

引言

個人讀者好像學生居多，而後你們最近問的比較多的一個話題就是大廠的研發流程，都比較好奇，整個流程是怎麼操做的。

我也很少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，技術難點都是你要面對的，不過沒啥大問題，咱們技術人嘛皮實能頂。

總結

產品研發流程你們是否是以爲有點複雜，或者以爲不少點有點小題大作了，不瞞你說，剛開始我也這麼認爲的，可是隨着時間的推移，你會發現有時候越是這樣規範，越是提高了效率，也提高了產品質量。

對本身設計的嚴苛也會讓你的業務能力提高，開發考慮的點也愈來愈普遍，我想大佬應該都是這樣走過去的，那沒啥好說的，咱們也走。

最後給你們看看我本身搞的一個項目管理模板吧，基本上能適用大部分項目了。

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

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

我不想被白嫖，求點這裏