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

本文不討論在這樣的大公司中常見的管理問題或業(yè)務(wù)領(lǐng)域問題，而是關(guān)注前端的協(xié)作架構(gòu)。

如今，前端架構(gòu)涉及的領(lǐng)域太多，因此，建議將其分為以下幾部分：

一、Visual Code

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

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

• 品牌認(rèn)知度
• 相同的UI/UX

為此，需要一個設(shè)計系統(tǒng)。設(shè)計團隊必須提出設(shè)計規(guī)范，并在所有將來的產(chǎn)品設(shè)計中遵循這些設(shè)計準(zhǔn)則。即使這已經(jīng)是一個非常復(fù)雜的任務(wù)，并且需要設(shè)計團隊、工程師和產(chǎn)品之間進行大量討論和協(xié)調(diào)。

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

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

二、代碼結(jié)構(gòu)

接下來談?wù)勅粘＞幋a，我們確實實現(xiàn)了新功能、修復(fù)了bug，如果需要的話重構(gòu)代碼。我們需要關(guān)注我們的代碼庫，試圖讓它變得友好和容易理解。但是，當(dāng)我們的公司開始有不是1個、也不是2個，而是幾十個大小項目時，會發(fā)生什么呢？

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

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

怎么樣？正確。通過為公司中的所有項目提供相同的代碼結(jié)構(gòu)，編碼和結(jié)構(gòu)準(zhǔn)則。

讓我們更深入地了解代碼結(jié)構(gòu)的含義：

• 項目中的文件夾結(jié)構(gòu)

  工程師第一次進入新項目時-與項目中的文件夾結(jié)構(gòu)相同，他們知道所有內(nèi)容都對導(dǎo)航和搜索有很大幫助。

• 配置或支持性文件的

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

• 文件類型的固定位置

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

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

• 組件內(nèi)部結(jié)構(gòu)：文件內(nèi)部的結(jié)構(gòu)應(yīng)相同：導(dǎo)入、導(dǎo)出的順序、公共功能的位置、類型等。在每種類型的文件中，都應(yīng)該知道期望的內(nèi)容。

• 命名規(guī)范：這包括文件夾、文件、變量、函數(shù)、類、類型等的名稱

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

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

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

三、技術(shù)棧

與上一節(jié)類似，我們確實希望在組織的各個項目中擁有統(tǒng)一的技術(shù)棧。

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

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

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

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

在我們?yōu)楣径x技術(shù)棧并達成共識之后，還有其他非常重要的成功支柱。

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

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

四、工具

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

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

例如，如果具有指定的編碼風(fēng)格，則可以為項目提供linting工具集，該工具集默認(rèn)情況下遵循這些規(guī)則。如果具有定義的技術(shù)堆棧，那么良好的CLI工具將提供機會，使用技術(shù)堆棧中的特定技術(shù)來引導(dǎo)新項目。

讓我們嘗試討論工具可以覆蓋前端體系結(jié)構(gòu)的哪些部分：

• 代碼風(fēng)格和結(jié)構(gòu)：如我們之前所討論的，可以通過工具輕松實現(xiàn)自動化

• 項目自舉：無需提出新的項目結(jié)構(gòu)，手動安裝所有需要的軟件包等。

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

• 啟動和構(gòu)建：當(dāng)然，最顯而易見的要自動化的事情是如何構(gòu)建或啟動應(yīng)用程序。

• 測試：為測試構(gòu)建應(yīng)用程序并實際運行所有類型的測試（單元、集成等）的過程。

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

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

• CI：CI是我們?nèi)粘９ぞ呒闹匾M成部分，自動化和統(tǒng)一對您的組織可能是一項非常有益的工作。

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

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

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

五、部署

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

在生產(chǎn)中，我們通常需要注意以下事項：

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

• 狀態(tài)監(jiān)視：這包括諸如運行狀況檢查之類的內(nèi)容，甚至可以在生產(chǎn)中運行測試，錯誤報告（例如Sentry）等。

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

• A/B測試：各種A/B測試解決方案或功能標(biāo)記。

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

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

生產(chǎn)的另一部分是代碼準(zhǔn)備，例如：

• 縮小：只是代碼縮小

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

• 資產(chǎn)準(zhǔn)備：為具有不同分辨率的屏幕，裁切圖像等做準(zhǔn)備。

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

六、開發(fā)

CLI工具

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

API

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

CI

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

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

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

演示環(huán)境

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

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

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

小結(jié)：借助具有集成塊的單個CI工具，使用統(tǒng)一的CLI前端工具和演示環(huán)境，即可輕松高效地進行開發(fā)流程。所有這些應(yīng)使我們的開發(fā)過程盡可能順利。

7、模塊化

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

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

我們現(xiàn)在有三種主要的模式:

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

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

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

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

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

這里我們有以下方法:

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

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

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

八、測試

關(guān)于前端應(yīng)用程序的測試，有很多可用的資源，所以我盡量不深入細(xì)節(jié)，而是更多地關(guān)注大型組織的問題以及我們?nèi)绾谓鉀Q它們。

第一步——每個工程師對測試技術(shù)的理解是不同的，以及在什么情況下應(yīng)用哪種技術(shù)，如何編寫“好的”測試，等等。所以非常有必要記錄下公司所使用的測試水平的所有細(xì)微差別和指導(dǎo)方針，以及每個標(biāo)準(zhǔn)的指導(dǎo)方針。

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

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

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

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