很多錄友會很好奇這么個事：

• 大廠的研發(fā)流程應該是什么樣的呢

• 為什么會有那么多繁瑣的流程呢

• 每一步都有什么作用呢

這次卡哥給大家介紹一波大廠的研發(fā)流程，讓大家明明白白。

同時我已經(jīng)錄制了視頻，昨晚已經(jīng)在B站首發(fā)了。

點擊這里：解密互聯(lián)網(wǎng)大廠研發(fā)流程?

其實對于幾十人或者上百人一起開發(fā)一個項目的話，一個規(guī)范的研發(fā)流程是很重要的。

有的同學可能想，哪有這么多流程啊，就是寫完代碼，跑一下，沒問題，然后就上線了。

其實在大廠里研發(fā)流程是很重要的。

一個項目從開發(fā)到上線到后面的維護，從流程上就保證大家少出錯，也方便后面人繼續(xù)維護。

那么接下來給大家介紹一下詳細的流程。

1.需求文檔

看需求文檔，我們要根據(jù)需求文檔來確定我們究竟要做什么。

一些同學可能感覺 為什么還要用一個需求文檔呢，你就告訴我做啥我就做啥不就完事了。

其實需求文檔一方面是倒逼產(chǎn)品經(jīng)理去系統(tǒng)性的思考這個需求究竟有哪些功能，用來滿足哪些用戶的需求。

另一方面，是保證我們在研發(fā)的時候，研發(fā)出來的功能是滿足需求文檔里所描述的。

如果是口頭對接的話，很有可能就是你做出來的東西，產(chǎn)品經(jīng)理看完感覺：這和我說的需求不一樣?。?！這和我想的不一樣?。?！

這樣就是兩個人相互甩鍋，那這究竟是誰的鍋呢。都沒有一個證據(jù)，對吧。

所以說，有一個需求文檔很重要。

而且每個階段的需求文檔相當于是把這個項目的整個迭代過程都記錄下來了。

這樣也方便后面的人，了解這個項目是如何迭代的。

2.這個需求包含了哪些功能

產(chǎn)品經(jīng)理在需求文檔里描述一個功能，那么我們在實現(xiàn)的時候，可能要改很多模塊，或者說我們要增加一些模塊。

就是我們從代碼的角度上來講，可能要增添很多功能才能滿足 用戶看起來好像微不足道的小功能。

例如點擊登錄，點擊下單，后臺都有很多模塊協(xié)同運行的。

我們要把產(chǎn)品經(jīng)理角度上的這個功能，拆解為我們代碼角度上的具體應該開發(fā)的那些功能。

3.確定有哪些難點

這里可能有同學疑惑了，我確定這東西干嘛呢。

給大家舉一個例子，給你一個需求文檔。

你說你一周的時間就能把它開發(fā)完，那為什么是一周呢，為什么不是兩天，為什么不是兩周呢。

其實 和上面的領(lǐng)導匯報你的工作的時候 都要把自己的工作進行量化。

那么這個功能有哪些難點，我們要克服這個難點，所需要花費的時間，都要有一個大體的量化。

這樣才能量化我們自己的工作，領(lǐng)導其實不知道你的工作是簡單 還是困難, 領(lǐng)導只在意最終結(jié)果，所以你要展現(xiàn)給領(lǐng)導你的工作是有難度的是有挑戰(zhàn)的。

而且這些也是我們年底用來晉升或者評職稱的素材。

如果這些東西你自己都不在乎的話，誰還會幫你在乎呢。

而且確定了自己的工作難點，把這些難點都記錄下來，對以后跳槽也很有幫助。

面試官最喜歡問的問題，就是：你做的項目中有哪些難點？以及你是如何克服的。

所以這一步對自己個人成長來說也是很有重要的。對于項目組來說也是記錄下來，每一個迭代版本有哪些難點，這些難點團隊是如何克服的。

這也是項目組往上一級去邀功的資料。

4.畫架構(gòu)圖

一般來說，大廠項目的架構(gòu)都是比較復雜的，特別是后端架構(gòu)。

如果添加一個模塊連個文檔都沒有，連個圖也沒有，上來就添加的話，后面的人是很難維護的。

而且每個模塊和每一個模塊之間的依賴關(guān)系，如果沒有畫出一個架構(gòu)圖的話，直接看代碼很容易直接就看懵了。

為什么你可以快速開發(fā)一個新的模塊，也是因為之前團隊有人把這個架構(gòu)圖畫清楚了，你只需要看一眼這個架構(gòu)圖，就知道你的模塊應該添加在哪里。

那么你去添加模塊的時候，也應該把這個架構(gòu)圖相應的位置 完善一下。

同時呢，在畫架構(gòu)圖的過程中，也增添了自己對整個系統(tǒng)架構(gòu)的掌握程度。

這個圖也會讓你確定，你的模塊在整個項目中扮演一個什么樣的角色。

5.定協(xié)議

后臺模塊之間進行通訊需要協(xié)議，后臺和前端通訊也需要協(xié)議。

所以只要有交互，就要確定協(xié)議的數(shù)據(jù)格式。

定協(xié)議要考慮到兼容，要考慮易于維護。

6.設計數(shù)據(jù)結(jié)構(gòu)和算法

其實設計數(shù)據(jù)結(jié)構(gòu)更多一些，因為我們要選擇使用什么容器，什么格式來處理我們的數(shù)據(jù)。

至于算法的話，就很少我們親自設計了。

什么快排，二叉樹，動態(tài)規(guī)劃，最短路啥的，在實際開發(fā)中，都不需要我們自己去寫，直接調(diào)包！

面試造火箭，工作擰螺絲 就體現(xiàn)在這里。

為什么會這樣呢？一個很簡單的例子，互聯(lián)網(wǎng)研發(fā)講究其實就是要快，例如一個功能2天就要開發(fā)完，如果算法都要自己去寫的話，等都寫完了，花都謝了。

7.預估一下容量

特別是后端開發(fā)，要估計出 我們自己模塊大體需要多大磁盤，多大內(nèi)存，多大帶寬，多少核CPU。

這也是沒有做過研發(fā)工作的同學經(jīng)常忽略的，因為大家好像默認 磁盤、內(nèi)存、帶寬、cpu是無窮的。

其實我們在設計一個模塊的時候，這些都要評估的，不能模塊一上線，把機器直接打爆了，例如 直接把帶寬打滿了，不僅影響自己的模塊功能，還影響了機器上其他模塊的運行。

8.考慮部署

要考慮如果一臺機器掛了（可能是硬件原因），那么我們的模塊還能不能正常提供服務。

這就是考慮模塊的容災性，一般都是采用分布式，服務部署在三臺機器上，一臺如果掛了，還有其他兩臺提供服務。

還有就是要彈性可伸縮，即我們的模塊可不可以直接 部署多臺機器來提高承載能力。

如果用戶量突然上來了，或者流量突然上來了，可以通過快速部署多臺機器來抗住流量。而不是模塊只能在單機上跑，多部署幾臺就發(fā)生各種問題。

這才能說明是有足夠強的風險意識的。

9.設計評審

前八的階段其實都是設計階段，那么你的設計需要讓組里的同學一起來評審一下，看看有沒有什么問題。

大家主要也是看看你的模塊 會不會給其他模塊或者整個系統(tǒng)帶來什么問題 以及 設計的是否合理。

10.寫代碼

終于到寫代碼的階段了，其實到這時候，是最容易的。

寫代碼就是體力活了，不是腦力活了。

11.自測

寫完代碼，我們需要自測，自己的功能會不會有什么問題。

這里可能需要自己造一造數(shù)據(jù)，跑一跑 看看和預想的是不是一樣的。

12.聯(lián)調(diào)

自己的模塊可能會涉及到其他模塊之間的一個交互，或者和前端的一個交互。

所以需要其他同學配合一起來測試。

這里就有很多溝通工作了，因為其他同學可能手頭有自己的活，那么就要協(xié)調(diào)一個時間來一起測試。

這一步也是很費時間的，其費時關(guān)鍵是要等，要等其他同學有空和你聯(lián)調(diào)，而且往往不是聯(lián)調(diào)一次就能解決問題的。

所以 在評估開發(fā)時間的時候 也要考慮到聯(lián)調(diào)的時間。

這也是大廠研發(fā)效率低的地方，但上百人開發(fā)的項目，這種溝通上消耗也是在所難免的。

13.交給測試

自己的代碼，自己測 一般都測不出什么問題，需要交給測試同學來給你測一測。

這里如果測試同學測出問題，你就要判斷確實有問題還是 測試方式不對，如果有問題就要修改，在提給測試，反反復復這么幾輪，直到測試同學測試沒問題了。

這個過程也是累心的。

14.code review

代碼合入主干之前，需要 項目組的同學一起來評審一下你的代碼。

之前是評審設計，看設計上有沒有什么缺失，這次是大家來看看你代碼寫的怎么樣。

例如合入主干會不會有什么問題，代碼兼容性做的好不好，接口設計的好不好，甚至字段，函數(shù)，變量名，命名合不合理。

都要經(jīng)過大家的評審，如果有問題就還是要改。

如果沒有問題一般 大家會給+2（就是通過的意思），這樣就可以合入主干了。

15.合入主干

合入主干為什么會單獨列出來呢。

其實合入主干是很重要的，經(jīng)常是自己的代碼沒問題，但合入主干之后就有問題了。

一般就是合入主干的時候有沖突，例如你從主干拉出一個分支，另一個同學從主干拉出一個分支，而且兩個分支修改了同一個模塊，如果另一個同學提前合入主干，你在合入主干的時候就會有代碼沖突。

在解決代碼沖突的時候 就會修改別人的代碼，這個過程很容易產(chǎn)生新的bug。

一般合入主干之后，測試同學還要重新跑一個全量測試，才能放心發(fā)布。

16.發(fā)布

最后一步就是發(fā)布了。

發(fā)布其實就是把主干的代碼更新到線上的服務器上。

一些還沒有工作的同學，可能不太理解究竟什么是發(fā)布。

用大白話來講，就是把 本地的代碼或者某臺機器的代碼，編譯成可執(zhí)行文件，然后更新到 線上的服務器（一個獨立的集群，專門處理線上的流量）并運行起來。

上線是最重要的一步了，也很容易出問題，因為一個大型項目，其上線的過程都非常復雜（要更新上百臺機器的集群），而且要考慮線上新版和舊版本的兼容問題。

這也是為什么大廠項目都選擇深夜上線，因為深夜在線用戶最少，如果出問題，影響的用戶會比較少，可以快速修復。

所以大家經(jīng)?？吹?某大廠程序員深夜上線發(fā)布版本之類的。

總結(jié)

整整講了十六個步驟！把大廠研發(fā)流程中 具體都有哪一步，為什么要這么做，都分析的很清楚了。

不過在大廠也不是所有部門都按照這個流程來的，每個部門都有自己玩法，各個部門也不太統(tǒng)一。

我這里是介紹的是已經(jīng)比較規(guī)范的流程，但流程越正規(guī)，研發(fā)效率就越低，想要提高效率，就是簡化流程，簡化流程，就會提高項目出錯的概率。

所以這也是一個相互權(quán)衡的過程，每一個部門可能根據(jù)自己的業(yè)務特點，適當簡化流程。

好了，講了這么多，希望對錄友們有所啟發(fā)。

最后代碼隨想錄刷題網(wǎng)站上線咯：programmercarl.com，200道力扣題目刷題順序，詳細題解，支持C++、Java、Python、Go、JS等多語言版本，一個你只要發(fā)現(xiàn)，就會收藏的硬核算法學習網(wǎng)站。

我是程序員Carl，哈工大師兄，獲得過ACM亞洲區(qū)獎牌，先后在BAT中的兩家采坑，一位文舞雙全的程序員?？梢约游覀€人VX：carlsun04，拉你進刷題交流群，備注：個人自我介紹+組隊刷題， 否則不會通過哦

覺得不錯的話，還請小伙伴 點贊 支持下，希望能幫助到更多同學 ??? ??