鵝廠大佬給的 30個提高團隊研發效能建議

點擊「程序員內點事」關注，選擇「設置星標」php

堅持學習，好文每日送達！前端

互聯網大公司價值上億的項目背後，團隊成員是怎麼高效協做開發的？

和我本身開發辣條項目時有什麼區別？

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

魚皮在學校的時候，作過不少項目，但大部分都是練手的 Demo。基本都是單兵做戰，毫無章法。

大二暑假，我第一次進入企業實習，要和同事合做開發一個大項目，對於企業中的條條框框和同事寫的爛代碼很是不適應，成天大呼同事不講碼德！

大三來到字節跳動實習，仍是和同事一塊兒開發一個新項目，那會兒仍然不適應團隊開發，最煩的事就是每次寫完代碼，都要讓同事檢查幾遍，確認沒問題後還要在他的監護下才能發佈上線。

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

通過在鵝廠一年多的摸爬滾打，現在的我，終於可以熟練運用企業的各類資源來提高本身和團隊的研發效率了！

我總結了 30 個提高團隊研發效能的錦囊，完整覆蓋項目的各研發流程，分享給你們~

1. 技術選型

想要提高團隊開發效率，在投入項目開發前，必須確認項目的技術選型。好比項目選用哪一種編程語言、選用哪一個開發框架、選用哪些依賴庫、選用哪一個測試框架、選用哪一種數據庫、選用哪些中間件等等。

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

技術選型的考量要素很是多，好比：

團隊成員對技術的熟悉程度。團隊成員對技術越熟悉，培訓成本越小，開發效率越高。在一個都是 Java 工程師的團隊提出使用 C++ 簡直不講碼德！程序員
團隊對技術的掌控度。團隊內至少要有一我的很是瞭解該技術，懂得最佳實踐，可以指導團隊正確運用技術，並解決疑難問題。web
技術的主流程度和生態。技術越主流，文檔、實踐和解決方案就越多，而使用冷門技術可能出現沒法解決的問題，整段垮掉！shell
技術和業務的貼合程度。技術是爲業務服務的，所以必須結合具體的業務場景去選用技術。好比在只有幾個用戶使用的小網站中運用微服務框架是一個愚蠢的選擇。數據庫

2. 開發工具

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

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

目前比較主流的開發工具備 JetBrains 全家桶、 Vscode、 Sublime 等等，沒必要沉迷於某一款開發工具沒法自拔，能夠針對項目的類別和體積進行選擇。

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

3. 代碼規範

在開發前，爲團隊或項目制定一套代碼規範太有必要了。

好的代碼規範可以幫助團隊成員閱讀理解他人的代碼，提高協做開發效率和團隊氛圍。

試想，若是你習慣代碼縮進兩格，而其餘同窗都縮進四格，會不會感到很懊惱？

4. 腳手架

在開發一個新項目前，一般由架構師或熟悉技術框架的同窗來搭建項目的基本結構、編寫 Demo，其餘同窗只須要在此基礎上遵循規範進行開發（複製粘貼）就好。

現在，項目結構愈來愈複雜，咱們不可能手動建立一個又一個文件。

懶人推進世界，不少框架自帶了 腳手架，可以讓咱們經過輸入一兩行命令，快速生成項目的基本結構、默認配置文件、甚至是可直接運行的 Demo，避免了沒必要要的重複工做，大大提高開發效率！

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

5. 低代碼構建

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

就像如今網上不少 App 和網站製做平臺，只須要在界面上選擇元素、點點拖拖，就可以自動建立出應用，根本不須要寫任何代碼，哪怕是不會編程的人也能輕鬆使用。

低代碼構建在企業中很是流行，是提高團隊開發效率的神器，幾乎每一個大公司都有本身的低代碼構建平臺。業界比較知名的低代碼平臺有 Google 的 App Maker 和微軟的 Power Apps 等。

6. 內部依賴倉庫

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

可是，一般軟件依賴源都是國外的服務器，好比 Maven 和 npm 源，從國內下載依賴的速度很是慢。雖然下載慢的問題能夠經過配置國內鏡像源獲得必定程度的解決，可是沒法直接在公有軟件源上傳私有包。

所以，一般企業都會在內網搭建私有軟件源，即 內部依賴倉庫，便於內部依賴管理，大大提高拉取效率。

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

7. 本地開發熱更新

不少年前，在我還有一雙清澈的雙眼的時候，我在本地開發網站都是改一行代碼，而後切換到瀏覽器裏刷新看效果，而後再改代碼，再刷新，如此往復，很是難受。尤爲是開發後臺應用時，哪怕在代碼中改了一個字母，都要去重啓項目！

如今想一想，效率實在是過低了。

現在，本地開發熱更新是程序員開發提效必備的神器，啓動一個開發服務器，讓它自動監聽代碼文件。當代碼更新時，運行中的項目也會自動更新，從而省去了無止盡的刷新和重啓。

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

8. Serverless

Serverless 是最近幾年逐漸流行的概念，翻譯過來就是「無服務器」。

之前，咱們要搭建網站的後臺，首先要買服務器，而後將一個大而全的項目包部署到服務器上，總體對外提供服務，全部的系統資源和進程都須要由咱們本身來管理。

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

而 Serverless 不是指徹底不須要服務器，而是讓開發者感覺不到服務器的存在。

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

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

9. 代碼託管

不少年前，咱們的代碼幾乎都存在本身的電腦裏，經過 U 盤或者網絡傳輸代碼文件來實現合做開發。

而現在，代碼託管平臺已經成爲團隊合做開發的靈魂。

相信不少小夥伴都接觸過 GitHub，世界上最大的代碼開源託管平臺。每一個人均可以把本身的代碼發佈到 GitHub 上，做爲一個代碼倉庫，隨時隨地遠程管理。還能夠搜索和瀏覽其餘人發佈的代碼倉庫，以此實現高效地合做開發，促進項目的完善。

爲了保證代碼的安全保密性，通常在公司或團隊內部都會本身搭建一個代碼託管平臺，比較知名的有 GitLab，能夠針對不一樣的項目爲成員分配權限，更好地管理團隊的代碼。

10. 本地代碼檢查

在代碼提交以前，首先應該在本地進行代碼檢查，及時發現一些低級的語法錯誤，防止被團隊的其餘同窗嘲笑。

大多數集成開發工具自帶了代碼檢查功能，邊敲代碼邊檢查，很是爽。

此外，咱們還能夠配置 Git Hooks，在代碼提交前自動執行代碼檢查， npm 項目能夠經過 Husky 插件實現，還能配合 ESLint 實現代碼自動修復。

11. 代碼提交規範

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

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



   
   
    
    
             
    

    
 
    <提交類型>[可選的做用域]:  
 
    <描述> 
 
    
 
 
    
[可選的正文] 
 
    
 
 
    
[可選的腳註]

指定代碼提交規範不只可以幫助成員快速理解每次提交的改動點，提高代碼審查效率；更大的做用是讓一些自動化工具理解提交信息以進行一些有意義的工做，好比生成 Change Log（代碼改變日誌）。

能夠參考一些大公司的代碼提交規範，並經過 commitlint 和 commitizen 等插件實現自動修復不規範代碼。

12. 代碼審查

在團隊開發中，寫代碼可不能像本身練習編程時同樣肆無忌憚。

在合做開發時，能夠爲每位開發者分配一個分支，在本身的分支編寫和提交代碼，也能夠按照需求來創建分支。確認開發測試完成後，發起一個 MR（Merge Request 合併請求），將小分支的代碼合併到公共的主線分支便可。

主線分支的代碼一般是可以直接發佈上線、穩定運行的。所以，爲了保證項目代碼的質量，每次合併代碼到主線分支前，必需要進行 代碼審查（CR，即 Code Review），就是讓同事或上級閱讀和審批你的代碼，以爲沒有問題後，纔可以執行代碼合併。

一般，代碼變動越大、項目越重要，代碼審查所需人數越多，越可以發現一些我的沒法發現的風險和問題。所以，代碼審查是大公司研發流程的關鍵一環和重要防線。雖然不能直接提高研發效能，可是能有效避免線上事故的發生，減小程序員沒必要要的工做量和心理壓力。

13. CI/CD 流水線

CI/CD 即持續集成/持續交付。

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

所以， 持續集成的意義在於，經過天天定時將各個開發人員的代碼合併到同一個代碼倉庫中，以儘早發現代碼衝突和錯誤，幫助團隊更緊密地開發協做。

當咱們開發完項目，想要發佈上線時，要先登陸服務器，而後在服務器上拉取代碼倉庫中的項目代碼，而後執行打包命令，最後經過腳本運行項目。

若是隻須要在一臺服務器上部署，其實還不算太麻煩，可是若是要在幾十臺機器上部署呢？要一臺一臺地登陸服務器而後重複着上述工做麼？

懶人推進世界，這時咱們就須要 持續交付，將構建部署的每一個步驟由人工轉變爲機器自動操做，原理相似編寫了一個自動化構建腳本，在代碼合併到倉庫時觸發腳本的執行，在各機器上自動拉取新代碼並打包發佈。

目前主流的 CI/CD 平臺是 Jenkins 老爺爺，能夠配合代碼託管平臺 GitLab 等實現徹底自動化打包、構建、發佈，不再用開發人員一臺臺登陸機器去執行重複的命令了，不只大大提高了團隊研發效率，還保證了發佈流程的規範和安全性。

畢竟總有些內鬼程序員藉着發佈的名義偷偷登陸服務器執行 rm -rf *。

14. 監控告警

爲了在第一時間發現線上項目存在的問題，咱們一般會在代碼中添加告警邏輯，當某段代碼執行異常時經過郵件、短信、微信、電話等方式聯繫項目負責人。

但有時，咱們可能會針對某些指標在一段時間內的統計值設置告警。好比當機器內存佔用超過 80% 且持續 5 分鐘才告警。這些告警邏輯和業務自己關係不大，若是都寫死在代碼裏，不只耗時，並且難以維護。

能夠在團隊內搭建 監控告警平臺，經過在機器上部署代理或者在代碼中使用上報 SDK 等方式來讓告警平臺統一收集項目運行時的各個指標，好比機器負載、網絡負載、異常信息等。

監控告警平臺提供配置界面，能夠靈活地配置告警規則，好比 1 分鐘內收集到 2 個報錯就發郵件告警、收集到 5 個報錯就發短信等。

完善的監控告警平臺還可以對歷史告警信息進行管理和詳情查看，以及可視化展現各指標圖表等。不只減小了咱們開發時的工做量，也能幫助咱們更快地分析和排錯。

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

15. 日誌平臺

一般，已上線的項目出現問題時，咱們會經過查看日誌文件來定位和排查問題。

若是項目比較小，僅僅在單臺服務器上部署，那麼只須要登陸這臺服務器，輸入命令來查看日誌便可。

但團隊的項目量級較大時，一般會部署到多臺機器上，並且每臺機器上的日誌量都很是大，以人工的方式一臺臺登陸服務器，而後在數以萬計的日誌中去找到本身想要的關鍵信息，是很是低效又噁心的！

日誌不講武德，能夠搭建一個統一的日誌平臺來治治它們。將各臺機器上分散的日誌收集到日誌平臺，而後經過可視化的界面去集中管理和搜索日誌，大大提高了查閱日誌的效率和體驗。

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

16. 接口文檔平臺

如今不少的項目都採用先後端分離的方式進行開發，前端同窗寫界面，後端同窗提供接口。若是沒有一個規範的接口文檔，聲明每一個接口的協議、請求參數、響應參數等，很容易致使前端請求錯誤。

傳統的方式是由後端同窗手動編寫接口文檔，接口改動時，文檔也要改動，很是低效且不利維護。

其實，咱們能夠將接口文檔平臺化，經過 Swagger 等工具自動生成精美的接口文檔網站，開發者還能夠在網站上直接測試各個請求，告別了手動編寫文檔的低效繁瑣，提高了開發和協做效率。

17. 接口測試平臺

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

咱們寫完代碼後，不只要在本地測試，還要在測試環境、預發佈環境、線上環境都進行測試驗證。項目越大，對測試的要求越高，也就越麻煩。

一般咱們會使用 Curl、 Postman 等工具進行接口測試，簡單易用。可是有些時候，本地網絡（公網）和測試環境（內網）的網絡不互通怎麼辦？

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

18. 即時協做

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

好比在協做開發同一個項目時，可使用開發工具 Vscode 的 VS Live Share 插件，支持多人連線，團隊成員能夠同時對文件進行編輯，甚至還能看到對方的光標！

在多人編寫同一個文檔或表格時，可使用騰訊文檔，實時看到其餘成員的光標位置和對文檔的改動，尤爲是在開會時，這個功能將很是有用。

使用即時協做平臺不只能夠提高效率，還能以最快的速度發現衝突，發現有人正在寫爛代碼能夠直接打字提示他。

19. 團隊知識庫

團隊在開發項目的過程當中，確定會產生不少有用的知識，好比技術選型過程、線上事故的分析處理過程、技術文檔、產品文檔、業務介紹等。這些知識是團隊成員共同積累的財富，往後可能要給其餘同窗閱讀學習，所以必須妥善保存。

之前的作法是，你們把想共享的文件傳到一個公共的網盤中，須要時下載到本身的電腦上。當網盤的文件更新時，還要再重複下載，很是地低效。

如今的項目團隊，通常都有本身的團隊知識庫，一般是雲端網站的形式，全部的成員能夠在知識庫中上傳想要保存和分享的文檔，也能夠直接在知識庫中編寫文檔。想要學習知識的同窗直接登陸知識庫網站，搜索文檔便可，還可以對優秀的文檔進行收藏。

團隊知識庫不只可以更好地維護和沉澱團隊的知識，還能提高你們編寫和閱讀文檔的效率，更好地進行知識協做共享。

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

20. 進程監控

有時，咱們線上運行的項目進程可能由於某些意外而退出，並且沒有被任何人及時發現，這可能會對團隊形成巨大的損失。

爲了保證線上項目的高可用，能夠開啓 進程監控，當項目進程退出時，自動重啓該進程而且向負責人發送告警，必定程度上減小了事故的影響，也省去了手動重啓進程的操做。

能夠本身編寫進程監控腳本，也可使用一些現成的監控程序，好比 Supervisor 和 Monit 等。

21. 前端監控統計

前端監控主要包括對頁面的性能監控、錯誤監控和用戶行爲監控。對於 C 端項目而言，前端監控很是重要。經過性能監控，能夠分析頁面性能的不足，優化頁面，提高用戶體驗。經過錯誤監控，能夠在用戶進行某些誤操做時第一時間通知到項目負責人，並進行相應的處理。經過行爲監控，能夠獲取 UV、PV、IP、點擊流等等，從而分析用戶的使用習慣，改進產品。

若是沒有前端監控平臺，開發者要本身收集各用戶行爲指標，且只能經過不斷地測試來分析頁面性能的不足，會產生不少額外的工做量。

有不少現成的前端監控平臺，好比百度統計、專一錯誤監控的 Sentry、騰訊的 Aegis 等，直接申請帳號接入便可，省去了本身搭建的麻煩。

22. 任務調度平臺

在平常開發中，少不了執行定時任務，好比天天檢測數據是否正常、定時發送郵件、同步數據等。若是把這些任務都寫死在代碼中去執行，即便用一些定時任務框架，當任務多了，也會變得難以管理。並且沒法控制任務的執行狀態，還有可能致使一些單次任務的重複執行，形成風險！

所以，須要統一的 任務調度平臺來管理任務。能夠經過平臺界面實時查看各任務的執行狀況，還可以靈活地控制任務的啓停、執行參數、超時時間等。甚至能夠將任務調度到多臺機器同時執行。下降風險的同時提高了管理定時任務的效率。

有一些優秀的開源任務調度平臺如 Elastic Job 和 XXL-JOB，能夠直接搭建使用。

23. 配置中心

任何項目都離不開配置，好比數據庫鏈接密碼、第三方服務調用地址等。

若是把配置都寫死在代碼中，或者是項目包裏的配置文件中，當配置須要修改時，咱們就不得不修改項目文件，提交代碼，從新打包，再發布上線，很是麻煩。

並且有些時候，因爲多個項目使用了相同的配置，在改動一行配置時，可能要去修改多個項目，不只麻煩，並且存在漏改的風險。

所以，咱們須要一個配置中心來集中管理那些常常變化的、同時被多個項目使用的配置。

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

24. 鏈路追蹤

假設咱們的項目中有一個功能依賴多個第三方接口，該功能的平均執行時間是 50ms。



   
   
    
    
             
    

    
 
    /**
 * 獲取用戶詳情（依賴三個接口）
 */ 
 
    
 
 
    function getUserDetail() { 
 
    
   
 
    let user = getUserById();  
 
    // 獲得用戶基本信息 10ms  
 
    
  user.account = getUserAccount();  
 
    // 獲得帳戶信息 20ms 
 
    
  user.idcard = getUserIdCard();  
 
    // 獲得用戶身份證信息 20ms 
 
    
   
 
    return user; 
 
    
}

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

當出現複雜的調用關係時，咱們可使用鏈路追蹤系統，經過給每一個請求環節綁定惟一 id 並上報時間的方式串聯起整條調用鏈路。在鏈路追蹤系統提供的界面能夠輕鬆地查看整個請求的調用過程，可以幫助咱們更快地定位請求中的問題，優化接口的性能。

25. 容器管理平臺

之前，團隊的項目都是直接部署在服務器上，簡單粗暴。可是隨着時間的推移，項目會愈來愈大，最終成長爲一個巨石應用。

隨着雲計算、容器、微服務等技術的發展，對於一些大型的巨石項目，咱們能夠將其拆分爲獨立的微服務，部署在一個個相互隔離的容器中。容器就像一位少女，輕量、優雅而迅速。

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

所以咱們須要容器管理平臺，統一管理容器，自動分配資源，並根據容器的資源佔用狀況進行彈性伸縮，極大地提高運維效率。

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

26. 中臺

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

確定要將前 5 個電商系統中能用上的代碼粘貼過來對吧！

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

中臺的概念近幾年來在國內十分火熱，能夠簡單地理解爲 被不少系統共用的中間件的集合。

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

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

中臺出現以前，因爲團隊的分散，咱們老是在重複建設一個又一個的輪子。而現在，幾乎全部的互聯網巨頭都在建設本身的中臺，好比支付中臺、直播中臺、電商中臺等。若是要開發一個新的系統，咱們根本不用從零開始，直接使用中臺資源就能很方便地完成，很快啊！

27. 腳本管理

在開發中，咱們常常須要編寫一些腳本（能夠將腳本理解爲簡單的程序），來幫助咱們更快捷地完成某項任務。

好比咱們要去重啓一個進程，須要執行關閉進程、清理文件、啓動進程三個步驟，可能要輸入不少行命令才能完成。

不妨直接將三個步驟的命令塞到一個 shell 腳本文件裏，再次重啓進程時，只須要一行命令就好了，很快啊！



   
   
    
    
             
    

   
    
  ./restart.sh

但若是咱們想在其餘的系統上屢次使用這個腳本，怎麼辦呢？是把編寫好的腳本放在本身的電腦上，仍是直接扔到服務器上呢？

更好的方式是使用 腳本管理平臺，團隊成員能夠將本身編寫的各類語言的腳本都發布到該平臺上，想在其餘系統或服務器中使用該腳本時，直接請求腳本的在線連接，腳本將自動下載、執行和清理。

腳本管理平臺尤爲適合運維同窗使用，某種程度上也是經過自動化提高了效率。

28. 可視化數據管理

團隊開發確定離不開數據庫，併發量高一點還須要使用緩存、消息隊列等中間件。

不管是本地開發，仍是在測試、線上環境驗證，咱們都常常須要查看數據庫或者緩存裏的數據是否正確。最直接了當的方法就是打開小黑框，用官方提供的命令行鏈接數據庫，而後輸入查詢命令去查看，這也是不少高級工程師如今還在堅持的作法，由於有 B 格。

可是，若是用了分庫分表技術，一份完整的數據被分散到多個數據庫和數據表中，使用命令行來查看就比較麻煩。所以，咱們須要可視化的數據管理平臺，比較經常使用的是本地軟件 Navicat、 JetBrains DataGrip 等。

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

29. 項目管理

提到項目管理，你們可能以爲和技術研發同窗沒什麼關係，其實否則。

經過項目管理平臺，咱們可以看到每一個需求的優先級和排期，能夠合理規劃本身的研發安排，掌控進度。有重要的信息，也能夠貼到需求詳情下，相對正式，可以及時同步到全部需求的參與者，規避一些風險。

而若是沒有項目管理平臺，對需求進度沒有一個好的把握，說不定摸魚就摸過頭了。

有不少開箱即用的項目管理平臺，好比 TAPD 和 Jira。

30. 企業通信

通信軟件是團隊溝通協做、高效辦公的靈魂，好比騰訊的企業微信、阿里的釘釘、字節跳動的飛書。

這些企業通信軟件早就不僅是支持團隊即時溝通的工具了，而是大而全的 企業辦公門戶。

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

以上就是魚皮分享給你們的錦囊啦。

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

此外，每一個團隊負責的業務不一樣、狀況不一樣，也都會有提高本身研發效能的獨門祕技，要根據實際的場景去選用技術，不然可能拔苗助長。

但願你們能利用好現有的技術、發掘新的技術，不斷提高研發效能，感覺技術帶來的美好。

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍介紹下魚皮npm

魚皮今年本科畢業加入騰訊，大學期間帶着工做室建設了幾十個網站，拿過國家獎學金、挑戰杯國獎，還曾在字節跳動等公司實習，實力很是強！編程

魚皮是全棧方向，熟悉多種技術，常常開發一些有趣的項目。他的公衆號『魚皮客棧』分享不少實用的編程技術、軟件資源、優秀面經等，創做靈感來源於親身經歷，讀他的文章很是有代入感。他正在寫一本漫畫形式的編程知識大百科，幫助你們擁抱技術、愛上編程！後端

不管你是前端、仍是後端，或者只是對編程有興趣，想獲得一些學編程的經驗技巧，均可以長按二維碼關注『魚皮客棧』 哦！瀏覽器

魚皮還超級寵粉哦，他的公衆號抽獎永不間斷！關注後回覆「我要抽獎3」 便可參與抽獎，各類公仔和程序員周邊等你拿！‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

本文分享自微信公衆號 - 程序員內點事（chengxy-nds）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。