1、系統龐大，涉及多個角色，角色互串，導致功能與功能之間的關係不清晰2、角色對應的頁面劃分不清晰，系統和系統之間混雜在一起
3、前端專案過大，前端效能低下
4、組員多，專案管理難
1、角色清晰、角色所屬功能清晰2、專案解耦，便於維護管理
3、專案上線，完全不會影響現有功能
4、效能進一步提公升
5、拆解顆粒度足夠細時，將不在限制於技術框架，對優秀人才的需求可以多元化
1、現有共用功能，難以實現共用，導致了**冗餘（持續迭代則是需要這麼做）2、第三方包多次引入，專案的總包增大（功能拆解後，對應的角色有對應的功能，絕大多數使用者並不需要或者沒有許可權載入所有內容，整體包載入應當是降低的）
3、對專案管理要求提公升，清晰各個系統之間的串聯
4、全域性性功能修改難度提公升（bit）
5、嚴重依賴元件庫（劣勢4），依賴固有的規範，發布流程等（後期沉澱為自己的一套模式十分重要）
6、非常依賴於前期的規劃或者經驗豐富者
1、拆解將以系統層面拆解2、以使用者的角色拆解為子系統
3、子系統再拆解，拆解為獨立模組專案
4、專案跳轉則是路由+專案位址的方式跳轉（又以系統為大目錄，對應的下級模組為目錄，並不會混亂）
微前端 跨域 做個微前端demo
之前已經分享過微前端，至於落地還是不落地就看公司和專案了，今天基於微前端做了個小demo，分享一下。可以去qiankun官網看看，包括微前端核心設計理念 為什麼不是ifram和快速上手及一些問題都很清楚。因為自己一直用的都是vue，所以基座和子應用都是用vue腳手架快速搭建，至於接入react和jq...
我的前端開源專案 知微
今天想要和大家分享的是乙個開源專案知微。關於知微我先介紹下我準備用知微做什麼 程式設計師的開源提公升平台。嗯是的，就是打造乙個開源平台。你可以將自己優秀的github專案放到上面，平台會為你做推廣，從而收穫更多的star。你也可以把你開發了一部分準備用來開源的 放到上面，平台會為你推廣，讓更多的小夥...
react 微前端實踐
最近花時間實踐了一下阿里 qiankun 微前端框架 主應用和子應用都使用react 實現，主應用伺服器使用golang語言 go chi框架實現，子應用實現簡單的對接，主應用配置好路由就可以訪問 專案還在持續完善中,專案實現目標 主應用只負責選單，使用者，路由，許可權管理等 子應用各司其責，熱插拔...