科普一下正式的大廠需求開發(fā)流程

大多數(shù)人認為的程序員，也就是很多人眼中的技術(shù)開發(fā)人員（前端或者后端），他們就是整個項目開發(fā)過程中的主力人員，此外就沒什么其余人了。

但其實，一個需求從提出到開發(fā)再到測試，直到最后上線，是需要幾波人共同努力的，而不是像很多外行理解的只需要程序員這種個角色就可以搞定的。

今天阿秀就根據(jù)在前司字節(jié)以及現(xiàn)司SAP的工作經(jīng)歷科普一下互聯(lián)網(wǎng)公司一般常見的需求開發(fā)流程有哪些？會有哪些人參與到？

新手朋友們可以稍微了解下大致流程有哪些，尤其是一些在校的學生粉絲們提前了解了解。

先科普一下常規(guī)的互聯(lián)網(wǎng)公司的需求開發(fā)中的三種角色以及三種環(huán)境：

三種角色分別是產(chǎn)品經(jīng)理、研發(fā)和測試，在下文中也會使用PM、RD、QA來做簡稱；

而三種環(huán)境依次是開發(fā)環(huán)境、測試環(huán)境和生產(chǎn)環(huán)境，有的還會在測試環(huán)境和生產(chǎn)環(huán)境中再加一個模擬生產(chǎn)環(huán)境做數(shù)據(jù)隔離和真實演練。

三種角色

1、產(chǎn)品經(jīng)理(Product Manager/Project Manager)，縮寫為PM：產(chǎn)品經(jīng)理是在產(chǎn)品的研發(fā)過程中，負責調(diào)查并根據(jù)用戶的需求制定出一套方案的相關(guān)人員。

2、研發(fā)(Research and Development engineer)，縮寫為RD：研發(fā)一般分為前端開發(fā)工程師或者后端開發(fā)工程師，比如C++后端開發(fā)工程師、Java后端開發(fā)工程師、Golang后端開發(fā)工程師等都屬于RD，他們是把功能具體實現(xiàn)出來的一撥人，也是網(wǎng)上各種程序員相關(guān)段子調(diào)侃的主要對象。

3、測試(Qualtiy Assurance)，縮寫為QA：QA的主要職責就是質(zhì)量保證工作，也就是很多人口中俗稱的測試，負責對RD實現(xiàn)的功能進行檢測，保證該功能在上線后能夠正常使用。

三種環(huán)境

1、開發(fā)環(huán)境

開發(fā)環(huán)境主要指研發(fā)進行功能開發(fā)的環(huán)境，其實就如同大家在自己的筆記本或者臺式機上寫程序一樣，這就是開發(fā)環(huán)境。

而大廠中用什么工具開發(fā)要看具體的組了，有些組選擇用統(tǒng)一型號的筆記本進行開發(fā)；也有些組會選擇使用開發(fā)機來進行開發(fā)。

這里一般是要求組員的開發(fā)環(huán)境都是一致的，比如大家都使用Window來進行開發(fā)，或者都用Mac進行開發(fā)或者開發(fā)機的型號也是一致的，為的就是減少可能因開發(fā)環(huán)境不一致而引發(fā)的BUG。

不要小看這個環(huán)境問題，很多莫名其妙出現(xiàn)的問題，最后排查下來都是由于環(huán)境不一致導致的。

2、測試環(huán)境

測試環(huán)境主要指的是測試人員進行功能驗收和檢測的環(huán)境，在正式上線前都會在這個環(huán)境中進行模擬功能的檢測。

這個環(huán)境一般臟數(shù)據(jù)會比較多，有時候為了模擬真實的線上環(huán)境，甚至要從線上數(shù)據(jù)庫copy數(shù)據(jù)到測試環(huán)境中去。

3、生產(chǎn)環(huán)境

生產(chǎn)環(huán)境就是廣大真實用戶使用的場景，也有的管它叫線上環(huán)境。這個環(huán)境是最重要的，因為一旦出事就是線上生產(chǎn)事故，需要立馬進行處理的。很多人看到的"程序員需要24小時 on call"的段子就是為了防止生產(chǎn)環(huán)境出問題。

不過有的比較講究的部門會在測試和生產(chǎn)環(huán)境之間再加一個生產(chǎn)隔離環(huán)境，比如涉及到支付、電商這樣跟錢強相關(guān)的部門。測試人員在測試環(huán)境中將需求測完無誤后，再發(fā)生產(chǎn)環(huán)境之前會現(xiàn)在生產(chǎn)隔離環(huán)境中走一遍，確認無誤后再正式上線。

下面我用一個很常規(guī)的功能：網(wǎng)站的登錄功能，來介紹下一個需求的正常開發(fā)流程是怎樣的，是如何從構(gòu)思到實現(xiàn)再到最終上線的，而在這其中又會使用哪些工具？涉及到哪些人？

需要說明的是不用公司流程可能有略微差別，這里主要介紹的是比較常見的需求開發(fā)迭代過程。

1、產(chǎn)品調(diào)研

一個需求的起點應該是產(chǎn)品經(jīng)理，也就是PM。

產(chǎn)品把調(diào)研結(jié)論寫成一頁紙"決策記錄"，附原型圖和指標公式，拉研發(fā)、測試、設計、運營、法務五方會審。

通過標準：指標可量化、技術(shù)風險可控、法務無否決。

評審表全員電子簽名后，需求池上鎖，任何人再加需求必須走"變更流程"，否則研發(fā)有權(quán)說"不"。

2、技術(shù)方案與評估

研發(fā)負責人3-7天內(nèi)給出技術(shù)方案：

• 時序圖：用戶→網(wǎng)關(guān)→登錄服務→風控→消息中心，每一步超時閾值標清楚；

• 接口定義：字段、碼值、限流閾值、降級邏輯；

• 數(shù)據(jù)變更：索引新增、歷史數(shù)據(jù)遷移腳本；

• 灰度策略：按用戶尾號分批，開關(guān)在配置中心，秒級回滾。

技術(shù)方案評審需要安全、性能、測試三方拍桌子，問題全部落地，研發(fā)才準開工，否則打回重新進行。

3、測試用例

測試同學拿到產(chǎn)品和技術(shù)組長的文檔后寫出"用例腦圖"，分功能、異常、性能、兼容四類，一鍵導入自動化平臺，等待研發(fā)人員將項目上線到測試環(huán)境中再開工。

4、正式開發(fā)

研發(fā)組長重新起一個會，簡單過一下需求，將需求分給組員，每個人負責1-2個需求。

其中研發(fā)人員統(tǒng)一用公司鏡像，本地一鍵起 Redis、MySQL、網(wǎng)關(guān)；

在代碼主分支上重新拉分支，一般是從master或者main分支重新開分支。

分支合并請求必須滿足以下下三條：

• 單測覆蓋率≥90%

• 靜態(tài)掃描零阻斷

• Code Review 兩人及其以上同意才可以發(fā)布。

每日晨會 15 分鐘，對齊需求進度，如果延期以及無法按時交付的話，組長需要馬上協(xié)調(diào)資源。

在組員全部開發(fā)完畢后，開發(fā)小組內(nèi)部會約定一個時間一起合并代碼，簡單自測一下沒什么問題才會發(fā)布到測試環(huán)境中。

然后通過測試人員開始測試。

5、開始測試

接口層用腳本壓 1 萬并發(fā)，UI 層用瀏覽器集群跑 20 條主流程； 同時把線上真實數(shù)據(jù)脫敏后灌入測試庫，造出 500 種"臟"組合，提前發(fā)現(xiàn)邊界 Bug。

嚴重 Bug 未清零，測試人員將版本打回，研發(fā)重新開工，直至全部功能確保無誤。

6、灰度發(fā)布

先推 10% 用戶，監(jiān)控看三行數(shù)字：成功率、延遲、錯誤率，任一紅線飄升，自動觸發(fā)回滾，5 秒內(nèi)切回老版本。

灰度 24 小時無異常，全量放開；期間運營在后臺看實時漏斗，確認指標達標才簽字畫押。

7、線上觀察與復盤

上線后 7 天持續(xù)監(jiān)控，數(shù)據(jù)落到統(tǒng)一報表：登錄成功率從 71% 提到 89%，驗證碼攔截量下降 38%，算是達到預期。

若出現(xiàn)事故，按"1-5-15"原則處理：1 分鐘發(fā)現(xiàn)、5 分鐘定位、15 分鐘恢復；

事故等級定級后，48 小時內(nèi)開復盤會，產(chǎn)出"教訓清單"，Wiki 永久留存，下次評審先檢查舊賬是否閉環(huán)。

上面7個流程是大多數(shù)稍微正規(guī)點的互聯(lián)網(wǎng)公司在開發(fā)新需求都會經(jīng)歷的七個步驟，有的可能更復雜，有的可能會精簡某些環(huán)節(jié)。

像我就知道有個互聯(lián)網(wǎng)中廠某些部門都是野路子開發(fā)，產(chǎn)品全程就一句話，啥文檔都不提供的，研發(fā)有問題只能去問，就這樣口口相傳，出問題了就相互甩鍋。

不要覺得不可思議，這個世界確實是個草臺班子哈哈。

越是正規(guī)的公司，在上線新功能的時候就越嚴謹。需求不是簡單"寫代碼"，而是把"一個想法"拆成可驗證、可回滾、可量化的七步流水線，每步都有門禁和責任人；

流程是速度的朋友，不是敵人—它讓幾百人能在同一節(jié)奏里快跑而不翻車。

來源 | 拓跋阿秀（ID：coder_Axiu）

作者 | 阿秀 ; 編輯 | 呼呼大睡

內(nèi)容僅代表作者獨立觀點，不代表早讀課立場