用戶界面組件體系結(jié)構(gòu)如何解決組織問(wèn)題

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

　　問(wèn)題是，我們解決問(wèn)題的大部分方法都來(lái)自于研究小項(xiàng)目。在小型項(xiàng)目中，我們可以使用一個(gè)樣式表，或者在UI框架上迭代。

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

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

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

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

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

　　隨著應(yīng)用的發(fā)展，前端團(tuán)隊(duì)創(chuàng)建了一個(gè)庫(kù)來(lái)“共享”代碼。

　　浪費(fèi)時(shí)間和停滯

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

　　開(kāi)發(fā)人員不愿做出改變，因?yàn)閾?dān)心它會(huì)在其他地方“崩潰”。

　　由于團(tuán)隊(duì)擁有站點(diǎn)的不同部分，開(kāi)發(fā)人員甚至不知道什么可能會(huì)中斷。

　　瓶頸的產(chǎn)生是因?yàn)樽兓歉唢L(fēng)險(xiǎn)的。

　　不一致

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

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

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

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

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

　　高風(fēng)險(xiǎn)/復(fù)雜性和條式代碼

　　現(xiàn)在有人提交另一個(gè)設(shè)計(jì)請(qǐng)求。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　CSS模塊允許有兩種情況。第一，他們擺脫了全局類暴露的問(wèn)題。這意味著當(dāng)您為組件更新一個(gè)類時(shí)，您確切知道將會(huì)更新什么，因?yàn)闃邮降姆秶窍鄬?duì)于組件的。

　　第二個(gè)主要優(yōu)勢(shì)是，開(kāi)發(fā)人員知道所有樣式都在哪里。他們不必?fù)?dān)心樣式表會(huì)在一組普通的樣式表上分散開(kāi)來(lái)。

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

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

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

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

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

　　一個(gè)特性請(qǐng)求通過(guò)并被分解成一組組件。

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

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

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

　　一旦更改或新組件被批準(zhǔn)，該分支就被移動(dòng)到主文件中。

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

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

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

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

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

　　另一個(gè)設(shè)計(jì)？沒(méi)有問(wèn)題。我們將在組件庫(kù)中創(chuàng)建一個(gè)分支，并更新所有樣式。當(dāng)我們準(zhǔn)備發(fā)布時(shí)，我們將創(chuàng)建一個(gè)主要的版本更新。問(wèn)題就解決了。

　　缺點(diǎn)呢？

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

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

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

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

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