有啥進大廠的前端學習指南嗎？

作者| 慕課網精英講師 雙越老師

本文首發自「慕課網」，想了解更多IT乾貨內容，程式設計師圈內熱聞，歡迎關注！

在一線網際網路公司，一個專案的開發，或者產品的迭代，從一開始到上線，都要經歷哪些核心步驟、哪些角色人員。而我們前端程式設計師，又是如何參與其中的。

這個主題是我在一年多之前就想做的，只是一直拖到近期才產出了這篇分享。我好多年之前結識了一個創業公司的技術負責人，一直也沒斷了聯絡，有一次和他約飯，他就說：現在公司慢慢壯大，幾十個人了，想了解一下大廠的開發規範，否則越大越難管理。

當時我也沒做什麼準備，於是就邊吃邊聊，把我想到的都跟他說了，不過比較散亂。從那時候開始，我就想應該很多人都有這個困惑，特別是中小型公司的管理者和程式設計師。於是，經過了這麼久我還是最終整理出了這篇分享稿。

但是，本次分享並不是泛泛而談，我除了會

講解各個流程、階段和角色人員之外，還會講到一些我們常用的工具、技術點。我覺得我也有能力給大家講出來，因為我既是一名大廠的高階前端工程師、有一定的開發經驗，又是一名 PMP 和專案負責人、有專案管理的知識積累和實踐。

慕課網免費好課

慕課網

智慧小程式

全流程概述

閒話不多說，畫了一個流程圖給大家做一個整體流程、角色、交付物的概述。

接下來給大家介紹一下各個角色。

專案委員會：這是一個很虛的角色，即能確定專案是否要做的那幫人，有時候可能就是一個高階經理就能拍板確定。和我們實際開發沒啥關係，不用去關心他。

PM：產品經理，也是一個專案的推動者，即兼職專案經理的角色。

UE：互動設計師，負責頁面佈局、互動的設計，不負責檢視的細節。

UI：視覺設計師，互動確定之後，設計頁面樣式。注意，很多情況下，UE 和 UI 是一個人。

RD：後端開發人員。

CRD：客戶端開發人員，安卓和 ios 都是。

FE：前端開發人員。

QA：測試人員。

OP：伺服器運維人員，一般負責審批上線單。

再說幾點注意事項：

這個流程是站在前端開發角度來分析的，因此好多步驟的發起人都是 FE。PS：在此我也希望大家在工作中都要做到積極熱情，主動承擔一些事情，你會得到收穫的。

這個流程看著非常複雜冗長，你可能會擔心執行起來的效率。其實，我只是把所有的細節都畫出來了而已，實際執行起來不會太麻煩，有些事情很快就能做完，例如聯調。

圖右側列出了每個步驟的交付物，即該步驟做完需要產出的文件或者其他內容。交付物是專案管理中非常重要的概念，有了交付物才有能證明你真正做了執行並完成了這個步驟，而且萬一後面出了問題，也可以回溯（甩鍋）。例如評審會結束之後，一定群發郵件寫出會議結論和評審人。

上述流程有些可能會被大家忽略，或者覺得多餘、浪費時間，例如技術方案設計和評審，再例如自測。其實只要你有點開發經驗或者專案管理經驗，都應該知道這不是浪費時間。拿技術方案設計來說，如果你接下來開發程式很順利，寫一個技術方案並不是難事兒，你不會因此而延期；但如果你技術方案寫了兩天都沒寫出來，那你開發的時候估計也磕磕絆絆不順利，延期風險很大。

詳細流程

接下來我們將假想一個實際的案例（因為我們不會在這裡演示如何開發）—— 為頁面增加評論（釋出評論，評論列表、點贊、回覆） —— 這個功能，來把上述各個步驟詳細分析一下，一來是再深入瞭解一些細節，二來是幫助大家加深對整個研發流程的理解和印象。

專案立項

這個過程我們作為 FE 很可能是參與不到，或者壓根就不知道的。因為在需求評審之前，所有的事情都是 PM 來主導的，只有專案立項之後，並且 PM 把需求編寫完成，才能流轉到 FE 這裡。總之，這個過程你不用關心，只需要知道有了這個過程，PM 才能編寫需求，併發起需求評審。

編寫需求和需求評審

編寫需求是 PM 的工作，我們不用關心。接下來 PM 會拉各個角色（UE UI RD CRD FE QA）開會，進行需求評審。會議的主要步驟：第一，PM 會按照需求文件把功能全部講一遍，包括 C 端的各個功能（如釋出評論，評論列表、點贊、回覆），也包括後臺的一些策略（黃反、敏感詞遮蔽）和統計；第二，各個角色的與會者提出自己的問題，PM 來解答；第三，如果問題全部被解答，則評審透過，否則評審不透過。

FE 參見需求評審和其他 RD CRD 類似，最重要的是關心這些功能的技術實現：是否可實現，或者實現成本高不高。例如，PM 要在使用者長按點贊按鈕時顯示絢麗的動畫，這一點使用 h5 來成本太高，你就可以建議 PM 在 h5 端換成簡單動畫。另外，開發人員也可以對 PM 的功能邏輯提出質疑，不一定非得是技術問題。

評審結束之後，PM 一般就會向各個開發人員要排期。注意，這時候不能立刻答應，最好的回覆方式是：我們回去討論一下，明天下班之前（或者某個未來不太久的時間點，都行）給你答覆。這樣，你可以和其他 FE 或者架構師來討論技術方案，一起評估一個比較靠譜的排期。PS：如果你的專案有拍死的 deadline ，那沒招了，你就安排加班吧。

編寫技術方案

這一步容易被大家忽略，人類好像是本能的眼高手低，感覺看似比較簡單的事情就很樂觀。越是這種心態，越要謹慎行事，在這裡我建議所有的公司或者團隊，都把編寫技術方案作為一個必要的步驟，即開啟開發前必須編寫技術方案，並完成評審。

技術方案到底寫什麼——技術方案就是寫你計劃如何實現需求中的功能。拿這個評論專案來說，釋出功能如何實現？要呼叫什麼介面，輸入輸出時什麼？要不要考慮 xss 攻擊？再如點贊，是先執行動畫再呼叫介面，還是先呼叫介面再執行動畫？還有，你的程式碼如何拆解，分幾個模組，有哪些核心的方法。這些都要寫。技術方案沒有一個固定的格式可供參考，因此是否能把技術方案寫的清晰且使用，是判斷一個人技術能力的標準之一。

技術方案評審

技術方案編寫完成之後，需要拉內部的經理、架構師（或者技術負責人）、其他對接的角色（RD CRD）來評審技術方案。內部人員注意評審這個方案是不是符合設計原則，有擴充套件性，以及是否有其他坑（如效能問題，安全漏洞等）。外部對接的角色主要評審介面是否全面，輸入輸出設計是否合理。

技術方案評審透過之後，就得給 PM 反饋排期了。注意，估算工期一定要留有 buffer ，給自己留好餘地。有工作經驗的人都知道，一個人在一個公司裡，一般會同時擔任很多的工作，你不能保證接下來不會有其他功能耽誤你的時間。例如，這個專案你本來預估是 10 人/天工作量，那你最好反饋 12-13 人/天。PS：評審之前反饋排期也可以，只是評審之後反饋，更加靠譜一些。

補充一句。這裡我們僅僅提到了 FE 的技術方案評審，其實 CRD 和 RD 也會有他們的技術方案評審，評審時也需要拉著 FE 。其實大家的關係都是相互的，彼此相互把關，出來的設計方案就不會有太大問題。

互動視覺設計和評審

互動和視覺的設計，是 UE 和 UI 要做的事情，我們不管他們怎麼做。他們做完之後會拉著 PM FE CRD QA 進行設計稿的評審，即看看這個頁面最終是什麼樣子。FE 去參加主要看看視覺的實現是否有難度，特別是對一些透明、漸變、毛玻璃、陰影等特效，要慎重對待，還有比較常見的例如 1px 邊框的問題。這些如果你遇到了，但是不確定是否可以實現，那最好回去查查再回復他們。

評審透過之後，UI 將產出設計稿給 FE 。按照慣例，UI 應該給 750 畫素的圖，即以 iphone 6 兩倍屏為標準的圖，並且設計稿中標出所有的顏色色值和間距、字型的大小。他們有專門的工具來匯出這些，例如用 sketch 就可以輕鬆匯出。注意，此時如果你已經給了排期，但是設計稿比較複雜的話，必須及時和 PM 溝通修改排期，有問題早發現早處理。

開發

有了前端的技術方案，有了客戶端、後端的介面，有了視覺設計稿，這時候就可以進行開發了。一般需要從 git 裡新拉一個分支，使用 mock 資料（此時後端還沒有介面）。如有客戶端的對接，還需要用到一些模擬 native 能力的外掛，如果你們沒有那就只能等到和客戶端聯調時再看了。開發產出的不僅僅是程式碼，還應該有開發文件（也可以是比較豐富的註釋）和測試用例。

我們作為技術人員，往往以為一個軟體專案最關鍵的就是程式碼開發，而傳統的專案管理流程說，程式碼開發只佔軟體生命週期的 1/6 。根據本文相信你能體會到，程式碼開發真的只佔軟體專案的很少一部分。所以，作為程式設計師你要想自己值錢、有不可替代性，就要從整個軟體專案的階段入手，而不僅僅是提高開發能力。

視覺聯調

程式碼開發完成之後，所有介面都做完了，你要告訴 UI 進行視覺聯調。雖然你自己是按照 UI 給的設計稿做的，但是你不一定每一個細節都做的正確，需要 UI 確認。另外，各個手機螢幕的響應式做的怎樣，也需要 UI 拿不同手機測試。他如何測試你不用管，只需要配合他就行了，遇到問題你就改。

這一步的產出是“聯調報告”，不要被這個詞給嚇著，以為要寫一個正規的文件。現實不是這樣的，待 UI 聯調完了之後，讓他在專案群裡 @ PM 回覆一下說“視覺聯調透過”，這樣就行了，這就是聯調報告，有這個記錄即可。包括圖中所有的“報告”，最常見的形式就是郵件和群資訊。但是，哪怕就是一封郵件或者群資訊，短短的一句話，這個步驟也不能省略。否則誰知道視覺聯調已經成功了？

程式聯調

FE 開發 h5 頁，CRD 開發客戶端，RD 開發後端介面，待大家都開發完成之後，也需要把程式碼放在一起聯調一下。將 h5 和後端程式碼打包到同一個測試機上，既可以聯調 h5 和後端介面。將客戶端的訪問地址指向這個測試機，就可以聯調客戶端和後端介面，也可以聯調客戶端和 h5 。聯調成功之後，最好再給 PM 看一眼，讓他確定這就是做出來的效果。

自測

這一步我是自己加的，也是我自己的做事風格。但這一步不是我自創的，在傳統軟體專案管流程裡，就有“冒煙測試”這一步驟，也就是自測。但是，我在所有帶過的團隊中，都沒有發現規定必須自測且產出自測記錄。但是，我還是堅持自己的觀點，我負責的專案必須要有自測步驟，而且我呼籲大家也要堅持自測。

自測並不是把所有功能全部詳細測試，而是把核心功能都測試一遍，並記錄測試結果，保證主流程是能跑通的。我相信每個有工作經驗的同學都遇到過這種情況，程式設計師程式碼寫完就提測給 QA 了，QA 一執行立馬報錯，無法繼續測試，打回來找程式設計師重新修改。這種事情極大影響效率，誰都不樂意看到。如何避免呢？答案就是提測前，先自測。

自測依據需求的核心功能，可以是人肉手動測試，有可以是自動化單元測試，這個不要求。但是最後要產出一個自測記錄，即用一個表格，列出所有核心功能，並記錄每個功能你的測試結果。為何要有這個產出，就是為了證明你真的測試過每個功能了，而不是眼高手低看兩眼就通過了。一般需要產出交付物時，大家都會認真對待，沒有交付物大家就可能敷衍了事。

提測

自測完成，併產出自測記錄，即可以提測了。提測需要 FE CRD RD 和 PM 一起，將需求文件、程式碼、自測記錄提交給 QA ，併發正式的提測郵件，告知所有專案角色該專案提測了。QA 收到之後，確認分析完成，需要回復計劃的測試完成時間。然後 QA 開始測試。

測試

QA 測試過程中肯定會不斷的產出 bug 列表，此時 FE 應該要求 QA 把所有 bug 的描述都寫清楚，即能讓個自己傻瓜式的復現這個 bug ，以便快速修改。遇到復現不了的問題，一定要第一時間找 QA 來複現，有些問題復現了一次再也復現不了，那你就先別管它，先去改別的問題。QA 測試完成之後，要發準出郵件，告訴所有專案角色該專案測試透過，可以準備上線了。

上線 & 迴歸測試

QA 測試完之後不一定能立馬上線，因為一般產品的上線都是例行的。頻率比較快的產品，可能規定每週一到週四下午的某個時間點可以上線，晚上一般不上線，週五一般不上線，除非緊急修復 bug 。因為，上線之後就有可能帶來一些 bug ，可能晚些才能發現，如果晚上或者週五上線，一旦發現 bug 大家已經回家睡覺或者過週末了，不容易集中人力修改。

上線的步驟一般是先合併程式碼到 dev 或者 master 分支，每次上線可能是多個功能一起上線，因此合併程式碼時還可能會出現衝突，得先解決衝突。然後開始發起上線審批，生成上線單，需要 PM QA 和各個技術經理審批確認，OP 才能將這個上線單解鎖，這樣就可以發起上線。

上線的機器一般也分好幾步，每一步都需要 QA 參與迴歸測試。第一步是預覽機，預覽機只對內有效，外網看不到，但是載入線上的真實資料。第二步是單臺機器，即線上機的一臺機器。第三步是單機房，即線上機的一個機房。第四部是全量，即線上機的所有機房。這些步驟全部操作完成，並且 QA 全部迴歸測試完成，才算真正的結束。

如果其中一個步驟遇到問題，就需要啟動快速回滾。回滾就是用 git 的上一條記錄重新上線，覆蓋目前的程式碼，步驟也是先預覽機、單機器、單機房、全量，每一步也需要 QA 迴歸測試。如果 bug 影響嚴重，還需要專案的主要角色寫檢討，做覆盤彙報，總結教訓。

專案總結（可選）

專案總結是可選的，而且我發現大部分的團隊都不會去做總結，覺得上線完了就大功告成，該啟動下一個專案了。但我覺得，無論是不是做專案，做完一件事（如看完一本書）就應該自己總結一下。回顧一下經過，總結一下得失，積累一點經驗，這樣才能慢慢成長。

歡迎關注「慕課網」，發現更多IT圈優質內容，分享乾貨知識，幫助你成為更好的程式設計師！