大廠需求研發流程,進去前了解一波?

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

本文 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格式的公眾號回復【項目】即可。

相關資料

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

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

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

注:如果本篇博客有任何錯誤和建議,歡迎人才們留言!

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

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

網頁設計最專業,超強功能平台可客製化

您可能也會喜歡…