UI組件是一個非常困難的問題。只是選擇一個UI框架或者在一些設(shè)計模擬上進行迭代，一切都會得到解決。對嗎？

　　問題是，我們解決問題的大部分方法都來自于研究小項目。在小型項目中，我們可以使用一個樣式表，或者在UI框架上迭代。

　　在一個使用大量的產(chǎn)品的大型組織中，這不會奏效。 以下是可能出錯的細節(jié)：

　　缺乏規(guī)劃和架構(gòu)

　　設(shè)計師為產(chǎn)品創(chuàng)建高保真的模型。

　　前端團隊將設(shè)計實現(xiàn)到應(yīng)用程序中。

　　應(yīng)用程序大小的增長。

　　隨著應(yīng)用的發(fā)展，前端團隊創(chuàng)建了一個庫來“共享”代碼。

　　浪費時間和停滯

　　產(chǎn)品需要對其中一個組件進行更改，但該組件現(xiàn)在在20-30頁。

　　開發(fā)人員不愿做出改變，因為擔心它會在其他地方“崩潰”。

　　由于團隊擁有站點的不同部分，開發(fā)人員甚至不知道什么可能會中斷。

　　瓶頸的產(chǎn)生是因為變化是高風險的。

　　不一致

　　現(xiàn)在產(chǎn)品負責人“A”她不喜歡一個選擇框，所以她讓設(shè)計師模擬出了一個她喜歡的新的選擇框。

　　創(chuàng)建了一個新的一次性組件，它將被輸入到代碼庫中，而不需要團隊的其他成員對此進行了解。

　　現(xiàn)在有兩個選擇框。

　　選擇框的更改不會在應(yīng)用程序中傳播。

　　現(xiàn)在，不僅存在瓶頸，還存在設(shè)計上的不一致。這一過程也缺乏團隊的支持。

　　高風險/復(fù)雜性和條式代碼

　　現(xiàn)在有人提交另一個設(shè)計請求。

　　全局樣式表的尺寸越來越大，以至于掩蓋任何其他樣式。

　　該組件引用了一種基礎(chǔ)樣式，它將以一種不受歡迎的方式更新許多內(nèi)容。

　　所以創(chuàng)建樣式拼圖，重要的是添加，現(xiàn)在…

　　認真的…開發(fā)人員已經(jīng)開發(fā)結(jié)束了，設(shè)計師已經(jīng)退出了，產(chǎn)品主人仍然在問為什么簡單的改變是如此難以做到。

　　幸運的是，有非常聰明的人努力解決這些問題。 那么我們?nèi)绾谓鉀Q呢？ 下面這是如何添加一些結(jié)構(gòu)的清單：

　　步驟1：構(gòu)建組件庫

　　即使您的組件庫引用了一組開源組件，也可以構(gòu)建自己的庫和版本。不僅如此，為庫中的所有組件創(chuàng)建包裝器。這樣，如果您需要將某些東西交換出來，則不需要更改外部API。您只需要修改實現(xiàn)細節(jié)。

　　組件庫應(yīng)該是應(yīng)用程序的核心。所有的應(yīng)用程序都需要這個庫。不要在您的應(yīng)用程序中編寫組件和“向后移植”，而是在前面的組件上工作。這將生成更好的代碼和更有意義的應(yīng)用程序。

　　組件庫的另一個優(yōu)點是所有開發(fā)人員可以隔離和觀察更改。特別是如果您正在管理GitHub中的代碼，并在在合并之前需要提取請求。

　　在一個單一的應(yīng)用程序中，很容易將變更轉(zhuǎn)移到一個導(dǎo)致不一致的功能分支上。有了一個組件庫，人們就可以抵制牛仔編程。

　　步驟2：將您的整體前端拆分成較小的應(yīng)用程序

　　如果您的應(yīng)用程序有很多頁面，那么您應(yīng)該嘗試將所有這些頁面移動到它們自己的SPA（單個頁面應(yīng)用程序）中。這個系統(tǒng)的美妙之處就在于，當您對組件庫進行更改時，您可以對所有應(yīng)用程序進行漸進的更新。它使你不必去做“一個巨大的更新”。

　　這減少了開發(fā)人員對更改導(dǎo)致更多工作的擔心。團隊能夠按照自己的進度管理更新。不需要有一個巨大的組織推動來更新一個按鈕。

　　步驟3：使用CSS模塊隔離組件設(shè)計

　　CSS模塊允許有兩種情況。第一，他們擺脫了全局類暴露的問題。這意味著當您為組件更新一個類時，您確切知道將會更新什么，因為樣式的范圍是相對于組件的。

　　第二個主要優(yōu)勢是，開發(fā)人員知道所有樣式都在哪里。他們不必擔心樣式表會在一組普通的樣式表上分散開來。

　　步驟4：使用交互樣式指南作為用戶體驗、產(chǎn)品和工程之間的合同

　　任何組件庫都應(yīng)該能夠發(fā)布交互式樣式指南。對于開發(fā)人員、產(chǎn)品團隊和設(shè)計人員來說，這是一個中間地帶。它允許您隔離您的組件并獨立地處理它們。你可以更快地工作，看到變化更快。最好的部分是，一旦您發(fā)布了更新，它將通過整個應(yīng)用程序傳播這些更改。

　　交互式樣式指南就像是故事書。它不僅捕獲了外觀和感覺，還公開了響應(yīng)組件的狀態(tài)（在工作中對Vue支持）。

　　既然您已經(jīng)知道了所有組件的位置，就不需要每次都交付高保真的模型了。設(shè)計師可以更多地關(guān)注行為、信息設(shè)計和用戶體驗。開發(fā)人員在開始新功能時不必擔心設(shè)計問題。他們可以專注于業(yè)務(wù)邏輯和復(fù)雜的行為。

　　這種方法的潛在流程如下：

　　一個特性請求通過并被分解成一組組件。

　　前端開發(fā)人員決定該特性是否需要新的組件或更改。

　　如果沒有，那么特性開發(fā)就可以開始了。

　　如果需要新的特性，開發(fā)人員將在組件庫中創(chuàng)建一個特性分支。在產(chǎn)品、UX和其他開發(fā)人員的交互式風格指南中，這些更改將被評審。

　　一旦更改或新組件被批準，該分支就被移動到主文件中。

　　根據(jù)更改的不同，這個庫的新版本是在semver之后創(chuàng)建的。

　　將應(yīng)用程序的設(shè)計抽象為一組組件，并開發(fā)成組件庫。該庫應(yīng)使用NPM進行版本控制。打破API或可能的主要設(shè)計變更將保證主要版本的更改。

　　應(yīng)用程序的部分被分解為具有自己的package.json的SPA（單頁面應(yīng)用程序）。這允許他們以可控的方式對組件進行升級。

　　新組件或更改在開始特性開發(fā)之前就已經(jīng)確定了。產(chǎn)品、UX和工程可以使用交互式樣式指南在組件設(shè)計上進行協(xié)作，并在站點上看到一個“真實”的副本。更改并不可怕，因為如果存在與更改相關(guān)的風險，開發(fā)人員可以使用版本控制來減輕影響。另外，現(xiàn)在使用CSS模塊對組件樣式進行隔離，因此對組件“a”的更改不會影響組件“b”。

　　用戶體驗現(xiàn)在可以交付低精度的模擬組件，根據(jù)名稱來引用組件。開發(fā)人員知道要使用哪些組件，不需要在“共享”代碼的某個地方“釣魚”。

　　另一個設(shè)計？沒有問題。我們將在組件庫中創(chuàng)建一個分支，并更新所有樣式。當我們準備發(fā)布時，我們將創(chuàng)建一個主要的版本更新。問題就解決了。

　　缺點呢？

　　將“整個應(yīng)用”更新仍然會有支持者。

　　將應(yīng)用程序拆分為小應(yīng)用程序可能會對某些產(chǎn)品造成規(guī)模太大的問題。

　　預(yù)先設(shè)計組件需要滿足團隊中大量的規(guī)范。并不是每個人都能夠抽象需求并據(jù)此制定計劃。

　　牛仔編程仍然可以實現(xiàn)。你的庫和你的程序需要一個所有者。

　　這不是一個容易的跳躍，它需要整個組織的支持。如果您的目標是在增加團隊速度的同時減少瓶頸和草率的更新，那么上面羅列的就是您的方法。如果你仍然相信“推送”按鈕的更新。祝你好運！當你看到速度下降和成本上升時不要感到驚訝。