大廠前端項目的研發(fā)流程詳解卫玖，前端必看！
雙越?慕課訓(xùn)練營?昨天
來源：慕課手記
如需轉(zhuǎn)載原朝，請標(biāo)注來源驯嘱！
之前雙越老師在慕課網(wǎng)前端核心用戶 qq 群進行了一次直播式分享，主題是《大廠前端項目的研發(fā)流程》喳坠。本文就是這次分享的所有文字內(nèi)容鞠评，給做前端的同學(xué)查閱參考。
接下來將分享雙越老師的 ——?大廠前端項目的研發(fā)流程壕鹉。即剃幌，在一線互聯(lián)網(wǎng)公司，一個項目的開發(fā)晾浴，或者產(chǎn)品的迭代负乡，從一開始到上線，都要經(jīng)歷哪些核心步驟脊凰、哪些角色人員。而我們前端程序員，又是如何參與其中的.......
好多年之前結(jié)識了一個創(chuàng)業(yè)公司的技術(shù)負(fù)責(zé)人圈浇，一直也沒斷了聯(lián)系辩块，有一次和他約飯，他就說：現(xiàn)在公司慢慢壯大帕胆，幾十個人了数尿，想了解一下大廠的開發(fā)規(guī)范，否則越大越難管理惶楼。
當(dāng)時我也沒做什么準(zhǔn)備右蹦，于是就邊吃邊聊诊杆，把我想到的都跟他說了，不過比較散亂何陆。從那時候開始晨汹，我就想應(yīng)該很多人都有這個困惑，特別是中小型公司的管理者和程序員贷盲。于是淘这，經(jīng)過了這么久我還是最終整理出了這篇分享稿。
但是巩剖，本次分享并不是泛泛而談铝穷，我除了會講解各個流程、階段和角色人員之外佳魔，還會講到一些我們常用的工具曙聂、技術(shù)點。我覺得我也有能力給大家講出來鞠鲜，因為我既是一名大廠的高級前端工程師宁脊、有一定的開發(fā)經(jīng)驗，又是一名 PMP 和項目負(fù)責(zé)人贤姆、有項目管理的知識積累和實踐榆苞。
全流程概述
閑話不多說，畫了一個流程圖給大家做一個整體流程霞捡、角色坐漏、交付物的概述。
接下來給大家介紹一下各個角色：
項目委員會：這是一個很虛的角色碧信，即能確定項目是否要做的那幫人仙畦，有時候可能就是一個高級經(jīng)理就能拍板確定。和我們實際開發(fā)沒啥關(guān)系音婶，不用去關(guān)心他慨畸。
PM：產(chǎn)品經(jīng)理，也是一個項目的推動者衣式，即兼職項目經(jīng)理的角色寸士。
UE：交互設(shè)計師，負(fù)責(zé)頁面布局碴卧、交互的設(shè)計弱卡，不負(fù)責(zé)視圖的細(xì)節(jié)。
UI：視覺設(shè)計師住册，交互確定之后婶博，設(shè)計頁面樣式。注意荧飞，很多情況下凡人，UE 和 UI 是一個人名党。
RD：后端開發(fā)人員。
CRD：客戶端開發(fā)人員挠轴，安卓和 ios 都是传睹。
FE：前端開發(fā)人員。
QA：測試人員岸晦。
OP：服務(wù)器運維人員欧啤，一般負(fù)責(zé)審批上線單。
在說幾點注意事項：這個流程是站在前端開發(fā)角度來分析的启上，因此好多步驟的發(fā)起人都是 FE邢隧。（PS：在此我也希望大家在工作中都要做到積極熱情，主動承擔(dān)一些事情冈在，你會得到收獲的倒慧。）
這個流程看著非常復(fù)雜冗長，你可能會擔(dān)心執(zhí)行起來的效率讥邻。其實迫靖，我只是把所有的細(xì)節(jié)都畫出來了而已院峡，實際執(zhí)行起來不會太麻煩兴使，有些事情很快就能做完，例如聯(lián)調(diào)照激。
圖右側(cè)列出了每個步驟的交付物发魄，即該步驟做完需要產(chǎn)出的文檔或者其他內(nèi)容。交付物是項目管理中非常重要的概念俩垃，有了交付物才有能證明你真正做了執(zhí)行并完成了這個步驟励幼，而且萬一后面出了問題，也可以回溯（甩鍋）口柳。例如評審會結(jié)束之后苹粟，一定群發(fā)郵件寫出會議結(jié)論和評審人。
上述流程有些可能會被大家忽略跃闹，或者覺得多余嵌削、浪費時間，例如技術(shù)方案設(shè)計和評審望艺，再例如自測苛秕。其實只要你有點開發(fā)經(jīng)驗或者項目管理經(jīng)驗，都應(yīng)該知道這不是浪費時間找默。拿技術(shù)方案設(shè)計來說艇劫，如果你接下來開發(fā)程序很順利，寫一個技術(shù)方案并不是難事兒惩激，你不會因此而延期店煞；但如果你技術(shù)方案寫了兩天都沒寫出來蟹演，那你開發(fā)的時候估計也磕磕絆絆不順利，延期風(fēng)險很大浅缸。
詳細(xì)流程
接下來我們將假想一個實際的案例（因為我們不會在這里演示如何開發(fā)）—— 為頁面增加評論（發(fā)布評論轨帜，評論列表、點贊衩椒、回復(fù)） —— 這個功能蚌父，來把上述各個步驟詳細(xì)分析一下，一來是再深入了解一些細(xì)節(jié)毛萌，二來是幫助大家加深對整個研發(fā)流程的理解和印象苟弛。
項目立項
這個過程我們作為 FE 很可能是參與不到，或者壓根就不知道的阁将。因為在需求評審之前膏秫，所有的事情都是 PM 來主導(dǎo)的，只有項目立項之后做盅，并且 PM 把需求編寫完成缤削，才能流轉(zhuǎn)到 FE 這里〈盗瘢總之亭敢，這個過程你不用關(guān)心，只需要知道有了這個過程图筹，PM 才能編寫需求帅刀，并發(fā)起需求評審。
編寫需求和需求評審
編寫需求是 PM 的工作远剩，我們不用關(guān)心扣溺。接下來 PM 會拉各個角色（UE UI RD CRD FE QA）開會，進行需求評審瓜晤。
會議的主要步驟：
第一锥余，PM 會按照需求文檔把功能全部講一遍，包括 C 端的各個功能（如發(fā)布評論痢掠，評論列表驱犹、點贊、回復(fù)）志群，也包括后臺的一些策略（黃反着绷、敏感詞屏蔽）和統(tǒng)計；
第二锌云，各個角色的與會者提出自己的問題荠医，PM 來解答；
第三，如果問題全部被解答彬向，則評審?fù)ㄟ^兼贡，否則評審不通過。
FE 參見需求評審和其他 RD CRD 類似娃胆，最重要的是關(guān)心這些功能的技術(shù)實現(xiàn)：是否可實現(xiàn)遍希，或者實現(xiàn)成本高不高。例如里烦，PM 要在用戶長按點贊按鈕時顯示絢麗的動畫凿蒜，這一點使用 h5 來成本太高，你就可以建議 PM 在 h5 端換成簡單動畫胁黑。另外废封，開發(fā)人員也可以對 PM 的功能邏輯提出質(zhì)疑，不一定非得是技術(shù)問題丧蘸。
評審結(jié)束之后漂洋，PM 一般就會向各個開發(fā)人員要排期。注意力喷，這時候不能立刻答應(yīng)刽漂，最好的回復(fù)方式是：我們回去討論一下，明天下班之前（或者某個未來不太久的時間點弟孟，都行）給你答復(fù)贝咙。這樣，你可以和其他 FE 或者架構(gòu)師來討論技術(shù)方案披蕉，一起評估一個比較靠譜的排期颈畸。
（PS：如果你的項目有拍死的 deadline 乌奇，那沒招了没讲，你就安排加班吧。）
編寫技術(shù)方案
這一步容易被大家忽略礁苗，人類好像是本能的眼高手低爬凑，感覺看似比較簡單的事情就很樂觀。越是這種心態(tài)试伙，越要謹(jǐn)慎行事嘁信，在這里我建議所有的公司或者團隊，都把編寫技術(shù)方案作為一個必要的步驟疏叨，即打開開發(fā)前必須編寫技術(shù)方案潘靖，并完成評審。
技術(shù)方案到底寫什么——技術(shù)方案就是寫你計劃如何實現(xiàn)需求中的功能蚤蔓。拿這個評論項目來說卦溢，發(fā)布功能如何實現(xiàn)？要調(diào)用什么接口，輸入輸出時什么单寂？要不要考慮 xss 攻擊贬芥？再如點贊，是先執(zhí)行動畫再調(diào)用接口宣决，還是先調(diào)用接口再執(zhí)行動畫蘸劈？還有，你的代碼如何拆解尊沸，分幾個模塊威沫，有哪些核心的方法。這些都要寫洼专。技術(shù)方案沒有一個固定的格式可供參考壹甥，因此是否能把技術(shù)方案寫的清晰且使用，是判斷一個人技術(shù)能力的標(biāo)準(zhǔn)之一壶熏。
技術(shù)方案評審
技術(shù)方案編寫完成之后句柠，需要拉內(nèi)部的經(jīng)理、架構(gòu)師（或者技術(shù)負(fù)責(zé)人）棒假、其他對接的角色（RD CRD）來評審技術(shù)方案溯职。內(nèi)部人員注意評審這個方案是不是符合設(shè)計原則，有擴展性帽哑，以及是否有其他坑（如性能問題谜酒，安全漏洞等）。外部對接的角色主要評審接口是否全面妻枕，輸入輸出設(shè)計是否合理僻族。
技術(shù)方案評審?fù)ㄟ^之后，就得給 PM 反饋排期了屡谐。注意述么，估算工期一定要留有 buffer ，給自己留好余地愕掏。有工作經(jīng)驗的人都知道度秘，一個人在一個公司里，一般會同時擔(dān)任很多的工作饵撑，你不能保證接下來不會有其他功能耽誤你的時間剑梳。例如，這個項目你本來預(yù)估是 10 人/天工作量滑潘，那你最好反饋 12-13 人/天垢乙。
（PS：評審之前反饋排期也可以，只是評審之后反饋语卤，更加靠譜一些追逮。）
補充一句：這里我們僅僅提到了 FE 的技術(shù)方案評審蓖租，其實 CRD 和 RD 也會有他們的技術(shù)方案評審，評審時也需要拉著 FE 羊壹。其實大家的關(guān)系都是相互的蓖宦，彼此相互把關(guān)，出來的設(shè)計方案就不會有太大問題油猫。
交互視覺設(shè)計和評審
交互和視覺的設(shè)計稠茂，是 UE 和 UI 要做的事情，我們不管他們怎么做情妖。他們做完之后會拉著 PM FE CRD QA 進行設(shè)計稿的評審睬关，即看看這個頁面最終是什么樣子。
FE 去參加主要看看視覺的實現(xiàn)是否有難度毡证，特別是對一些透明电爹、漸變、毛玻璃料睛、陰影等特效丐箩，要慎重對待，還有比較常見的例如 1px 邊框的問題恤煞。這些如果你遇到了屎勘，但是不確定是否可以實現(xiàn)，那最好回去查查再回復(fù)他們居扒。
評審?fù)ㄟ^之后概漱，UI 將產(chǎn)出設(shè)計稿給 FE 。按照慣例喜喂，UI 應(yīng)該給 750 像素的圖瓤摧，即以 iphone 6 兩倍屏為標(biāo)準(zhǔn)的圖，并且設(shè)計稿中標(biāo)出所有的顏色色值和間距玉吁、字體的大小照弥。他們有專門的工具來導(dǎo)出這些，例如用 sketch 就可以輕松導(dǎo)出诈茧。注意产喉，此時如果你已經(jīng)給了排期捂掰，但是設(shè)計稿比較復(fù)雜的話敢会，必須及時和 PM 溝通修改排期，有問題早發(fā)現(xiàn)早處理这嚣。
開發(fā)
有了前端的技術(shù)方案鸥昏，有了客戶端、后端的接口姐帚，有了視覺設(shè)計稿吏垮，這時候就可以進行開發(fā)了。一般需要從 git 里新拉一個分支，使用 mock 數(shù)據(jù)（此時后端還沒有接口）膳汪。如有客戶端的對接唯蝶，還需要用到一些模擬 native 能力的插件，如果你們沒有那就只能等到和客戶端聯(lián)調(diào)時再看了遗嗽。開發(fā)產(chǎn)出的不僅僅是代碼粘我，還應(yīng)該有開發(fā)文檔（也可以是比較豐富的注釋）和測試用例。
我們作為技術(shù)人員痹换，往往以為一個軟件項目最關(guān)鍵的就是代碼開發(fā)征字，而傳統(tǒng)的項目管理流程說，代碼開發(fā)只占軟件生命周期的 1/6 娇豫。根據(jù)本文相信你能體會到匙姜，代碼開發(fā)真的只占軟件項目的很少一部分。所以冯痢，作為程序員你要想自己值錢氮昧、有不可替代性，就要從整個軟件項目的階段入手浦楣，而不僅僅是提高開發(fā)能力郭计。
視覺聯(lián)調(diào)
代碼開發(fā)完成之后，所有界面都做完了椒振，你要告訴 UI 進行視覺聯(lián)調(diào)昭伸。雖然你自己是按照 UI 給的設(shè)計稿做的，但是你不一定每一個細(xì)節(jié)都做的正確澎迎，需要 UI 確認(rèn)庐杨。另外，各個手機屏幕的響應(yīng)式做的怎樣夹供，也需要 UI 拿不同手機測試灵份。他如何測試你不用管，只需要配合他就行了哮洽，遇到問題你就改填渠。
這一步的產(chǎn)出是“聯(lián)調(diào)報告”，不要被這個詞給嚇著鸟辅，以為要寫一個正規(guī)的文檔》帐玻現(xiàn)實不是這樣的，待 UI 聯(lián)調(diào)完了之后匪凉，讓他在項目群里 @ PM 回復(fù)一下說“視覺聯(lián)調(diào)通過”枪眉，這樣就行了，這就是聯(lián)調(diào)報告再层，有這個記錄即可贸铜。包括圖中所有的“報告”堡纬，最常見的形式就是郵件和群信息。但是蒿秦，哪怕就是一封郵件或者群信息烤镐，短短的一句話，這個步驟也不能省略棍鳖。否則誰知道視覺聯(lián)調(diào)已經(jīng)成功了职车？
程序聯(lián)調(diào)
FE 開發(fā) h5 頁，CRD 開發(fā)客戶端鹊杖，RD 開發(fā)后端接口悴灵，待大家都開發(fā)完成之后，也需要把代碼放在一起聯(lián)調(diào)一下骂蓖。將 h5 和后端代碼打包到同一個測試機上积瞒，既可以聯(lián)調(diào) h5 和后端接口。將客戶端的訪問地址指向這個測試機登下，就可以聯(lián)調(diào)客戶端和后端接口茫孔，也可以聯(lián)調(diào)客戶端和 h5 。聯(lián)調(diào)成功之后被芳，最好再給 PM 看一眼缰贝，讓他確定這就是做出來的效果。
自測
這一步我是自己加的畔濒，也是我自己的做事風(fēng)格剩晴。但這一步不是我自創(chuàng)的，在傳統(tǒng)軟件項目管流程里侵状，就有“冒煙測試”這一步驟赞弥，也就是自測。但是趣兄，我在所有帶過的團隊中绽左，都沒有發(fā)現(xiàn)規(guī)定必須自測且產(chǎn)出自測記錄。但是艇潭，我還是堅持自己的觀點拼窥，我負(fù)責(zé)的項目必須要有自測步驟，而且我呼吁大家也要堅持自測蹋凝。
自測并不是把所有功能全部詳細(xì)測試鲁纠，而是把核心功能都測試一遍，并記錄測試結(jié)果仙粱，保證主流程是能跑通的房交。我相信每個有工作經(jīng)驗的同學(xué)都遇到過這種情況，程序員代碼寫完就提測給 QA 了伐割，QA 一運行立馬報錯候味，無法繼續(xù)測試，打回來找程序員重新修改隔心。這種事情極大影響效率白群，誰都不樂意看到。如何避免呢硬霍？答案就是提測前帜慢，先自測。
自測依據(jù)需求的核心功能唯卖，可以是人肉手動測試粱玲，有可以是自動化單元測試，這個不要求拜轨。但是最后要產(chǎn)出一個自測記錄抽减，即用一個表格，列出所有核心功能橄碾，并記錄每個功能你的測試結(jié)果卵沉。為何要有這個產(chǎn)出，就是為了證明你真的測試過每個功能了法牲，而不是眼高手低看兩眼就通過了史汗。一般需要產(chǎn)出交付物時，大家都會認(rèn)真對待拒垃，沒有交付物大家就可能敷衍了事停撞。
提測
自測完成，并產(chǎn)出自測記錄悼瓮，即可以提測了怜森。提測需要 FE CRD RD 和 PM 一起，將需求文檔谤牡、代碼副硅、自測記錄提交給 QA ，并發(fā)正式的提測郵件翅萤，告知所有項目角色該項目提測了恐疲。QA 收到之后，確認(rèn)分析完成套么，需要回復(fù)計劃的測試完成時間培己。然后 QA 開始測試。
測試
QA 測試過程中肯定會不斷的產(chǎn)出 bug 列表胚泌，此時 FE 應(yīng)該要求 QA 把所有 bug 的描述都寫清楚省咨，即能讓個自己傻瓜式的復(fù)現(xiàn)這個 bug ，以便快速修改玷室。遇到復(fù)現(xiàn)不了的問題零蓉，一定要第一時間找 QA 來復(fù)現(xiàn)笤受，有些問題復(fù)現(xiàn)了一次再也復(fù)現(xiàn)不了，那你就先別管它敌蜂，先去改別的問題箩兽。QA 測試完成之后，要發(fā)準(zhǔn)出郵件章喉，告訴所有項目角色該項目測試通過汗贫，可以準(zhǔn)備上線了。
上線 & 回歸測試
QA 測試完之后不一定能立馬上線秸脱，因為一般產(chǎn)品的上線都是例行的落包。頻率比較快的產(chǎn)品，可能規(guī)定每周一到周四下午的某個時間點可以上線摊唇，晚上一般不上線咐蝇，周五一般不上線，除非緊急修復(fù) bug 遏片。因為嘹害，上線之后就有可能帶來一些 bug ，可能晚些才能發(fā)現(xiàn)吮便，如果晚上或者周五上線笔呀，一旦發(fā)現(xiàn) bug 大家已經(jīng)回家睡覺或者過周末了，不容易集中人力修改髓需。
上線的步驟一般是先合并代碼到 dev 或者 master 分支许师，每次上線可能是多個功能一起上線，因此合并代碼時還可能會出現(xiàn)沖突僚匆，得先解決沖突微渠。然后開始發(fā)起上線審批，生成上線單咧擂，需要 PM QA 和各個技術(shù)經(jīng)理審批確認(rèn)逞盆，OP 才能將這個上線單解鎖，這樣就可以發(fā)起上線松申。
上線的機器一般也分好幾步云芦，每一步都需要 QA 參與回歸測試：
第一步是預(yù)覽機，預(yù)覽機只對內(nèi)有效贸桶，外網(wǎng)看不到舅逸，但是加載線上的真實數(shù)據(jù)。
第二步是單臺機器皇筛，即線上機的一臺機器琉历。
第三步是單機房，即線上機的一個機房。第四部是全量旗笔，即線上機的所有機房彪置。這些步驟全部操作完成，并且 QA 全部回歸測試完成换团，才算真正的結(jié)束悉稠。
如果其中一個步驟遇到問題宫蛆，就需要啟動快速回滾艘包。回滾就是用 git 的上一條記錄重新上線耀盗，覆蓋目前的代碼想虎，步驟也是先預(yù)覽機、單機器叛拷、單機房舌厨、全量，每一步也需要 QA 回歸測試忿薇。如果 bug 影響嚴(yán)重裙椭，還需要項目的主要角色寫檢討，做復(fù)盤匯報署浩，總結(jié)教訓(xùn)揉燃。
項目總結(jié)（可選）
項目總結(jié)是可選的，而且我發(fā)現(xiàn)大部分的團隊都不會去做總結(jié)筋栋，覺得上線完了就大功告成炊汤，該啟動下一個項目了。但我覺得弊攘，無論是不是做項目抢腐，做完一件事（如看完一本書）就應(yīng)該自己總結(jié)一下〗蠼唬回顧一下經(jīng)過迈倍，總結(jié)一下得失，積累一點經(jīng)驗捣域，這樣才能慢慢成長啼染。
