網際網路大公司那些價值上億的專案背後，團隊成員是怎麼高效協作開發的？和我自己開發辣條專案時有什麼區別？

看完本文，保證讓你大開眼界！

魚皮在學校的時候，做過很多專案，但大部分都是練手的 Demo。基本都是單兵作戰，毫無章法。

大二暑假，我第一次進入企業實習，要和同事合作開發一個大專案，對於企業中的條條框框和同事寫的爛程式碼非常不適應，整天大呼同事不講碼德！

大三來到位元組跳動實習，還是和同事一起開發一個新專案，那會兒仍然不適應團隊開發，最煩的事就是每次寫完程式碼，都要讓同事檢查幾遍，確認沒問題後還要在他的監護下才能釋出上線。

後來走出校園，來到騰訊，接觸到了更大的團隊、更大的專案，但起初我還不能很好的適應團隊開發，依舊保持個人開發時的野性，導致效率非常低。

經過在鵝廠一年多的摸爬滾打，如今的我，終於能夠熟練運用企業的各種資源來提升自己和團隊的研發效率了！

我總結了 30 個提升團隊研發效能的錦囊，完整覆蓋專案的各研發流程，分享給大家~

專案研發流程

1. 技術選型

想要提升團隊開發效率，在投入專案開發前，必須確認專案的技術選型。比如專案選用哪種程式語言、選用哪個開發框架、選用哪些依賴庫、選用哪個測試框架、選用哪種資料庫、選用哪些中介軟體等等。

技術選型是一門大學問，通常不是由一位技術大牛或架構師一錘定音的，而是要大家開會討論，結合具體的業務場景進行分析，並且對技術進行充分的研究，最後共同確認一個較為合適的選型方案。

技術選型的考量要素非常多，比如：

1. 團隊成員對技術的熟悉程度。團隊成員對技術越熟悉，培訓成本越小，開發效率越高。在一個都是 Java 工程師的團隊提出使用 C++ 簡直不講碼德！

2. 團隊對技術的掌控度。團隊內至少要有一個人非常瞭解該技術，懂得最佳實踐，能夠指導團隊正確運用技術，並解決疑難問題。

3. 技術的主流程度和生態。技術越主流，文件、實踐和解決方案就越多，而使用冷門技術可能出現無法解決的問題，整段垮掉！

4. 技術和業務的貼合程度。技術是為業務服務的，因此必須結合具體的業務場景去選用技術。比如在只有幾個使用者使用的小網站中運用微服務框架是一個愚蠢的選擇。

2. 開發工具

工欲善其事，必先利其器。

在開發前，選擇一款優秀的開發工具，並且學習如何高效地使用它吧！很多開發工具都自帶了程式碼檢查、程式碼格式化等功能，還有很多快捷鍵，這將大大提升我們的開發效率和開發體驗。

目前比較主流的開發工具有 JetBrains 全家桶、Vscode、Sublime 等等，不必沉迷於某一款開發工具無法自拔，可以針對專案的類別和體積進行選擇。

除了本地的開發工具外，還可以使用雲端的開發工具，比如 Cloud Studio，無需下載任何軟體，直接在瀏覽器中進行開發和除錯、實時瀏覽。對於小型專案的開發也許是一個不錯的選擇。

Cloud Studio 線上開發

3. 程式碼規範

在開發前，為團隊或專案制定一套程式碼規範太有必要了。

好的程式碼規範能夠幫助團隊成員閱讀理解他人的程式碼，提升協作開發效率和團隊氛圍。

試想，如果你習慣程式碼縮排兩格，而其他同學都縮排四格，會不會感到很懊惱？

4. 腳手架

在開發一個新專案前，通常由架構師或熟悉技術框架的同學來搭建專案的基本結構、編寫 Demo，其他同學只需要在此基礎上遵循規範進行開發（複製貼上）就好。

如今，專案結構越來越複雜，我們不可能手動建立一個又一個檔案。

懶人推動世界，很多框架自帶了腳手架，能夠讓我們通過輸入一兩行命令，快速生成專案的基本結構、預設配置檔案、甚至是可直接執行的 Demo，避免了不必要的重複工作，大大提升開發效率！

比如前端框架 Vue 的腳手架 Vue Cli 和前端框架 React 的腳手架 Create React App。

腳手架演示

5. 低程式碼構建

低程式碼是指少寫程式碼或不寫程式碼。通過對應用場景的極致抽象和模板化，將寫程式碼的工作交給機器來自動生成。

就像現在網上很多 App 和網站製作平臺，只需要在介面上選擇元素、點點拖拖，就能夠自動創建出應用，根本不需要寫任何程式碼，哪怕是不會程式設計的人也能輕鬆使用。

低程式碼構建在企業中非常流行，是提升團隊開發效率的神器，幾乎每個大公司都有自己的低程式碼構建平臺。業界比較知名的低程式碼平臺有 Google 的 App Maker 和微軟的 Power Apps 等。

Power Apps 畫布的影象

6. 內部依賴倉庫

在開發中，我們經常需要下載大量的依賴包，還要將開發好的依賴包進行上傳。

但是，通常軟體依賴源都是國外的伺服器，比如 Maven 和 npm 源，從國內下載依賴的速度非常慢。雖然下載慢的問題可以通過配置國內映象源得到一定程度的解決，但是無法直接在公有軟體源上傳私有包。

因此，通常企業都會在內網搭建私有軟體源，即內部依賴倉庫，便於內部依賴管理，大大提升拉取效率。

目前最常用的內部依賴倉庫是 Nexus。

Nexus 倉庫

7. 本地開發熱更新

很多年前，在我還有一雙清澈的雙眼的時候，我在本地開發網站都是改一行程式碼，然後切換到瀏覽器裡重新整理看效果，然後再改程式碼，再重新整理，如此往復，非常難受。尤其是開發後臺應用時，哪怕在程式碼中改了一個字母，都要去重啟專案！

現在想想，效率實在是太低了。

如今，本地開發熱更新是程式設計師開發提效必備的神器，啟動一個開發伺服器，讓它自動監聽程式碼檔案。當代碼更新時，執行中的專案也會自動更新，從而省去了無止盡的重新整理和重啟。

在前端，比較知名的熱更新工具有基於 HMR 技術（模組熱替換 hot module replacement）的 Webpack Dev Server；在 Java 後端有 熱部署外掛 JRebel。

JRebel 簡化流程

8. Serverless

Serverless 是最近幾年逐漸流行的概念，翻譯過來就是 “無伺服器”。

以前，我們要搭建網站的後臺，首先要買伺服器，然後將一個大而全的專案包部署到伺服器上，整體對外提供服務，所有的系統資源和程序都需要由我們自己來管理。

單體架構

隨著雲端計算時代虛擬化、容器、微服務等技術的發展，人們將大專案的通用部分抽象成一個個細小的服務，每個服務只提供一個或幾個功能，獨立部署在比伺服器更輕量且無狀態的容器中，共同對外提供服務，組成一個完整的系統。

Serverless 架構

而 Serverless 不是指完全不需要伺服器，而是讓開發者感受不到伺服器的存在。

什麼意思呢？其實就是把對伺服器的需求外包給廠商，我們只管寫程式碼，讓他們負責部署和運維。我們花錢，他們辦事！

目前國內有很多 Serverless 服務提供商，如阿里雲、騰訊雲、LeanCloud 等，使用這些 Serverless 服務後，我們無需再關心伺服器的執行，只需要專心寫業務邏輯就可以了，能夠大大提升開發和維護效率，省時省心。

9. 程式碼託管

很多年前，我們的程式碼幾乎都存在自己的電腦裡，通過 U 盤或者網路傳輸程式碼檔案來實現合作開發。

而如今，程式碼託管平臺已經成為團隊合作開發的靈魂。

相信很多小夥伴都接觸過 GitHub，世界上最大的程式碼開源託管平臺。每個人都可以把自己的程式碼釋出到 GitHub 上，作為一個程式碼倉庫，隨時隨地遠端管理。還可以搜尋和瀏覽其他人釋出的程式碼倉庫，以此實現高效地合作開發，促進專案的完善。

為了保證程式碼的安全保密性，一般在公司或團隊內部都會自己搭建一個程式碼託管平臺，比較知名的有 GitLab，可以針對不同的專案為成員分配許可權，更好地管理團隊的程式碼。

GitLab

10. 原生代碼檢查

在程式碼提交之前，首先應該在本地進行程式碼檢查，及時發現一些低階的語法錯誤，防止被團隊的其他同學嘲笑。

大多數整合開發工具自帶了程式碼檢查功能，邊敲程式碼邊檢查，非常爽。

此外，我們還可以配置 Git Hooks，在程式碼提交前自動執行程式碼檢查，npm 專案可以通過 Husky 外掛實現，還能配合 ESLint 實現程式碼自動修復。

ESLint

11. 程式碼提交規範

團隊越大，規範就越重要。

只有程式碼編寫規範還不夠，還要在團隊內製定一套程式碼提交規範，通常是約定式提交規範，即讓成員在提交程式碼時填寫指定格式的 Commit Message，比如下面的格式：

<提交型別>[可選的作用域]:<描述>

[可選的正文]

[可選的腳註]

指定程式碼提交規範不僅能夠幫助成員快速理解每次提交的改動點，提升程式碼審查效率；更大的作用是讓一些自動化工具理解提交資訊以進行一些有意義的工作，比如生成 Change Log（程式碼改變日誌）。

可以參考一些大公司的程式碼提交規範，並通過 commitlint 和 commitizen 等外掛實現自動修復不規範程式碼。

commitlint 程式碼提交規範檢查

12. 程式碼審查

在團隊開發中，寫程式碼可不能像自己練習程式設計時一樣肆無忌憚。

在合作開發時，可以為每位開發者分配一個分支，在自己的分支編寫和提交程式碼，也可以按照需求來建立分支。確認開發測試完成後，發起一個 MR（Merge Request 合併請求），將小分支的程式碼合併到公共的主線分支即可。

分支合併

主線分支的程式碼通常是能夠直接釋出上線、穩定執行的。因此，為了保證專案程式碼的質量，每次合併程式碼到主線分支前，必須要進行程式碼審查（CR，即 Code Review），就是讓同事或上級閱讀和審批你的程式碼，覺得沒有問題後，才能夠執行程式碼合併。

通常，程式碼變更越大、專案越重要，程式碼審查所需人數越多，越能夠發現一些個人無法發現的風險和問題。因此，程式碼審查是大公司研發流程的關鍵一環和重要防線。雖然不能直接提升研發效能，但是能有效避免線上事故的發生，減少程式設計師不必要的工作量和心理壓力。

程式碼審查

13. CI/CD 流水線

CI/CD 即持續整合/持續交付。

在敏捷開發時代，哪怕是一個小團隊，每天也會有幾次的程式碼提交，如果長期不合並，可能就會出現程式碼衝突。

程式碼衝突

因此，持續整合的意義在於，通過每天定時將各個開發人員的程式碼合併到同一個程式碼倉庫中，以儘早發現程式碼衝突和錯誤，幫助團隊更緊密地開發協作。

當我們開發完專案，想要釋出上線時，要先登入伺服器，然後在伺服器上拉取程式碼倉庫中的專案程式碼，然後執行打包命令，最後通過指令碼執行專案。

如果只需要在一臺伺服器上部署，其實還不算太麻煩，但是如果要在幾十臺機器上部署呢？要一臺一臺地登入伺服器然後重複著上述工作麼？

懶人推動世界，這時我們就需要持續交付，將構建部署的每個步驟由人工轉變為機器自動操作，原理類似編寫了一個自動化構建指令碼，在程式碼合併到倉庫時觸發指令碼的執行，在各機器上自動拉取新程式碼並打包釋出。

目前主流的 CI/CD 平臺是 Jenkins 老爺爺，可以配合程式碼託管平臺 GitLab 等實現完全自動化打包、構建、釋出，再也不用開發人員一臺臺登入機器去執行重複的命令了，不僅大大提升了團隊研發效率，還保證了釋出流程的規範和安全性。

Jenkins 爺爺

畢竟總有些內鬼程式設計師藉著釋出的名義偷偷登入伺服器執行 rm -rf *。

14. 監控告警

為了在第一時間發現線上專案存在的問題，我們通常會在程式碼中新增告警邏輯，當某段程式碼執行異常時通過郵件、簡訊、微信、電話等方式聯絡專案負責人。

但有時，我們可能會針對某些指標在一段時間內的統計值設定告警。比如當機器記憶體佔用超過 80% 且持續 5 分鐘才告警。這些告警邏輯和業務本身關係不大，如果都寫死在程式碼裡，不僅耗時，而且難以維護。

可以在團隊內搭建監控告警平臺，通過在機器上部署代理或者在程式碼中使用上報 SDK 等方式來讓告警平臺統一收集專案執行時的各個指標，比如機器負載、網路負載、異常資訊等。

監控告警平臺提供配置介面，可以靈活地配置告警規則，比如 1 分鐘內收集到 2 個報錯就發郵件告警、收集到 5 個報錯就發簡訊等。

完善的監控告警平臺還能夠對歷史告警資訊進行管理和詳情檢視，以及視覺化展示各指標圖表等。不僅減少了我們開發時的工作量，也能幫助我們更快地分析和排錯。

Zabbix 是比較知名的開源監控解決方案，幾乎能對任何 IT 基礎架構、服務、應用程式和資源進行監控和告警，全面且專業。

Zabbix 監控

15. 日誌平臺

通常，已上線的專案出現問題時，我們會通過檢視日誌檔案來定位和排查問題。

如果專案比較小，僅僅在單臺伺服器上部署，那麼只需要登入這臺伺服器，輸入命令來檢視日誌即可。

但團隊的專案量級較大時，通常會部署到多臺機器上，而且每臺機器上的日誌量都非常大，以人工的方式一臺臺登入伺服器，然後在數以萬計的日誌中去找到自己想要的關鍵資訊，是非常低效又噁心的！

雜亂的日誌

日誌不講武德，可以搭建一個統一的日誌平臺來治治它們。將各臺機器上分散的日誌收集到日誌平臺，然後通過視覺化的介面去集中管理和搜尋日誌，大大提升了查閱日誌的效率和體驗。

目前比較主流的技術是 Elastic Stack（Elasticsearch + Logstash + Kibana + Filebeat） ，使用它可以搭建一套企業級日誌平臺，輕鬆管理上百萬甚至是上億的日誌資料。

Kibana 日誌視覺化

16. 介面文件平臺

現在很多的專案都採用前後端分離的方式進行開發，前端同學寫介面，後端同學提供介面。如果沒有一個規範的介面文件，宣告每個介面的協議、請求引數、響應引數等，很容易導致前端請求錯誤。

傳統的方式是由後端同學手動編寫介面文件，介面改動時，文件也要改動，非常低效且不利維護。

其實，我們可以將介面文件平臺化，通過 Swagger 等工具自動生成精美的介面文件網站，開發者還可以在網站上直接測試各個請求，告別了手動編寫文件的低效繁瑣，提升了開發和協作效率。

Swagger 介面文件

17. 介面測試平臺

測試是對研發質量的保障。

我們寫完程式碼後，不僅要在本地測試，還要在測試環境、預釋出環境、線上環境都進行測試驗證。專案越大，對測試的要求越高，也就越麻煩。

通常我們會使用 Curl、Postman 等工具進行介面測試，簡單易用。但是有些時候，本地網路（公網）和測試環境（內網）的網路不互通怎麼辦？

可以在團隊內部搭建介面測試平臺。提供一個 web 介面，無需下載任何軟體，就可以輕鬆地建立各種介面測試，編寫各種測試用例，建立測試計劃。最棒的是還能切換不同的測試環境，以及多人共享測試等等。大大提高了測試效率和質量。

18. 即時協作

天下武功，無快不破。為追求更高的協作效率，可以使用一些即時協作工具。

比如在協作開發同一個專案時，可以使用開發工具 Vscode 的 VS Live Share 外掛，支援多人連線，團隊成員可以同時對檔案進行編輯，甚至還能看到對方的游標！

Live Sharing with VS Code

在多人編寫同一個文件或表格時，可以使用騰訊文件，實時看到其他成員的游標位置和對文件的改動，尤其是在開會時，這個功能將非常有用。

騰訊文件

使用即時協作平臺不僅可以提升效率，還能以最快的速度發現衝突，發現有人正在寫爛程式碼可以直接打字提示他。

19. 團隊知識庫

團隊在開發專案的過程中，肯定會產生很多有用的知識，比如技術選型過程、線上事故的分析處理過程、技術文件、產品文件、業務介紹等。這些知識是團隊成員共同積累的財富，日後可能要給其他同學閱讀學習，因此必須妥善儲存。

以前的做法是，大家把想共享的檔案傳到一個公共的網盤中，需要時下載到自己的電腦上。當網盤的檔案更新時，還要再重複下載，非常地低效。

現在的專案團隊，一般都有自己的團隊知識庫，通常是雲端網站的形式，所有的成員可以在知識庫中上傳想要儲存和分享的文件，也可以直接在知識庫中編寫文件。想要學習知識的同學直接登入知識庫網站，搜尋文件即可，還能夠對優秀的文件進行收藏。

團隊知識庫不僅能夠更好地維護和沉澱團隊的知識，還能提升大家編寫和閱讀文件的效率，更好地進行知識協作共享。

比較不錯的在線團隊知識庫有阿里語雀、騰訊樂享、Wiki、Confluence 等。

語雀知識庫

20. 程序監控

有時，我們線上執行的專案程序可能因為某些意外而退出，而且沒有被任何人及時發現，這可能會對團隊造成巨大的損失。

為了保證線上專案的高可用，可以開啟程序監控，當專案程序退出時，自動重啟該程序並且向負責人傳送告警，一定程度上減少了事故的影響，也省去了手動重啟程序的操作。

可以自己編寫程序監控指令碼，也可以使用一些現成的監控程式，比如 Supervisor 和 Monit 等。

Monit 監控

21. 前端監控統計

前端監控主要包括對頁面的效能監控、錯誤監控和使用者行為監控。對於 C 端專案而言，前端監控非常重要。通過效能監控，可以分析頁面效能的不足，優化頁面，提升使用者體驗。通過錯誤監控，可以在使用者進行某些誤操作時第一時間通知到專案負責人，並進行相應的處理。通過行為監控，可以獲取 UV、PV、IP、點選流等等，從而分析使用者的使用習慣，改進產品。

如果沒有前端監控平臺，開發者要自己收集各使用者行為指標，且只能通過不斷地測試來分析頁面效能的不足，會產生很多額外的工作量。

有很多現成的前端監控平臺，比如百度統計、專注錯誤監控的 Sentry、騰訊的 Aegis 等，直接申請賬號接入即可，省去了自己搭建的麻煩。

百度統計

22. 任務排程平臺

在日常開發中，少不了執行定時任務，比如每天檢測資料是否正常、定時傳送郵件、同步資料等。如果把這些任務都寫死在程式碼中去執行，即使用一些定時任務框架，當任務多了，也會變得難以管理。而且無法控制任務的執行狀態，還有可能導致一些單次任務的重複執行，造成風險！

因此，需要統一的任務排程平臺來管理任務。可以通過平臺介面實時檢視各任務的執行情況，還能夠靈活地控制任務的啟停、執行引數、超時時間等。甚至可以將任務排程到多臺機器同時執行。降低風險的同時提升了管理定時任務的效率。

有一些優秀的開源任務排程平臺如 Elastic Job 和 XXL-JOB，可以直接搭建使用。

XXL 任務排程平臺

23. 配置中心

任何專案都離不開配置，比如資料庫連線密碼、第三方服務呼叫地址等。

如果把配置都寫死在程式碼中，或者是專案包裡的配置檔案中，當配置需要修改時，我們就不得不修改專案檔案，提交程式碼，重新打包，再發布上線，非常麻煩。

而且有些時候，由於多個專案使用了相同的配置，在改動一行配置時，可能要去修改多個專案，不僅麻煩，而且存在漏改的風險。

因此，我們需要一個配置中心來集中管理那些經常變化的、同時被多個專案使用的配置。

比較好用的配置中心有攜程的 Apollo、阿里的 Nacos 等，可以直接在介面上建立和釋出配置，還能對配置進行版本控制，靈活地升級和回退。使用配置中心能夠提升配置管理的效率，同時避免重複地改動專案的配置檔案。

攜程 Apollo 配置中心

24. 鏈路追蹤

假設我們的專案中有一個功能依賴多個第三方介面，該功能的平均執行時間是 50ms。

/**
*獲取使用者詳情（依賴三個介面）
*/
functiongetUserDetail(){
letuser=getUserById();//得到使用者基本資訊10ms
user.account=getUserAccount();//得到賬戶資訊20ms
user.idcard=getUserIdCard();//得到使用者身份證資訊20ms
returnuser;
}

結果有一天，這個功能執行超過了 10 分鐘！那怎麼排查出是哪個第三方接口出現了問題呢？

當出現複雜的呼叫關係時，我們可以使用鏈路追蹤系統，通過給每個請求環節繫結唯一 id 並上報時間的方式串聯起整條呼叫鏈路。在鏈路追蹤系統提供的介面可以輕鬆地檢視整個請求的呼叫過程，能夠幫助我們更快地定位請求中的問題，優化介面的效能。

SkyWalking 鏈路追蹤系統

25. 容器管理平臺

以前，團隊的專案都是直接部署在伺服器上，簡單粗暴。但是隨著時間的推移，專案會越來越大，最終成長為一個巨石應用。

滾雪球

隨著雲端計算、容器、微服務等技術的發展，對於一些大型的巨石專案，我們可以將其拆分為獨立的微服務，部署在一個個相互隔離的容器中。容器就像一位少女，輕量、優雅而迅速。

一個專案可能需要同時部署多個容器，我們需要對這些容器進行管理和資源的分配。而容器比伺服器的粒度更細，數量可能是機器數的幾倍，手動去管理他們是很難的。

Docker 容器

因此我們需要容器管理平臺，統一管理容器，自動分配資源，並根據容器的資源佔用情況進行彈性伸縮，極大地提升運維效率。

K8S（Kubernetes）可以說是最知名的容器管理平臺了，很多大公司也都提供容器管理平臺的雲服務，可以直接接入。

K8S

26. 中臺

問個問題，如果讓你連續開發 5 個電商系統，當你開發第 6 個電商系統的時候，你會怎麼做呢？

肯定要將前 5 個電商系統中能用上的程式碼貼上過來對吧！

如果你意識到重複開發的麻煩，你就知道有一箇中臺會多香了，說是提升百倍效率一點也不誇張！

中臺的概念近幾年來在國內十分火熱，可以簡單地理解為被很多系統共用的中介軟體的集合。

中臺又分為業務中臺、技術中臺、資料中臺、組織中臺等。就拿業務中臺來說，就是抽象傳統的業務場景，把後臺的火藥等資源整合成前臺打仗需要的炮彈，隨取隨用。

回到上述問題，我們是不是可以將前 5 個電商系統中用到的技術和工具，抽象成一箇中臺呢？

中臺出現之前，由於團隊的分散，我們總是在重複建設一個又一個的輪子。而如今，幾乎所有的網際網路巨頭都在建設自己的中臺，比如支付中臺、直播中臺、電商中臺等。如果要開發一個新的系統，我們根本不用從零開始，直接使用中臺資源就能很方便地完成，很快啊！

27. 指令碼管理

在開發中，我們經常需要編寫一些指令碼（可以將指令碼理解為簡單的程式），來幫助我們更快捷地完成某項任務。

比如我們要去重啟一個程序，需要執行關閉程序、清理檔案、啟動程序三個步驟，可能要輸入很多行命令才能完成。

dostop
doclear
dostart

不妨直接將三個步驟的命令塞到一個 shell 指令碼檔案裡，再次重啟程序時，只需要一行命令就行了，很快啊！

./restart.sh

但如果我們想在其他的系統上多次使用這個指令碼，怎麼辦呢？是把編寫好的指令碼放在自己的電腦上，還是直接扔到伺服器上呢？

更好的方式是使用指令碼管理平臺，團隊成員可以將自己編寫的各種語言的指令碼都發布到該平臺上，想在其他系統或伺服器中使用該指令碼時，直接請求指令碼的線上連結，指令碼將自動下載、執行和清理。

指令碼管理平臺尤其適合運維同學使用，某種程度上也是通過自動化提升了效率。

28. 視覺化資料管理

團隊開發肯定離不開資料庫，併發量高一點還需要使用快取、訊息佇列等中介軟體。

無論是本地開發，還是在測試、線上環境驗證，我們都經常需要檢視資料庫或者快取裡的資料是否正確。最直接了當的方法就是開啟小黑框，用官方提供的命令列連線資料庫，然後輸入查詢命令去檢視，這也是很多高階工程師現在還在堅持的做法，因為有 B 格。

但是，如果用了分庫分表技術，一份完整的資料被分散到多個數據庫和資料表中，使用命令列來檢視就比較麻煩。因此，我們需要視覺化的資料管理平臺，比較常用的是本地軟體 Navicat、JetBrains DataGrip 等。

為了更方便地管理資料，團隊內部還可以搭建線上的視覺化資料管理平臺，比如面向 MySQL 資料庫的 phpMyAdmin，開發者無需在本地安裝任何軟體，直接開啟網站，輸入密碼，就能夠瀏覽和操控資料啦！

phpMyAdmin 資料庫管理

29. 專案管理

提到專案管理，大家可能覺得和技術研發同學沒什麼關係，其實不然。

通過專案管理平臺，我們能夠看到每個需求的優先順序和排期，可以合理規劃自己的研發安排，掌控進度。有重要的資訊，也可以貼到需求詳情下，相對正式，能夠及時同步到所有需求的參與者，規避一些風險。

而如果沒有專案管理平臺，對需求進度沒有一個好的把握，說不定摸魚就摸過頭了。

有很多開箱即用的專案管理平臺，比如 TAPD 和 Jira。

30. 企業通訊

通訊軟體是團隊溝通協作、高效辦公的靈魂，比如騰訊的企業微信、阿里的釘釘、位元組跳動的飛書。

這些企業通訊軟體早就不只是支援團隊即時溝通的工具了，而是大而全的企業辦公門戶。

像騰訊的企業微信，集成了文件、待辦、會議、通訊錄、工作臺、雲盤、電話等辦公必備的工具，成員可以通過軟體快速地找到並使用這些功能，大大提高了辦公效率。還可以在通訊軟體中設定機器人，實現業務的自動告警。

以上就是魚皮分享給大家的錦囊啦。

其實，大廠中還有很多提升研發效能的技術，比如流量回放、壓測平臺、試驗系統、故障演練系統等，這裡就不一一介紹了。

此外，每個團隊負責的業務不同、情況不同，也都會有提升自己研發效能的獨門祕技，要根據實際的場景去選用技術，否則可能適得其反。

希望大家能利用好現有的技術、發掘新的技術，不斷提升研發效能，感受技術帶來的美好。