拜託，大廠作項目可不簡單！

揭祕一線大廠研發流程

你們好，我是魚皮。

不少未工做過的小夥伴都很好奇：企業中作項目是怎樣的流程？尤爲是大廠那些百萬用戶的項目，和本身學編程時作項目到底有什麼區別呢？

實話說，區別可大了！

本身開發項目那是單打獨鬥，本身掌握命運，不會拖垮隊友；但企業中開發項目是開團打本，你們是一根繩上的螞蚱，每一個人都會影響整個項目。

我本身也在幾家公司實習過，不得不說，大廠和其餘公司的研發流程也有很大的區別。

所以，對於大多數同窗，若是沒有在大廠工做過，對不少研發環節可能都是一無所知的。

因此今天給你們揭祕一下大廠的項目研發流程，幫你們開拓思路。

正好以前有同志質疑個人平常工做就只有寫代碼和摸魚？！這篇文章就做爲回擊，讓他明白，在大廠作項目，可不止寫代碼那麼簡單！

大廠研發流程揭祕

爲了規範團隊、保證項目的進展，大廠研發流程一般仍是比較複雜的。

能夠分爲不少個階段，用一張思惟導圖來歸納：

須要注意的是，以上階段並非徹底按從上到下的順序執行，階段間可能存在交叉，好比 技術選型 其實在 設計階段 就應該考慮。

正式工做一年多，我也是經歷過屢次項目的完整研發流程的。下面就以個人視角，帶你們快速過一遍~

（爲了內容更有趣，如下故事有虛構成分）

需求階段

今天是週一，魚皮像往常同樣騎着他的小電動車來到公司，卻不知，等待他的是一場噩夢的開始。

需求產生

上午十點，產品妹子找到魚皮，告訴他：我們的系統上線後，用戶表示不少功能並很差用，須要大改。

老闆也找到魚皮，告訴他：我今天打開頁面居然加載了十幾秒，我們這個系統的性能太爛了吧！

魚皮心想：嘔豁，完蛋！估計得作個新的項目了，又要開會了。

果真，沒過多久，屏幕上彈出了一條 「歡迎加入會議」 的邀請。

需求評審

次日上午，老闆、產品、測試、幾位開發大哥和魚皮一塊兒來到會議室，具體討論昨天提到的那些需求 是否合理、要不要作 ？

產品妹子打開文檔，說到：這一期呢，咱們要作這幾個需求，下面我來詳細講一下，你們一塊兒評估下有沒有問題。

需求分析

接下來，產品妹子正在對着屏幕侃侃而談、瘋狂輸出時，旁邊的開發大哥坐不住了。

開發大哥：這個需求不合理啊！

產品：爲啥不合理？用戶就是有這個需求啊！

開發大哥：我知道，實現不了啊！

因而開始了經典的產品開發撕逼大戰。。。

而魚皮正躲在角落冷靜分析 這個需求怎麼作 ，過了一下子，提出了一種改動低、實現快的解決方案，平息了這場戰爭。

排期

肯定需求合理、可實現以後，產品妹子問到：那這個需求啥時候能上線呀？

開發大哥：我這周忙，下週吧。

產品：用戶可能比較着急，這周就要呢！

開發大哥：我知道，作不完啊！

因而開始了經典的產品開發撕逼大戰。。。

魚皮：要不咱們把這個需求拆解爲功能 A 和功能 B，這周我先把功能 A 作了，功能 B 排到下週二測試，下週四上線？

就這樣，咱們一個個安排了需求的計劃完成日期。

設計階段

終於開完會了，看了下時間，都該下班了！

唉，需求討論完了，產品的工做是完成了一些，可魚皮的工做纔剛剛開始。

急着開始寫代碼麼？

不，想好怎麼寫代碼比寫代碼更重要。

架構設計

魚皮打開寫文檔軟件和畫圖軟件，開始梳理整個系統，從總體到局部，依次設計出系統的層次結構、各層間交互的接口和通信方式、每層之間包含哪些重要模塊、模塊選擇何種物理部署方式等。

概要設計

寫完架構設計後，魚皮開始對着產品妹子寫的 PRD（產品需求文檔），分析需求，而後依然是從總體到局部，先整理出系統須要的功能模塊，再分析每一個功能模塊內有哪些子模塊。

和抽象的架構設計相比，概要設計和需求的關係更緊密，是對架構設計的細化。

打個比方你們就明白了，你要蓋一棟樓，架構設計就是從總體來考慮，總共有幾層、每層管道怎麼接、每層有幾戶、地基怎麼打等；而概要設計就是考慮每戶套件的內部怎麼劃分，哪裏是客廳、哪裏是衛生間。

不少狀況下，概要設計和架構設計可能會在一個文檔中進行，劃分並不明確。

詳細設計

想好系統有哪些功能後，魚皮就開始具體分析每一個功能如何實現，用到哪些算法、須要注重哪些細節等。

方案對齊

寫好設計文檔後，下次會議上，魚皮和其餘的開發同窗（前端、後端等）一塊兒針對本身設計的方案展開討論，最終產生一個統一的方案，而後你們分工去作就行了。

測試用例設計

爲了保證系統功能的正常穩定，測試同窗（或者叫 QA）是很是重要的，測試不是像咱們本身作項目同樣對着網頁點幾下就 ok 了。

在大公司中，爲了保證測試的覆蓋度、提升測試效率，通常是要設計測試用例的，好比：用戶點擊 「登陸」，未傳任何數據，指望結果是警告用戶輸入用戶名和密碼。

測試用例設計完後，須要其餘同窗一塊兒來評審把關，而不是隻交給測試同窗。由於一我的很容易忽略掉不少測試細節，最好讓更熟悉代碼的開發同窗一塊兒幫忙補充。

魚皮本身也寫了幾個測試可能會遺漏的用例，和測試同窗一塊兒進行了確認，儘可能讓問題暴露在測試階段而不是線上。

研發準備

寫了快一週的設計文檔，終於準備開始動手搭建項目了。但在此以前，還有一些準備工做要進行。

技術預研

現在技術發展太快，新技術層出不窮，因此魚皮首先對項目中須要或可能須要用到的技術進行了調研。

技術選型

經過調研，魚皮獲得了幾個能夠知足需求的技術，但他開始糾結：這麼多技術，我該用哪個呢？是用 SSM 框架仍是 Play 框架呢？用 guava 包仍是 Apache Commons 呢？

魚皮又打開了寫文檔軟件，開始對比不一樣技術的優劣，頭疼啊，技術選型要考量的因素太多了，好比：

• 單從技術考慮：性能、易用性、穩定性、主流程度和生態、文檔詳細度
• 結合團隊：團隊成員對技術的熟悉度、掌控度（有無精通該技術的人）
• 結合業務：是否適應業務的量級（單機 or 微服務）、是否適應業務（讀多、寫多 or 分析多）

對於關鍵的項目，魚皮本身還不敢徹底肯定選型，所以在寫好本身的選型文檔後，與同事和 Leader 一塊兒討論，才最終確認。

資源申請

確認好技術後，就要申請資源。好比魚皮用到了 MySQL 數據庫，可是這個 MySQL 從哪兒來呢？

之前的話，魚皮都是去買一臺雲服務器，本身搭建 MySQL。可是在企業中，通常是有集中管理和分配資源的平臺的，直接到平臺填寫預算、等領導審批、而後等着下發資源就行了。千萬不能私自用本身的或買外部的服務器來部署項目，不安全！

魚皮此次直接申請到了 2 萬多一年的雲數據庫，真的是爽死了。

環境準備

申請好數據庫等資源後，魚皮按照申請機器的版本搭建瞭如出一轍的本地開發環境和測試環境，後面就能夠直接鏈接了。

項目初始化

環境準備穩當後，因爲是新項目，魚皮要搞一個最小可運行的初始化項目 Demo，使用 腳手架 自動生成代碼，而不是從零開始一個個新建文件、手敲重複代碼。

依賴安裝

生成了項目代碼後，魚皮使用包管理工具（前端 yarn、Java Maven / Gradle 等）自動安裝依賴，而後項目 Demo 就能夠運行啦！

研發階段

前期準備完成後，這纔到了程序員朋友們最熟悉的寫代碼環節，也是魚皮最愛的環節。

由於以前設計方案時須要保持冷靜、仔細思考，無法邊聽歌兒邊作；而方案設計好後，已經明確了該怎麼作，寫代碼實現就很簡單了，頂可能是遇到一些坑，上網搜索去解決就行了。

本地開發

開發時，通常魚皮會先在本地寫代碼，經過配置熱更新工具，實現代碼更新時自動從新編譯打包，而不用手動重啓項目，大大提升了開發效率。

對了，企業開發都會使用版本控制系統的，好比 Git，開發前記得先建立一個本身的分支，在這個分支上開發。

遠程開發

如今還有一種比較流行的遠程開發方式，就是能夠像編輯本地文件同樣編輯遠程文件，直接修改服務器上的代碼。通常咱們每位研發同窗是有本身的開發機的，經過遠程開發就省去了反覆部署調試的麻煩，提升效率。通常用 VSCode 等開發工具，安裝遠程開發插件就能夠實現了。

代碼優化

魚皮在寫代碼的時候，始終保持主動優化代碼的好習慣，注重代碼的時空複雜度；而且當重複代碼多了，會想辦法抽象成函數或者使用設計模式。以前專門寫文章分享過個人編程習慣：我寫代碼時的小倔強 。

單元測試

注意！不要聽到測試就覺得是測試同窗的工做，開發同窗也一樣須要編寫小粒度的測試來爲本身的代碼負責。

魚皮通常會爲每一個數據庫讀寫函數和業務邏輯函數編寫單元測試，像 Java 的話通常用 JUnit 等工具，還能夠用 Jacoco 生成測試覆蓋度報告。每次修改關鍵代碼後，都要執行一遍單元測試，防止意外錯誤。

開發聯調

魚皮終於寫好了後端代碼，也自測完成了，下面就是把寫好的代碼打包構建，而後把可執行項目包發佈到測試服務器上，和前端同窗一塊兒聯調，讓他請求個人接口，驗證系統的功能是否可用。

測試驗證

魚皮和前端聯調完畢後，告知了測試和產品同窗。

測試驗證是企業中相當重要的環節，甚至能夠說是最後一道防線。測試的目的是找 Bug，儘可能發現系統中的問題，把它們扼殺在測試階段。

在企業中，測試驗證又有不少類型。

集成測試

集成測試比單元測試粒度更大，是把多個模塊或代碼單元放在一塊兒，驗證模塊之間的集成和調用關係。

由於單個函數的執行多是正常的，但把多個函數組合在一塊兒順序調用，可能就會出現問題。

打個比方，咱們有個吃麪包系統：

功能 A：小魚吃一個麪包

功能 B：小皮吃一個麪包

每次只有一個麪包，獨立執行功能 A 和 B 都是容許的。但若是兩個一塊兒執行，後執行的那個功能就會報錯。

系統測試

系統測試比集成測試的粒度更大，測試對象是整個系統，不只包括軟件，還可能覆蓋對硬件的測試。

產品體驗

除了測試同窗要驗證系統可用性，產品妹子也要體驗下功能是否符合預期、是否易用。大多數狀況下，產品會在體驗時提出修改建議，開發可能還要再去作一些修改。

驗收測試

測試和產品妹子終於表示沒有問題啦，那就到了最後一步，把整個產品或功能給最終的用戶來體驗。老闆 用戶說沒問題，纔是真的沒問題！

提交階段

系統沒問題以後，魚皮就能夠把代碼發佈到遠程倉庫了，通常使用 Git 和 SVN 等版本控制系統。

代碼提交

魚皮首先在本地觸發代碼提交（git commit），爲保證規範，在大項目中通常會使用提交檢測插件，防止你把錯誤的代碼進行了提交。

代碼推送

下一步就是把本地的提交推送到遠程的同名分支。通常大廠會有推送檢測工具，檢測代碼的錯誤、圈複雜度、代碼規範等，和提交檢測同樣，防止你把錯誤或不規範的代碼進行了推送。

合併請求

代碼分支推送到遠程以後，魚皮發起了一個分支合併請求（MR），但願把該分支的代碼合併到主幹分支（沒問題的代碼）。

代碼審查

並非發起了合併請求就能直接合並，還要經過代碼審查，即 CR。

審查又分爲兩種方式：人審和機審。

相信很多同窗都知道人審，通常是由你的上級和其餘項目負責人來閱讀和評論你的代碼，以爲沒問題就 Approve（經過），不然打回去修改。

那機審是個啥呢？其實就是機器自動檢測你的代碼是否符合規範，是否可以成功自動化構建等，通常是由項目負責人配置的，能夠幫助發現一些人工難以發現的問題。

剛接觸新項目的時候，魚皮常常被機審折磨得苦不堪言，常常被提示一些莫名其妙的代碼問題，好比加號要換行，文件行末要加空行等。但後來注意編碼習慣後，就很天然地適應了，的確不錯。

發佈階段

代碼審查經過後，魚皮的項目代碼就能夠發佈上線啦。

打包構建

傳統上線方式是開發人員到正式服務器上拉取代碼，而後安裝依賴，再經過工具把代碼打包構建，獲得部署包，經過 Nginx、Tomcat、Docker 等技術運行。

但這樣效率很低，有不少重複工做。因此大廠通常是用自動化構建的，像 Jenkins、各類 CI / CD 工具等。代碼合併到主分以後，由機器把代碼打包構建爲最終的部署包。

預發佈

爲了防止上線出問題，通常咱們會先在預發佈環境部署項目，再觀察一下是否可以正常運行。

正式發佈

預發佈測試正常後，魚皮終於等到了上線的這一刻。大項目通常都會部署在多臺機器上，因此不可能一臺臺登陸機器去發佈部署包。

一般公司會提供可視化發佈平臺，點選須要發佈機器（通常先灰度，選一小部分機器，再全量發佈），點擊一鍵發佈，等項目管理員審批經過以後，就交給機器自動部署吧！

後續

魚皮曾天真地覺得項目上線以後，就能夠高枕無憂了。但後來發現，項目上線以後，一樣須要保持警覺。雖然已經測試過，但仍然時不時會出現個預期以外的小 Bug，仍是很考驗心態的。

來看看上線以後，魚皮作了哪些事呢？

監控運維

魚皮會按期查看項目的監控面板，觀察項目的運行狀況，機器的負載等。

統計分析

魚皮在代碼中添加了一些日誌，能夠利用 ELK 等日誌收集可視化平臺對這些日誌進行分析，從而感知到用戶的行爲，進一步優化業務和系統。

好比我會統計用戶執行 SQL 查詢的耗時，對重複率高的慢 SQL 進行鍼對性地優化。

事件反饋

有的時候，用戶本身都不能清楚地描述 Bug，並且歷史 Bug 也不方便找到。因此公司內部通常會有事件反饋平臺，產品等內部同窗在接收到 Bug 時，會在該平臺發佈一個 Bug 事件，詳細描述 Bug 出現的時間、情況、詳情等，便於咱們開發集中分析和處理問題。

文檔沉澱

每次上線了新功能和項目，魚皮都會經過寫文檔來記錄項目的背景、設計方案、開發過程和一些坑點，便於後續其餘同窗瞭解項目，這是很是重要的！利人利己。

曾經分享過個人寫文檔技巧：如何寫好文檔？

迭代優化

最後，一個需求的結束每每只是另外一個需求的開始。像魚皮最近在跟進的項目，一期作完作二期，二期還沒作完三期就來了；還要抽出時間去優化之前的代碼，這日子遙遙無期，沒盼頭啊！

---

以上就是本期分享，看完本文後，歡迎閱讀我以前的這篇文章：大廠機密！30 個提高團隊研發效能的錦囊 ，瞭解更多大廠技術。

最後再送你們一些 幫助我拿到大廠 offer 的學習資料：

跑了，留下 6T 的資源！

歡迎閱讀 我從 0 開始自學進入騰訊的編程學習經歷，再也不迷茫！

我學計算機的四年，共勉！

我是魚皮，點贊 仍是要求一下的，祝你們都能心想事成、發大財、行大運。