微前端開發流

關於微前端開發流其實大部分情況都是希望部門自治，不要有互相干擾的情況發生。微前端本質是希望用基技術方案來解決管理問題，把資源分散到其他部門進行開發，每個應用程式自治。

要注意什麼？

微前端非常需要前端架構師去管理架構，實務上其實蠻多困難，但有幾個關鍵的 Tips 是可以優先被處理的。

狀態管理

在微前端之中的耦合點是需要定義出禁止的溝通手法，確保在 global 之下的單例物件對於分散出去的服務是唯讀的，只有特定的介面或窗口才能夠去進行副作用操作。在各個專案都嚴格管理下，確保副作用和狀態都是可預期，那管理微前端就會是一件更加容易的事情。

版本管理

雖然微前端允許應用自治，但如果不斷載入許多微前端，那也會導致應用的總體用戶加載的檔案大小，逐漸累積增長。有計劃的去管理應用中必須是一致的版本這件事很重要，可以大幅降低總體程式碼大小。但也因為是微前端，也不會失去多版本共存的彈性，可以執行漸進式版本迭代。

共享資源

只要是共享資源，最懼怕的就是版本不一致無法相互構通，本身設計上就是高度耦合架構。一但發生需要版本更迭，最先碰上的難題就是「全部應用要同時更新」這個困難點，此時就會遇上微前端最鎮痛的共用 Library 升級的過程。但最務實的方式是盡可能避免使用共用 Library，這樣就可以避免版更帶來的困擾。

更明確的策略

對於跨應用溝通，應該盡量使用 Browser API 來傳遞資訊，由此避免自己實作的行為有版本落差時產生更版的困擾。如果有行為類型的推薦使用 CustomEvent 去溝通，有儲存需求可以利用 Browser Storage 來緩存，共用狀態保持單例模式去管理。

所以該怎麼做？

既然為前端都需要篇大型應用使用，且更需要跨部門協作的規範，所以每一個前端項目的負責可以拆出單位。有些可以使用「人」搭配「職務代理」去協作，有些可以用「部門」為單位協作，每一個協作單位互相溝通不應該基於程式碼來溝通，應該完全按照 API 文件去溝通。當有需要跨協作單位去溝通時，依照文件去相互理解功能與職責。

以敏捷開發來說，每一次的 Planning 之後應該先進行單位職責的分類，當需要跨單為協作時，由負責該單位的前端開發設計曝露的介面，進行改動必要的開發與改動。而到了 Kick of 都應該提供時都應提供必要的設計介面進行同步，提供完整的溝通方式與解決方案的規劃。每一次的 Review 確保介面的可理解性與耦合性，並做好每一次溝通的版本管理的正確性，以及對低版本的兼容性。

當每個微前端服務徹底被區隔，版本管理意識才會高度拉升，對於個版本的謹慎程度才大大的被提高，而不是用較為輕忽的態度在修改程式。共用這件事應該是謹慎的，不能為共用而共用，而是有意識去抽象和共用。