今天來跟大家聊聊大型組織中（前端工程師的人數開始超過15人）前端管理架構，主要涉及的是團隊協作。

本文不討論在這樣的大公司中常見的管理問題或業務領域問題，而是關注前端的協作架構。

如今，前端架構涉及的領域太多，因此，建議將其分為以下幾部分：

一、Visual Code

從最簡單的主題開始，這是前端開發最常用的代碼編輯器。

最可能是因為我們希望在同一家公司開發多個前端應用程序，所以我們希望它們具有：

• 品牌認知度
• 相同的UI/UX

為此，需要一個設計系統。設計團隊必須提出設計規范，并在所有將來的產品設計中遵循這些設計準則。即使這已經是一個非常復雜的任務，并且需要設計團隊、工程師和產品之間進行大量討論和協調。

從前端的角度來看，需要提供一種工具來在工程師之間實施和共享此設計規范。為此，一個好的解決方案是創建npm軟件包，該軟件包將由Storybook或其他類似工具直觀地呈現。我認為，擁有專用的Web資源（帶有URL）以及有關如何使用此軟件包的文檔非常重要。該Web資源將由前端工程師和設計師使用，并且可以作為他們之間對話的重要參考。

小結：在這一點上，有一個設計規范及其在包中的封裝和它的交互式文檔。所有的前端應用程序中共享并采用這個package。

二、代碼結構

接下來談談日常編碼，我們確實實現了新功能、修復了bug，如果需要的話重構代碼。我們需要關注我們的代碼庫，試圖讓它變得友好和容易理解。但是，當我們的公司開始有不是1個、也不是2個，而是幾十個大小項目時，會發生什么呢？

通常，人們圍繞一些項目分組，并開始只與這組項目一起工作。由于人的本性和有限的時間，我們通常不能在一段時間內兼顧多于2-5個項目。所以很自然地，我們開始受到這些群體的影響。順便說一句，感謝美國國家航空航天局（NASA）為我們提供了這么棒的照片。

但是，我們開始遇到越來越多的情況，當人們進行跨團隊協作時，需要檢查彼此的代碼和解決方案，甚至在其他應用程序中也要修復一些錯誤，或者在某個外部應用程序（對于他們的小組來說是外部的）中添加他們需要的東西。影響力）。壞消息是，這一過程正在幾乎不受控制的大公司中發生。好消息-我們可以幫助改善它。

怎么樣？正確。通過為公司中的所有項目提供相同的代碼結構，編碼和結構準則。

讓我們更深入地了解代碼結構的含義：

• 項目中的文件夾結構

  工程師第一次進入新項目時-與項目中的文件夾結構相同，他們知道所有內容都對導航和搜索有很大幫助。

• 配置或支持性文件的

  文件，如package.json、.gitignore、.editorconfig、webpack.config等他們應該總是在同一個地方，在每一個項目。如果需要，將它們連接到測試配置文件或CI文件。

• 文件類型的固定位置

  如果相同文件類型的位置始終遵循相同的結構，則效果也很好。例如，如果組件文件夾中始終有一個style.css文件：

  /Component
  --/Component.tsx
  --/style.css
  --/index.ts
  

• 組件內部結構：文件內部的結構應相同：導入、導出的順序、公共功能的位置、類型等。在每種類型的文件中，都應該知道期望的內容。

• 命名規范：這包括文件夾、文件、變量、函數、類、類型等的名稱

• 編碼約定：總的來說，編碼約定是一個非常寬泛的部分，但是在這里我只想包含不適合其余部分的內容

在實踐中，相同的代碼結構和項目工具集非常緊密地結合在一起，有利于開發效率。我所說的工具集是指CLI工具（項目啟動、檢測、測試等）、IDE擴展等等。我們將在下一節中討論工具集主題。

小結：在應用了本節并采用它之后，我們應該使組織中的所有項目都具有相同的文件夾結構、命名規范、文件結構等。理想情況下，每個開發人員都可以在項目之間無縫切換，不需要花額外的時間來學習和理解代碼。

三、技術棧

與上一節類似，我們確實希望在組織的各個項目中擁有統一的技術棧。

在Frontend項目中，技術堆棧的組件可以是：構建該項目所基于的框架、主要語言、樣式處理器、數據層（例如Apollo）、狀態管理、測試、代碼整理、構建系統等。

當然，所有規則中都有例外。在本主題中，我也想說一句，有時某些技術非常適合某些特定項目，即使這些技術不屬于全球公司范圍的技術堆棧。但是，每當這種想法脫離公司技術堆棧時，都應該三思而后行，因為支持此類事務的成本非常高，需要收益必須非常可觀來支撐。

讓我們在這里提及一些通用技術堆棧，該堆棧現在可以適合大多數項目（當然，它僅涵蓋實際技術堆棧的一部分，但對于某人來說可能是一個很好的起點）：

• React
• Typescript
• Apollo
• Styled Components
• React Router
• Jest
• Cypress
• Create React App

在我們為公司定義技術棧并達成共識之后，還有其他非常重要的成功支柱。

首先，我們需要寫下來的技術堆棧的文件。這些文檔應該在工程師之間方便且容易地共享，因此他們始終可以相互鏈接并維護。

其次，我們應該再次使用已定義的技術堆棧來寫下并共享文檔，以及如何啟動和引導新項目的方式。

四、工具

這個話題很重要。現在，我們幾乎在所有地方都使用了一些其他工具：整理、構建應用程序、CI、組件生成器等等。因此，這就是為什么能確定我們是否可以為項目選擇正確的工具的原因至關重要。好的工具還是不好的工具（或者根本沒有工具），就像自動化測試與手動測試之間的比較一樣。

我們之前在前幾節中談到了技術堆棧和代碼結構，并提到我們需要編寫大量文檔來使項目成員關注它們。但是正確的工具集可以有機會按照公司的準則進行自動化。

例如，如果具有指定的編碼風格，則可以為項目提供linting工具集，該工具集默認情況下遵循這些規則。如果具有定義的技術堆棧，那么良好的CLI工具將提供機會，使用技術堆棧中的特定技術來引導新項目。

讓我們嘗試討論工具可以覆蓋前端體系結構的哪些部分：

• 代碼風格和結構：如我們之前所討論的，可以通過工具輕松實現自動化

• 項目自舉：無需提出新的項目結構，手動安裝所有需要的軟件包等。

• 組件生成：大多數情況下，應用程序中的某些組件甚至都不包含單個文件，因此文件創建、鏈接或者導入它們會花費一些時間，因此需要自動化。

• 啟動和構建：當然，最顯而易見的要自動化的事情是如何構建或啟動應用程序。

• 測試：為測試構建應用程序并實際運行所有類型的測試（單元、集成等）的過程。

• 依賴關系管理：現在大約80％的代碼之間是有依賴關系。因此，需要讓他們保持最新版本，并且要在大型公司中進行管理并非易事。

• 跨項目的依賴關系：很可能我們的項目不是孤立地工作，可能依賴于其他項目，，因此我們可能需要一些工具來簡化鏈接它們的過程，并結合多個項目（例如Bit等），等等。

• CI：CI是我們日常工具集的重要組成部分，自動化和統一對您的組織可能是一項非常有益的工作。

如果不想開發自己的新工具集，我可以推薦NX工具集，它是最有趣的候選對象之一。同樣，Babel的創建者似乎也執行了類似的解決方案，可能需要check out — Rome。這些工具并不能涵蓋所有內容，而是我們所討論內容的很大一部分，因此可以作為一個很好的起點。

小結：試想一下，在我們完成所有部分的采用之后，我們的體系結構將變得多么偉大。

每個項目都是相同的，并由統一工具集維護和管理。每個項目都可以以相同的方式啟動和構建。新的組件在相同的位置使用相同的命名準則生成。

五、部署

通常，在前端體系結構的這一部分中，工程師最不用擔心。也許是因為它在大多數時候都與編碼本身無關，而且可能并不那么令人興奮，但同樣重要。

在生產中，我們通常需要注意以下事項：

• Google Analytics（分析）：各種不同的跟蹤事件，例如Google Analytics（分析），Segment，HotJar等。

• 狀態監視：這包括諸如運行狀況檢查之類的內容，甚至可以在生產中運行測試，錯誤報告（例如Sentry）等。

*** 性能**：這與上一項相似，但更注重性能。這包括測量響應時間，第一個有意義的油漆等。（可能是工具＃1- Lighthouse）

• A/B測試：各種A/B測試解決方案或功能標記。

• 緩存：諸如Varnish和Cloudflare之類的工具。

所有這些都可以在公司的前端應用程序中統一，這將簡化工程師的工作。例如，通過添加具有預定義的初始配置的軟件包，并將這些軟件包添加到自舉項目中。

生產的另一部分是代碼準備，例如：

• 縮小：只是代碼縮小

• 源映射：某些其他工具，例如Sentry，可能也需要源映射。

• 資產準備：為具有不同分辨率的屏幕，裁切圖像等做準備。

這些都是將要添加到我們用于管理前端應用程序的工具集中的不錯的選擇，我們在“工具”部分中已經討論過。

六、開發

CLI工具

當我們接觸前端CLI工具時，已經部分地在“工具”部分討論了開發經驗。統一工具是工程師日常工作的重要組成部分，但不是全部。

API

在本地使用舒適的API是我們改善開發人員體驗和開發速度的第二件事。通常，為前端工程師在本地提供API并不是一件容易的事：這可能包括他們不熟悉的安裝工具或框架。即使通過泊塢設置進行安裝，這也可能會占用開發人員計算機的大量計算資源（如果不是，則可以將其視為安裝）。在這種情況下，什么是解決方案-外部服務的API。對于所有工程師來說，這可以是一臺服務器，也可以是某種機制來輕松引導您自己的專用服務器進行開發。

CI

CI是第三大部分。我可能認為，您的公司已經選擇了一些CI工具作為前端并使用了該工具 （例如Circle CI，Concourse CI或任何其他工具）。如果不是，則應統一。

我認為，特定項目的CI配置應該是該項目團隊的一部分。這給CI帶來了穩定的機會，因為有些人對CI感興趣，每天都要使用它，并且具有修復，配置和改進它的能力和技能。

但是，并非所有工作都應由團隊完成。對于前端應用程序，存在相當特定的一堆作業，這可能是需要的。特別是，如果我們能夠設法統一文件夾/代碼結構，技術堆棧等。那么在您的公司工作一段時間后，也許可以在您的CI工具階段檢測到這些模式，將這些階段實現為某種“構建基塊”，并為您的工程師提供了一個機會，就是從這些統一的“構建基塊”構建其CI管道。

演示環境

最后是最后-驗證實現的功能。在工程師完成所有工作并實施之后，幾乎總是需要某種方式來檢查其外觀和工作方式，并將其與其他工程師，設計師或其他利益相關者共享。對于此類需求，它可以通過提供的URL在特定PR的應用程序的臨時部署版本中發揮出色的作用。

該解決方案大大加快了不同團隊與人員之間的溝通，我認為這是必須具備的。但是，此臨時部署的版本應盡可能接近生產環境，因為它也是檢查某些表面錯誤或錯誤的好工具。

如果前端應用程序構建和部署流程管道是統一的，則可以輕松地將其添加到項目中并自動進行。同樣，諸如Kubernetes和Helm之類的此類工具或類似工具也可以在實現中提供很大幫助。

小結：借助具有集成塊的單個CI工具，使用統一的CLI前端工具和演示環境，即可輕松高效地進行開發流程。所有這些應使我們的開發過程盡可能順利。

7、模塊化

這個話題非常大，可能需要一篇單獨的文章來討論，但我會試著簡要地介紹一下。

在大型組織中，龐大的代碼庫并不罕見。與所有已知的問題一起出現，如緩慢的CI管道、協作工作問題、緩慢的測試等。因此，前端架構的一個重要部分是決定我們希望看到獨立前端應用/模塊的粒度。

我們現在有三種主要的模式:

• Monolith：一個大的存儲庫包含一個項目和所有的代碼，所有的團隊同時在這個存儲庫中工作。

• Monorepo：很多項目，但仍然有一個很大的存儲庫(在wiki中是monorepo)。所有的團隊仍然使用相同的存儲庫，但是使用的是不同的項目。我們已經有機會修復一些問題了，我們采用的是單一的方法，只針對特定的項目運行管道，項目有更小的測試套件等等。如果你選擇了這種方法，像Lerna這樣的工具可以讓你的生活更簡單。

• Repo per project：每個項目都有自己的存儲庫和所有支持的東西，比如CI管道、部署等。

在所有這些模型中，項目可能意味著獨立的前端應用程序、頁面、獨立的前端模塊等等。這取決于您希望如何劃分前端應用程序的粒度。在大多數情況下，這種劃分應該與所需的組織結構和人員管理同步。

決定如何分割應用程序后的第二大主題是如何將這些部分連接在一起(如果你決定分割應用程序)。

這里我們有以下方法:

• Build-time composition：項目可以只是npm軟件包，可以在構建期間安裝和組成。
• Server-side composition：通常包括服務器端渲染和服務器上發生的合成。像Hypernova這樣的工具可以幫助更好地組織它。
• Client-side composition：瀏覽器內部項目的組成。非常重要的是要提到Module Federation，這是Webpack 5中引入的一種新方法。
• Route composition：超級簡單——每個項目都有自己的URL，在Nginx層級上我們決定把用戶重定向到哪里。

就像我之前說的，用這么小的格式來涵蓋這個主題是非常困難的，但我希望你至少能找到一些自己感興趣的想法，并自己深入研究這個主題。

小結：我們找到了一種方法，通過組織存儲庫，將我們的項目分成更小的部分(最有可能)，通過使團隊更獨立于彼此，使我們的團隊快樂和富有成效。

八、測試

關于前端應用程序的測試，有很多可用的資源，所以我盡量不深入細節，而是更多地關注大型組織的問題以及我們如何解決它們。

第一步——每個工程師對測試技術的理解是不同的，以及在什么情況下應用哪種技術，如何編寫“好的”測試，等等。所以非常有必要記錄下公司所使用的測試水平的所有細微差別和指導方針，以及每個標準的指導方針。

你的測試策略中可能需要的測試級別:

• 單元測試
• 整體測試
• 端到端測試
• 其他的

此外，第二步，我們需要在公司的不同前端應用程序中統一它們，因此人們在遷移到其他項目時不會對如何以及如何進行測試有任何疑問。

如果設法統一了測試級別和方法，就可以自動幫助解決第二個問題——測試基礎設施設置。每個項目都需要在本地和CI上設置和配置一些測試基礎設施。例如，我們決定使用Cypress，它需要在docker鏡像中運行。這需要一些時間在本地和CI上進行設置。如果我們把這個數字乘以我們所擁有的項目數量，那將是非常巨大的時間。因此，解決方案——再次統一并為項目提供一些工具。聽起來很簡單，但卻需要大量的時間去實現。