yupi-translate-app[bot]
14 KiB
企業專案開發流程
揭秘大廠專案是如何誕生的
你好，我是魚皮。
在前面的文章中，我們學習了 Vibe Coding 的專案開發流程，也實戰了很多個人專案。這些專案大多是自己一個人完成的，從需求到設計到開發到上線，全程自己掌控。
但你可能會好奇：企業中做專案是怎樣的流程？尤其是大廠那些百萬用戶的專案，和自己學程式設計時做專案到底有什麼區別呢？
實話說，區別可大了！自己開發專案那是單打獨鬥，自己掌握命運，不會拖垮隊友。但企業中開發專案是開團打本，大家是一根繩上的螞蚱，每個人都會影響整個專案。
我自己光大學的時候就在幾家公司實習過，不得不說，大廠和其他公司的研發流程也有很大的區別。對於大多數同學來說，如果沒有在大廠工作過，對很多研發環節可能都是一無所知的。
所以這篇文章就來揭秘一下大廠的專案研發流程，幫大家開拓思路。即使你現在用 Vibe Coding 做個人專案，了解企業的開發流程也能讓你的專案更加規範和專業。而且，如果你將來想進入大廠工作，提前了解這些流程會讓你更有競爭力。
如果你想更直觀地了解大廠專案開發流程，強烈推薦觀看我的視頻：一線大廠專案是怎麼做出來的，結合視頻和本文一起學習，效果更好。
研發流程全景圖
為了規範團隊、保證專案的進展，大廠研發流程一般還是比較複雜的。可以分為很多個階段，用一張思維導圖來概括：
需要注意的是，以上階段並不是完全按從上到下的順序執行，階段間可能存在交叉，比如 技術選型 其實在 設計階段 就應該考慮。
正式工作一年多，我也是經歷過多次專案的完整研發流程的。下面就以我的視角，帶大家快速過一遍~
（為了內容更有趣，以下故事有虛構成分）
需求階段
今天是周一，魚皮像往常一樣騎著他的小電動車來到公司，殊不知，等待他的是一場噩夢的開始。
需求產生
上午十點，產品妹子找到魚皮，告訴他：咱們的系統上線後，用戶表示很多功能並不好用，需要大改。
老闆也找到魚皮，告訴他：我今天打開頁面竟然加載了十幾秒，咱們這個系統的性能太爛了吧！
魚皮心想：嘔豁，完蛋！估計得做個新的專案了，又要開會了。
果然，沒過多久，屏幕上彈出了一條 “歡迎加入會議” 的邀請。
需求評審
第二天上午，老闆、產品、測試、幾位開發大哥和魚皮一起來到會議室，具體討論昨天提到的那些需求 是否合理、要不要做？
產品妹子打開文檔，說到：這一期呢，我們要做這幾個需求，下面我來詳細講一下，大家一起評估下有沒有問題。
需求分析
接下來，產品妹子正在對著屏幕侃侃而談、瘋狂輸出時，旁邊的開發大哥坐不住了。
開發大哥：這個需求不合理啊！
產品：為啥不合理？用戶就是有這個需求啊！
開發大哥：我知道，實現不了啊！
於是開始了經典的產品開發撕逼大戰。。。
而魚皮正躲在角落冷靜分析 這個需求怎麼做，過了一會兒，提出了一種改動低、實現快的解決方案，平息了這場戰爭。
在 AI 時代，我們還可以用 AI 工具（如 ChatGPT、Cursor）來輔助分析需求，快速生成多種技術方案進行對比，大大提升需求分析的效率。
排期
確定需求合理、可實現之後，產品妹子問到：那這個需求啥時候能上線呀？
開發大哥：我這周忙，下周吧。
產品：用戶可能比較著急，這周就要呢！
開發大哥：我知道，做不完啊！
於是開始了經典的產品開發撕逼大戰。。。
魚皮：要不我們把這個需求拆解為功能 A 和功能 B，這周我先把功能 A 做了，功能 B 排到下周二測試，下周四上線？
就這樣，我們一個個安排了需求的計劃完成日期。
設計階段
終於開完會了，看了下時間，都該下班了！
唉，需求討論完了，產品的工作是完成了一些，可魚皮的工作才剛剛開始。
急著開始寫代碼麼？
不，想好怎麼寫代碼比寫代碼更重要。
架構設計
魚皮打開寫文檔軟件和畫圖軟件，開始梳理整個系統，從整體到局部，依次設計出系統的層次結構、各層間交互的接口和通訊方式、每層之間包含哪些重要模塊、模塊選擇何種物理部署方式等。
現在有了 AI 工具的加持，我們可以用 AI 輔助生成架構圖、分析架構方案的優缺點，甚至讓 AI 幫我們做技術調研，大大提升設計效率。建議觀看魚皮分享的 AI 畫圖保姆級指南和技巧分享視頻。
概要設計
寫完架構設計後，魚皮開始對著產品妹子寫的 PRD（產品需求文檔），分析需求，然後依然是從整體到局部，先整理出系統需要的功能模塊，再分析每個功能模塊內有哪些子模塊。
和抽象的架構設計相比，概要設計和需求的關係更緊密，是對架構設計的細化。
打個比方大家就明白了，你要蓋一棟樓，架構設計就是從整體來考慮，總共有幾層、每層管道怎麼接、每層有幾戶、地基怎麼打等；而概要設計就是考慮每戶套件的內部怎麼劃分，哪裡是客廳、哪裡是衛生間。
很多情況下，概要設計和架構設計可能會在一個文檔中進行，劃分並不明確。
詳細設計
想好系統有哪些功能後，魚皮就開始具體分析每個功能如何實現，用到哪些算法、需要注重哪些細節等。
方案對齊
寫好設計文檔後，下次會議上，魚皮和其他的開發同學（前端、後端等）一起針對自己設計的方案展開討論，最終產生一個統一的方案，然後大家分工去做就好了。
測試用例設計
為了保證系統功能的正常穩定，測試同學（或者叫 QA）是非常重要的。關於軟件測試的詳細學習，可以查看 軟件測試學習路線。測試不是像我們自己做專案一樣對著網頁點幾下就 ok 了。
在大公司中，為了保證測試的覆蓋度、提高測試效率，一般是要設計測試用例的，比如：用戶點擊 “登錄”，未傳任何數據，期望結果是警告用戶輸入用戶名和密碼。
測試用例設計完後，需要其他同學一起來評審把關，而不是只交給測試同學。因為一個人很容易忽略掉很多測試細節，最好讓更熟悉代碼的開發同學一起幫忙補充。
魚皮自己也寫了幾個測試可能會遺漏的用例，和測試同學一起進行了確認，盡量讓問題暴露在測試階段而不是線上。
研發準備
寫了快一周的設計文檔，終於準備開始動手搭建專案了。但在此之前，還有一些準備工作要進行。
技術預研
如今技術發展太快，新技術層出不窮，所以魚皮首先對專案中需要或可能需要用到的技術進行了調研。
在 AI 時代，技術調研變得更加高效。我們可以用 AI 工具快速了解新技術、對比不同方案，甚至讓 AI 幫我們生成技術選型報告。
技術選型
通過調研，魚皮得到了幾個可以滿足需求的技術，但他開始糾結：這麼多技術，我該用哪一個呢？是用 SSM 框架還是 Spring Boot 呢？用 Guava 包還是 Apache Commons 呢？
魚皮又打開了寫文檔軟件，開始對比不同技術的優劣，頭疼啊，技術選型要考量的因素太多了，比如：
- 單從技術考慮：性能、易用性、穩定性、主流程度和生態、文檔詳細度
- 結合團隊：團隊成員對技術的熟悉度、掌控度（有無精通該技術的人）
- 結合業務：是否適應業務的量級（單機 or 微服務）、是否適應業務（讀多、寫多 or 分析多）
對於關鍵的專案，魚皮自己還不敢完全確定選型，因此在寫好自己的選型文檔後，和同事和 Leader 一起討論，才最終確認。
資源申請
確認好技術後，就要申請資源。比如魚皮用到了 MySQL 數據庫，但是這個 MySQL 從哪兒來呢？
以前的話，魚皮都是去買一台雲服務器，自己搭建 MySQL。但是在企業中，一般是有集中管理和分配資源的平台，直接到平台填寫預算、等領導審批、然後等著下發資源就好了。千萬不能私自用自己的或買外部的服務器來部署專案，不安全！
魚皮這次直接申請到了 2 萬多一年的雲數據庫，真的是爽死了。
環境準備
申請好數據庫等資源後，魚皮按照申請機器的版本搭建了一模一樣的本地開發環境和測試環境，後面就可以直接連接了。
專案初始化
環境準備妥當後，由於是新專案，魚皮要搞一個最小可運行的初始化專案 Demo，使用 腳手架 自動生成代碼，而不是從零開始一個個新建文件、手敲重複代碼。
現在還有更智能的方式：使用 AI 工具（如 Cursor、GitHub Copilot）來輔助初始化專案、生成模板代碼，大大節省時間。
依賴安裝
生成了專案代碼後，魚皮使用包管理工具（前端 yarn/npm、Java Maven / Gradle 等）自動安裝依賴，然後專案 Demo 就可以運行啦！
研發階段
前期準備完成後，這才到了程式員朋友們最熟悉的寫代碼環節，也是魚皮最愛的環節。
因為之前設計方案時需要保持冷靜、仔細思考，沒法邊聽歌兒邊做；而方案設計好後，已經明確了該怎麼做，寫代碼實現就很簡單了，頂多是遇到一些坑，上網搜索去解決就好了。
本地開發
開發時，一般魚皮會先在本地寫代碼，通過配置熱更新工具，實現代碼更新時自動重新編譯打包，而不用手動重啟專案，大大提高了開發效率。
對了，企業開發都會使用版本控制系統的，比如 Git，開發前記得先創建一個自己的分支，在這個分支上開發。
遠程開發
現在還有一種比較流行的遠程開發方式，就是可以像編輯本地文件一樣編輯遠程文件，直接修改服務器上的代碼。一般我們每位研發同學是有自己的開發機的，通過遠程開發就省去了反覆部署調試的麻煩，提高效率。一般用 VSCode 等開發工具，安裝遠程開發插件就可以實現了。魚皮之前分享過一個簡單的 VSCode 遠程開發實操視頻，可以看一下。
AI 輔助開發
在 2025 年，AI 輔助開發已經成為主流。魚皮現在寫代碼時經常使用 Cursor、GitHub Copilot 等 AI 工具，它們能夠：
- 自動補全代碼，提升編碼效率
- 生成單元測試，保證代碼質量
- 解釋複雜代碼，幫助理解
- 發現潛在 Bug，提前預警
- 重構優化代碼，提升可維護性
推薦大家使用 AI 資源大全 中的工具，提升開發效率。
代碼優化
魚皮在寫代碼的時候，始終保持主動優化代碼的好習慣，注重代碼的時空複雜度；並且當重複代碼多了，會想辦法抽象成函數或者使用設計模式。之前專門寫文章分享過我的編程習慣：我寫代碼時的小倔強。
單元測試
注意！不要聽到測試就以為是測試同學的工作，開發同學也同樣需要編寫小粒度的測試來為自己的代碼負責。
魚皮一般會為每個數據庫讀寫函數和業務邏輯函數編寫單元測試，像 Java 的話一般用 JUnit 等工具，還可以用 Jacoco 生成測試覆蓋度報告。每次修改關鍵代碼後，都要執行一遍單元測試，防止意外錯誤。
現在還可以用 AI 工具自動生成單元測試代碼，省去很多重複勞動。
開發聯調
魚皮終於寫好了後端代碼，也自測完成了，下面就是把寫好的代碼打包構建，然後把可執行專案包發布到測試服務器上，和前端同學一起聯調，讓他請求我的接口，驗證系統的功能是否可用。
測試驗證
魚皮和前端聯調完畢後，告知了測試和產品同學。
測試驗證是企業中至關重要的環節，甚至可以說是最後一道防線。測試的目的是找 Bug，盡量發現系統中的問題，把它們扼殺在測試階段。
在企業中，測試驗證又有很多類型。
集成測試
集成測試比單元測試粒度更大，是把多個模塊或代碼單元放在一起，驗證模塊之間的集成和調用關係。
因為單個函數的執行可能是正常的，但把多個函數組合在一起順序調用，可能就會出現問題。
打個比方，我們有個吃麵包系統：
功能 A：小魚吃一個麵包
功能 B：小皮吃一個麵包
每次只有一個麵包，獨立執行功能 A 和 B 都是允許的。但如果兩個一起執行，後執行的那個功能就會報錯。
系統測試
系統測試比集成測試的粒度更大，測試對象是整個系統，不僅包括軟件，還可能覆蓋對硬件的測試。
產品體驗
除了測試同學要驗證系統可用性，產品妹子也要體驗下功能是否符合預期、是否易用。大多數情況下，產品會在體驗時提出修改建議，開發可能還要去