微服務對前端的衝擊：微前端終於落地了 - thecamjackson

• 更小，更有凝聚力和可維護的程式碼庫
• 具有分離的自治團隊的更具可擴充套件性的組織
• 能夠以比以前更加增量的方式升級，更新甚至重寫部分前端

優點

1. 增量升級
對於許多組織來說，這是他們微觀前沿之旅的開始。舊的，大的，前端的巨石被昔日的技術堆疊或者在交付壓力下編寫的程式碼所阻礙，並且它已經到了完全重寫的深坑邊緣。為了避免 完全重寫的 危險，我們更傾向於 逐個扼殺舊的應用程式，同時繼續為我們的客戶提供新功能，而不受整體結構的影響。

這往往導致微前端架構。一旦一個團隊獲得了將功能一直帶到生產的經驗而對舊世界幾乎沒有任何修改，其他團隊也希望加入新世界。現有程式碼仍然需要維護，在某些情況下，繼續新增新功能可能是有意義的，但現在可以選擇。

最後的結論是，我們可以更自由地對產品的各個部分做出逐案決策，並對我們的架構，依賴關係和使用者體驗進行逐步升級。如果我們的主框架發生重大變化，每個微前端都可以在有意義的時候升級，而不是被迫停止世界並立即升級所有內容。如果我們想要嘗試新技術或新的互動模式，我們可以以比以前更孤立的方式進行實驗。

2. 簡單的解耦程式碼庫
根據定義，每個單獨的微前端的原始碼將遠小於單個單片前端的原始碼。這些較小的程式碼庫對於開發人員來說往往更簡單，更容易。特別是，我們避免了由於彼此之間不瞭解的元件之間的無意和不適當的耦合而產生的複雜性。透過在應用程式的有界上下文周圍繪製較粗的線條，我們會使這種意外耦合更加困難。

當然，單個高階架構決策（即“讓我們做微前端”）並不能代替好的老式清潔程式碼。例如，跨越有界上下文共享域模型變得更加困難，因此開發人員不太可能這樣做。同樣，微前端會促使您明確並慎重地瞭解資料和事件如何在應用程式的不同部分之間流動，這是我們應該做的事情！

2. 獨立部署
與微服務一樣，微前端的獨立可部署性是關鍵。這減少了任何給定部署的範圍，從而降低了相關風險。無論您的前端程式碼如何或在何處託管，每個微前端都應該有自己的持續交付管道，該管道可以構建，測試並將其一直部署到生產環境中。我們應該能夠在很少考慮其他程式碼庫或管道的當前狀態的情況下部署每個微前端。如果舊的整體塊是固定的，手動的，季度釋出週期，或者如果隔壁的團隊已將半完成或損壞的特徵推入其主分支中，則無關緊要。如果給定的微前端已準備好投入生產，它應該能夠這樣做：

3.自治團隊
將程式碼庫和釋出週期分離的更高階段的好處：團隊可以完全擁有為客戶提供價值所需的一切，從而使他們能夠快速有效地行動。為了實現這一目標，我們的團隊需要圍繞垂直業務功能組成，而不是圍繞技術功能。一種簡單的方法是根據終端使用者將看到的內容來分割產品，因此每個微前端都封裝了應用程式的單個頁面，並由一個團隊端到端擁有。這帶來了團隊更高的凝聚力，下圖每個應用程式應由一個團隊擁有：

總結
簡而言之，微前端都是將大而可怕的東西分成更小，更易於管理的部分，然後明確它們之間的依賴關係。我們的技術選擇，我們的程式碼庫，我們的團隊和我們的釋出流程都應該能夠彼此獨立地運營和開發，而不需要過多的協調。