隨著互聯網的不斷發展，越來越多的程序員都在學習不同的編程開發方式，而組件化編程開發就是其中的一個常用開發方法。今天我們就一起來了解一下，組件化開發中關于組件的優劣性應該如何判斷。

認識組件

隨著近些年”微前端“概念的不斷醞釀，越來越多的團隊開始著手將自己的業務處理為不同組件，然后通過一些微前端做法，編排到一個業務頁面中去。

那么對于組件的維護就會變得越來越重要。所以，先來看看現在大多數團隊是怎么維護組件的吧!

大庫型，Antd、Element標準的大庫型

一次型，完全業務組件，用完一次再也不維護

高復用型，一看就應該單獨封裝以后給其他人用，比如：視頻播放器

項目融合型，與業務項目在一起，混合store，不分你我

我暫時能想到的就這幾種類型的組件，如果你的團隊也在維護自己的一套組件庫，那么應該很容易理解我上面所說的。

我相信，既然這么做了，肯定有這么做的理由和好處，沒有人會閑著沒事找麻煩做不是，那么這些做法都有什么好處和痛點呢?我從幾個方面入手分別分析一下。

方便、快捷

組件嘛，當然是快能跑起來，方便能看到效果好咯。就這點來講，還有什么比直接在業務項目里擼組件更快的方式嗎!?

現在用個展示的面板，立馬去components目錄擼一個。

數據?不是有store嗎?引入進來不就拿到數據了!

所見即所得，現在改完馬上看到頁面上的效果!無法反駁..

這么看確實開發這個組件是好快了，但是從整個業務需求實現來看，這么做真的是快的嗎?如果這樣的做法是快捷的，那為什么那么多團隊在強調沉淀、封裝、抽象呢?

其實很多組件當時看起來，這輩子就只可能用一次，不用封裝。可是往往交互稿過來的時候就會發現，這個樣式好像我在哪里見過。然后去各種業務項目里一頓翻，哇終于找到了，復制過來發現各種爆紅，定睛一看，store???

所以，聰明的團隊早已洞察這一切，讓我們把組件都維護到同一個地方，然后大家寫好文檔，用的時候從庫里面取就可以了。

可維護性

于是乎，大家便如火如荼的開始的組件抽象，組件整改的浩大工程。

一開始，一般會有一個團隊中較為靠譜、能力突出的小伙子(嗯?怎么是我?)去把Webpack、Babel、TypeScript、SassLess、目錄結構、單元測試結構、代碼規范、Review規范、發布規范這些梳理好，然后寫一個標準的組件出來，后再強調一下大家一定要按照規范認真維護組件，書寫文檔，編寫單元測試。

從維護性上來講，大家把組件都寫在一個庫里面，然后再用到的項目中直接引入，業務上的問題逐漸被分為組件問題還是項目問題，甚至有些需求可以用這個交互在組件庫中有相似的，用那個組件就可以了，來反駁產品和設計。

組件大小、加載性能

接觸Webpack的一些周邊工具，比如analyzer很容易可找出具體是什么包”霸占“了這么多的流量。

發現原來組件包中還有一些個組件，看上去不應該放在大庫中進行維護，比如那種一次性組件，二次封裝型組件。

因為這種組件可能會引入一個很大的三方依賴，比如視頻播放器、BannerSwiper等。

對于這樣的組件，好的處理方式應該是創建一個獨立的倉庫，封裝完善后，寫好README，發布至內網NPM，供業務項目使用。

【免責聲明】：本內容轉載于網絡，轉載目的在于傳遞信息。文章內容為作者個人意見，本平臺對文中陳述、觀點保持中立，不對所包含內容的準確性、可靠性與完整性提供形式地保證。請讀者僅作參考。

總結

以上是生活随笔為你收集整理的java组件化的优势_组件化编程开发如何判断组件的优劣性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。