現代Web應用程序變得越來越大，越來越復雜，有時由不同的團隊來管理。 您的應用程序可能具有由不同團隊開發的功能，并且您希望在交付整個應用程序之前僅將某些功能發布到生產環境中。 如果您有一個倉庫，您如何管理不同的團隊，不同的發布時間表?

這些復雜的應用程序大多數都生活在客戶端，這使得維護變得更加困難。 這個整體式的大脂肪應用程序還存在其他一些問題。 在這篇文章中，我們應該考慮微觀前端的原因有哪些?

[[348126]]

1. 應用很小

第一個原因是應用程序變小了，您不必下載大型代碼庫，而只需要等待10分鐘即可安裝所有依賴項。 想象一下，您加入了一家公司并第一次克隆了存儲庫，而您必須等待15分鐘才能下載依賴項并編譯項目。 當您查看源代碼時，有成千上萬的組件被編寫，您甚至都不知道在哪里尋找或在哪里進行更改等。如果您的應用程序足夠小，則可以更快，更輕松地瀏覽應用程序。

2. 應用是獨立的

由于所有應用程序都是分開劃分和開發的，因此它們彼此獨立。 當您擁有一個整體應用程序時，您有太多彼此依賴的模塊和組件，從而導致在哪里進行更改或在哪里尋找外觀等方面的困惑。設想一個場景，您必須在現有的整體應用程序中進行一些更改，并且 5個不同的團隊為此工作。 有時，您每次必須召開一次會議，從所有團隊中查找信息大約需要2周的時間。 如果應用程序具有明確定義的邊界并允許一個專門的團隊專注于此，通常可以節省大量時間。

3. 應用程序更易于理解

應用程序較小，由一個團隊開發，因此更易于理解。 由于這些應用程序具有明確的界限，并且由一個團隊開發，因此它們通常遵循一致的樣式指南，這使它更易于理解。 對于大型應用程序，有幾個團隊在處理它，而他們通常不遵循一致的樣式指南。 您甚至可以定義一個好的項目結構，因為用于項目的組件或服務數量很少。

4. 應用程序更易于開發和部署

由于這些應用程序的性質很小，并且由一個團隊開發，因此非常容易開發和部署。 我們甚至可以獨立部署。 當您在Jenkins上擁有大型應用程序的構建管道時，由于擁有成千上萬的組件，因此需要等待20至40分鐘才能下載并編譯該項目。 當您為每個微型應用程序定義單獨的管道時，使用微型前端可以大大減少這些構建時間。

5. 應用程序更易于測試

我們必須為大型應用程序編寫成千上萬的單元測試，并且要花很多時間才能運行。 這會使我們的部署過程變慢。 當涉及到微型前端時，每個應用程序只有很少的單元測試，并執行自己的單元測試，并且可以獨立運行。

6. 應用程序開發變得更快

由于有獨立的團隊，整個開發變得更快，更容易。

7. CI / CD變得更容易

每個應用程序都可以集成和單獨部署，這使得CI / CD的過程變得更加容易。 當我們修復應用程序或引入新功能時，我們不必擔心整個應用程序，因為所有功能都是獨立的。

8. 獨立的堆棧和版本

我們可以為每個應用選擇自己的堆棧，但是這種情況很少發生，但是我們可以在同一堆棧中使用不同的版本。 例如，某些團隊具有靈活性和時間來引入和測試同一堆棧的較新版本。 例如，React很好，可以靈活地完成任務，而Angular可以很好地滿足其他要求，您可以根據自己的需要選擇框架，而不必依賴以前的開發人員或以前的團隊就開始使用它。 相同適用于同一框架的不同版本。

9. 沒有共享代碼

在大型應用程序中，我們傾向于跨功能共享代碼，但是這種擴展性不好，并且隨著應用程序越來越大，會引入許多錯誤和相互依賴性。 這不適用于微型前端，因為除非它是愚蠢的組件，否則我們不會共享代碼。 我們可能會分享信息

10. 可以輕松更改架構，而無需觸及舊架構

有時我們必須擴展舊的體系結構，但是我們可能沒有開發人員來實現或擴展該體系結構。 借助微型前端方法，我們可以開發具有最新堆棧的新功能并獨立交付。 如果要擴展已有20年的現有應用程序，很難找到開發人員，因為您必須使用新技術來實現整個應用程序，或者可以借助微前端方法進行擴展。

結論

我知道微前端并不能解決所有問題，但是它為您提供了足夠的理由和靈活性來開始考慮這些問題。