起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何利用組件，高效解決復用和個性化的矛盾？
思考組件這件事，對于產品經理的產品思維訓練是有幫助的。本篇文章圍繞組件展開了一系列的思考，包括如何拆解組件以及組件的未來，感興趣的小伙伴們快來一起看看吧，希望對你有所幫助。
這篇文章是我對過去半年工作的一些思考，閱讀過程中需要一些背景知識的支撐，例如你需要理解「應用」、「低代碼」、「組件」等概念。
當然，我會盡可能用簡單的語言去表達，但還是要首先說明，這篇文章有一定的閱讀門檻。
一、組件背后的產品思維
在介紹什么是組件之前，我想首先說明一下組件背后的產品思維，因為這是理解組件價值的關鍵。
所謂思維，是從感性到理性的提煉結果。感性是我們面對世界看到的現象，理性是我們從繁雜的現象中抽象出來的概念和規律。
例如，在外賣平臺沒有出現之前，我們感受到的現象是「無法堂食」和「想要立刻吃到東西」之間的矛盾，當這個矛盾成為一種普遍的社會現象時，能解決矛盾的外賣服務便出現了。
起初是門店給顧客留電話，顧客打電話訂餐品，門店老板自己送。后來供應商多了，顧客需求多了，就出現了更高效地解決這個矛盾的平臺。外賣產品從一種感性的矛盾中脫胎出來，成為了一種新的概念和規律。這種規律就是，我打開外賣 app，就可以獲得我周圍的可配送的美食。
外賣產品不是從天而降的，而是感性層面的現象不斷累積，最終變成了理性的概念。
組件也是一樣。在互聯網早期，可能并沒有組件的概念（產品領域沒有，可能在技術領域是存在的），后來出現了一種現象是什么呢？那就是不同的業務應用，往往采用的都是同一種或者相似的產品框架來完成。
例如很多公司都有自己的后臺管理工具，他們很多時候可以抽象為對數據的增改刪查；又例如很多公司內建自己的項目管理工具，內核也是一種狀態機。
哪怕是現在的電商領域，無論是以天貓、京東為代表的貨架式電商，還是以抖音為代表的興趣電商，他們 app 首頁的產品框架也都是以記錄列表（什么是記錄，此處就不展開）為核心。
這樣的現象隨著互聯網的高速發展而愈發明顯，繁雜的業務應用背后是通用的產品架構。但由于每個業務獨立核算、獨立運營，導致一套產品框架往往要在不同的業務中開發多次，也就是很多人討厭的重復造輪子現象。
誠然，在方案設計環節，產品經理會通過盡可能復用已有的成熟方案降低開發成本，但只要有一點點改動，從開發流程上來說就需要走一遍完成的流程。
這就導致業務方經常會問：“我就改這么一點點東西，為啥還要排期到那么晚”。我只能告訴你，生產關系就是這樣，在原有的系統里無論你改的是什么，可能都需要把所有干系功能都測一遍。
從上述現象中我們可以提煉出哪些矛盾呢？
- 很多業務應用的內核是相似的，但需要多次開發
- 凡是動代碼的，可能就是慢的，代碼開發、測試和發布的速度趕不上業務變化的速度
在這種矛盾日益劇增時，組件出現了。
組件背后的產品思維，就是盡可能將邏輯相似的代碼塊抽象為通用的可配置的功能單元，從而高效解決復用和個性化的矛盾。
它背后體現出組件的兩種特性：高通用、高可配。
并帶來兩種鮮明的業務價值：復用價值、兼容價值。
二、為什么要討論組件
在介紹組件的具體特性之前，我想說一說「為什么要討論組件」。
首先，思考組件這件事，對于產品經理的產品思維訓練是有幫助的。我們知道，大多數產品經理以擁有好的抽象能力而自居。然而他們的抽象能力，大多是建立在業務需求上的抽象能力，非產品角度的抽象能力。
業務需求的抽象能力，追求的是用一個產品化的方案解決多樣化的業務需求。例如業務方希望通過打折的方式在特定時間點對產品做促銷，這是一種從經濟學和心理學角度出發的業務訴求。當然要對哪些商品做促銷，促銷力度如何，促銷規則怎么樣，都依賴于不同的業務方有不同的玩法。
有些希望做滿減促銷，有些希望做限時打折，有些希望搭贈一些臨期商品，從各自業務的角度看都是合理的，產品經理要做的事情就是用產品來滿足業務訴求。
但組件要求產品經理具備的抽象能力，是對產品的進一步抽象，并對最終抽象而成的模塊做產品化。
例如我們經常在大促期間見到的各種活動頁面，雖然看起來風格不同，且每個頁面也都是跟業務溝通之后，確定下來的共識，但從產品角度看其核心是相似的。
很多電商促銷頁面主要包括商品、券、轉盤、動圖、按鈕、鏈接跳轉等要素，但抽象出來其實都是一系列的組件。
而這種從多樣化的頁面到組件的抽象過程，就是對產品的進一步抽象，這是一種產品思維的訓練。
其次，思考組件這件事，也有助于對產品經理這個行業未來的思考奠定基礎。當我從事低代碼行業的第一天我就在思考，如果我們在做的這件事做成了，那很可能意味著大批的程序員和產品經理的失業或轉型。
本質原因在于，社會的發展會使得資源最終會流轉到最能用好它們的人手中，這是客觀的經濟學規律，不以人的物質為轉移。
還記得我們在第一部分提出的兩點矛盾么：重復開發和慢迭代。須知這種矛盾的背后是人力和機器資源的巨大投入。這種投入還存在，是因為當下我們沒有更好的解決辦法。
但如果我們往5年、10年后看去，如果產品經理這個崗位帶來的業務價值已經低于他們存在本身帶來的資源消耗，那資源就會轉移到其他崗位上。
會不會出現這種現象呢，我不確定，但我認為應該警惕和思考。
像輕流這樣已經商業化的低代碼產品，正在幫助中小型企業搭建一些簡單的表單應用，那原來準備投入到自研或外包中的資源，就節約下來了。
我一直在想，有沒有可能5 年后的互聯網產品生產端，負責標準化模塊（評論、訂單等）的產品經理會消失，取而代之的是低代碼產品經理和業務產品經理，前者負責不斷完善底層工具和生態，后者負責面向不同業務方落地產品實施。
僅作一猜測，擺在這里。
三、拆解組件
這節，我將以騰訊微搭產品為例子，帶大家一起拆解組件。要拆解組件，首先要對組件做定義、分類和內部結構分析。
在我看來，組件是可被復用的完整的產品功能模塊。
可被復用是組件最顯著的特征。因為它是對產品的進一步抽象，說明它可以出現在不同的產品中，進而在搭建應用時，它可以出現在不同的頁面中。
完整是指組件代表了一個完整的使用場景。例如下圖中的文本組件，它代表的場景是在頁面中展示一段文本。且頁面中任何使用到文本的地方，都可以拖入這個組件，它也是通用的。
從這個定義出發，線條就不是一個組件，因為單單一個線條不能代表任何完整的使用場景，盡管它是可復用的。
最后，組件是一個功能模塊，我所理解的功能，是它具有處理信息的能力。再抽象一些，它有自己的輸入、作用和輸出。
要進一步拆解組件，首先要對組件做分類。
原子組件：不能被進一步拆解的組件，代表了某個功能場景下的最小粒度。例如上述的文本組件就是一個原子組件，因為我不可能再進一步拆解出一個字符組件。它也代表了當我需要在頁面展示文本信息時，在這個場景下我需要的最小功能模塊。
復合組件：由原子組件組合而成的組件，代表了復雜場景下的功能模塊。
例如下圖的表格組件。這種組件往往更貼合某種實際的使用場景，比如管理一張表格，或者填寫一個問卷，他們的目標是在對應的復雜業務場景下，可以有更便捷的方式搭建出對應的功能模塊來。
原子組件由于粒度小，所以在搭建時的自由度更高，理論上如果一個平臺的原子組件足夠豐富，那么可以搭建出非常復雜的應用出來。但它的劣勢在于，搭建門檻非常高。
以上圖的表格組件為例，拆開來看它包括的原子組件是：按鈕、復選框、文本、搜索框等組件，但如果我只給你提供這四個原子組件，讓你搭建出上圖這樣的效果，估計你會崩潰的。
復合組件由于更貼近實際使用的場景，所以搭建門檻更低。
例如對上述表格來說，我只需要給組件關聯對應的數據模型，然后做一些字段和樣式配置，基本上在 5 分鐘內就可以搭建出一個能對數據表做增改刪查的管理表格。
但另一方面，它的靈活性也相對被降低了，因為很多布局和樣式都是預設好的，沒有可以進一步編輯的功能，所以兼容性較差。
從上面的分析可以看出，不同的組件盡管都可以代表完整的功能場景，但設計上還是有不同的考慮，這種考慮往往是自由度和使用體驗之間的平衡。這也是組件本身固有的矛盾。
組件的功能拆解，需要從輸入、作用和輸出三個角度來說。我們以經常用到的美食篩選場景為例。
上圖是大眾點評美食頻道頁里的篩選功能，我可以通過選擇美食的種類，進一步縮小我看到的頁面信息的范圍。那在低代碼產品中，這種功能模塊怎么搭建出來呢。
首先我們需要使用一個下拉選擇組件，注意，這個組件是一個抽象的組件，它既不代表美食的篩選，也不代表距離的篩選。它表達的意思是：這個組件提供了在下拉框中完成單選的功能。
要給這個組件賦以業務含義，就必須向它注入數據。例如，給這個組件關聯美食品類的數據表，這樣下拉選擇后的每一個選項，代表了一種美食品類。
有了輸入之后，就需要對輸入做處理，那下拉選擇組件是怎么處理的呢？它提供了一種特性，叫做用戶在 app 上點擊選中的數據，就代表了這個組件最新的值。
你選擇了火鍋，業務上代表了你在美食品類中選擇了火鍋，產品上代表了你在下拉選擇組件中，通過前端頁面的點擊，給組件賦值，這個值就是火鍋這個選項數據。
最后是輸出，輸出是該組件作為一個獨立的功能模塊，能夠給頁面、或者頁面內的其他模塊傳遞的信息。在上述例子中，從業務上看，當我們選擇了火鍋之后，商戶列表就完成了一次刷新，并且刷新之后只展示跟火鍋相關的商戶。
但產品原理上并不簡單。首先，在搭建的時候，需要在頁面內建立下拉選擇組件和商戶列表組件之間的關系，是的，看起來內容很多的商品列表，其實也是一個組件。建立的是什么關系呢？是一種篩選邏輯關系。
在商戶列表組件的篩選條件中，我們需要加上，這個列表中每個商戶的美食品類需要等于下拉組件中選擇的美食品類。
在這個邏輯關系中，下拉組件的值作為輸出，就被商戶列表組件使用了，這種關系，用偏技術的話說叫做「消費」，就是我用了你給我的東西。
以上只是下拉選擇組件在實際 app 中的一個很簡單的應用，事實上組件的輸入、處理和輸出遠比這個場景要復雜很多。但無論有多么復雜，從這三個角度去分析組件的功能我理解基本都是可以的。
如何設計一款組件呢？這是很多低代碼產品經理面臨的課題，也是我在過去半年內從事的主要工作。一個完整的組件設計方案，需要重點考慮三個問題：
- 屬性：這個組件的功能是什么
- 樣式：它長什么樣子
- 行為：它跟其他模塊之間如何交互
屬性如我們剛剛所述，需要考慮組件的輸入、處理和輸出。還是以微搭中最簡單的文本組件為例。
可以看到微搭的文本組件提供了兩個最基本的屬性配置項：內容和格式。它解決的就是一個問題：這個組件需要以什么方式展示什么內容。
樣式決定了這個組件長什么樣子，例如它在展示區域內的間距、位置，它是否有背景色等等。樣式的配置能力跟很多設計軟件提供的能力很像，在此就不贅述。
最后是行為，它告訴系統的就是一個問題：當發生了什么事情時，會執行什么動作。發生了什么事情，我們一般叫做觸發事件。
它往往是一個可被捕獲的前端事件，例如點擊、失焦、hover 等。而執行的動作，就是產生了這些事件時，接下來需要做什么。
例如下圖是一個表單復合組件，當我們點擊提交按鈕時，它捕捉到的是 click 這個事件，接著會執行的動作可能就是，將提交的數據更新到數據庫。
行為往往是進行組件和組件之間以及系統和系統之間通信的橋梁，如果有機會我們可以再好好聊聊組件的行為。
四、組件的未來
我先拋出我的看法：組件未來一定要建立起生態，且組件生態一定是市場化的。
組件要解決的問題，類似于 SaaS 產品在現階段想要解決的矛盾：以標準化的解決方案滿足多樣化的業務訴求。
從發展的眼光看，業務訴求豐富度的增長，一定是快過產品解決方案能滿足的場景的增長，所以一定要部分場景是標準化的解決方案覆蓋不了的。這一點從國內外的 SaaS 廠商紛紛布局自己的 PaaS 能力可以看出。
同樣的，雖然組件滿足的是快速搭建業務應用的場景，但目前絕大多數的低代碼產品，其組件的設計還是中心化的：平臺負責設計，開發者使用。當開發者的訴求無法被滿足時，他們提出了新的需求，平臺開發新的組件。
問題是：這種中心化開發的模式下，組件可以被稱為組件的前提是，它必須要有一定的通用性，不受場景的局限。這個前提本身就限制了組件模式的天花板。
事實上回歸組件的定義：可復用的完整功能模塊。在這個定義下，我們并不強調組件一定要由平臺生產和定義，平臺能不能提供生產組件的能力，由眾多開發者自己生產，自行使用呢。我理解是可以的，且在國外產品中已經構建起這樣的市場了。
在一款低代碼產品中，我們已經能看到，當系統提供的組件不能滿足你的搭建訴求時，你可以在組件市場中安裝更多的組件，而這些組件可能就是由第三方服務商開發完成的。
通過平臺，充分連接起組件生產者、組件使用者、應用使用者等不同的利益相關方，這樣的生態會使得有越來越多的為垂直行業而服務的復合組件出現。
五、結語
這篇文章大致呈現了我對組件相關的思考，由于篇幅的限制，以及出于可讀性的考慮，與組件相關的頁面、流程、模型、變量等概念就沒有提及，但你需要知道對于一款完整應用來說，以上這些都是很重要的系統。
其實，從 0 到 1 開發一款應用并沒有那么容易，當我從事低代碼之后，我才體會到一款應用產生的背后會牽涉到如此復雜的系統，這是我以前工作的盲區。
在這之前我作為產品經理，更多關注的是用戶和客戶的價值，較少關注產品的實現邏輯。這也是絕大多數產品經理的通病，否則也不會出現「這個需求很簡單，怎么實現我不管」這樣的段子。
但如果你真正走到產品背后，去從搭建的角度思考一款應用的從 0 到 1 ，你會對這份工作產生更多的敬畏之心的。
這是我半年來最大的收獲。
專欄作家
大力哥呀，微信公眾號：大力哥，人人都是產品經理專欄作家。一個90后產品經理，已經寫了6年的公眾號，通過輸出獲得了許多意料外的成長。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
如何做通兌積分平臺
請問是哪個平臺的低代碼？想了解一下
類似于物理學中對物質組成的研究，原子?分子?物質；app 的首頁搭建其實也可以看成是一種遞進。從最基本的組間，再到簡單組合后的組件，不斷組合，最終形成一個完成的獨立的APP。