在數(shù)字化浪潮席卷而來的今天，低代碼平臺作為一種新興的開發(fā)工具，受到了廣泛關(guān)注。然而，正如任何新興技術(shù)一樣，低代碼平臺也面臨著諸多爭議。2021年《為什么我說低代碼是“行業(yè)毒瘤”？》一文便提出了對低代碼平臺的質(zhì)疑，認為其預(yù)設(shè)使用人群局限、暗藏變革成本、并非長期發(fā)展風口，甚至質(zhì)疑其為偽需求。

那篇文章是一篇采訪文章，大概率是媒體為博人眼球有意為之，才為文章取了一個這么大的標題。我從受訪者的回答中可以看出他說：“低代碼如果定位是幫助小白來入門行業(yè)，不是幫助從業(yè)者提升效能”的話，這樣是偽需求。因為當時低代碼普遍形態(tài)是以無代碼為主，當無法滿足需要時，通過特定方式將代碼以插件的形式注入平臺，作為低代碼平臺的內(nèi)置邏輯，供設(shè)計器使用。然后就大肆宣傳低代碼要變革研發(fā)，能做復(fù)雜場景。

我認為如果這篇文章再嚴謹點，把“指望這樣定位的低代碼平臺，來做核心業(yè)務(wù)場景”的訴求，稱之為偽需求，我認為是對的。這也是許多研發(fā)人員反對低代碼的核心原因之一，主次搞反了，因為這種模式下研發(fā)人員變成了輔助角色，而軟件工程是一門需要技術(shù)能力的學科，讓沒有技術(shù)能力的人主導(dǎo)是違反常理的。對于軟件產(chǎn)品公司來說，產(chǎn)品需要迭代規(guī)劃，需要多人協(xié)作，需要工程化管理。

但是即使這種形態(tài)的低代碼或無代碼平臺，如果定位在企業(yè)輔助場景，也是有市場有空間的。它在當企業(yè)部門之間有協(xié)同需求，但沒有專業(yè)軟件支撐的場景，找外包開發(fā)有不劃算的場景，也是起到了補充作用。比如明道云、宜搭、得帆這類平臺，做輔助場景也非常好。人家也沒說非要做核心場景。這些平臺明確表明自己主要支持一些輔助場景，這種專注使得它們在簡單場景的優(yōu)化體驗上做得相當出色。對于用戶來說，它們提供了一個清晰、直觀的選擇，使他們能夠快速地構(gòu)建和部署應(yīng)用程序，滿足日常工作的需求。這種明確的定位不僅降低了用戶的使用門檻，也提高了平臺的使用效率。但如果像某流一樣，一上來就要用無代碼顛覆，革研發(fā)的命，就有點那啥了，也就前面說的“主次搞反”。

市面上，還有一類低代碼平臺，特別奇怪，它的定位屬于不上不下的騎墻定位。以某易旗下的低代碼為例，該平臺定位在中等復(fù)雜度的業(yè)務(wù)上，但似乎并沒有很好地把握這一定位。在實際應(yīng)用中，客戶可能會發(fā)現(xiàn)它既不像簡單的無代碼平臺那樣易于上手，也不像低代碼平臺那樣功能全面。這種定位上的飄忽不定使得用戶難以判斷到底能否滿足自己的需求，從而影響了平臺的推廣和使用。

悲觀的人正確，樂觀的人向前。如果文章就寫到這里就沒意思了。接下來介紹那本文的重點，也就是哪些號稱能做復(fù)雜場景的低代碼平臺，比如ClickPaaS、炎黃盈動、當然也包括我們數(shù)式Oinone。這類產(chǎn)品必然要在技術(shù)路徑選擇上要跟明道云、宜搭、得帆，這些類型平臺不一樣。接下來我為這類平臺發(fā)發(fā)聲，它們絕對不是偽需求，只是難度很大：

首先，我們要澄清一個誤解：低代碼平臺并非僅面向初級、入門人員。

實際上，隨著技術(shù)的不斷發(fā)展，低代碼平臺已經(jīng)具備了高度的可配置性和擴展性，能夠滿足專業(yè)研發(fā)人員的復(fù)雜需求。同時，低代碼平臺也提供了豐富的API和集成能力，使得開發(fā)者能夠輕松地與其他系統(tǒng)進行集成，實現(xiàn)業(yè)務(wù)邏輯的快速構(gòu)建。因此，低代碼平臺并非局限于初級人員，而是能夠覆蓋更廣泛的開發(fā)人群。

其次，關(guān)于低代碼平臺暗藏的變革成本問題，我們需要正視但不必過分擔憂。

任何新技術(shù)的引入都會帶來一定的變革成本，包括人員培訓、系統(tǒng)遷移等方面的投入。然而，這些成本并非低代碼平臺所獨有，而是所有新技術(shù)都需要面對的問題。關(guān)鍵在于我們?nèi)绾纹胶庾兏锍杀九c潛在收益。通過合理的規(guī)劃和實施策略，我們可以將變革成本控制在可接受的范圍內(nèi)，并充分利用低代碼平臺帶來的效率提升和業(yè)務(wù)創(chuàng)新。

再者，關(guān)于低代碼是否是長期發(fā)展風口的問題，就拿《為什么我說低代碼是“行業(yè)毒瘤”？》這篇文章中提到的“現(xiàn)在程序員缺口很大，大家都在 996，加班干活，所以我們需要一個提升效能的工具”，這個沒有錯，我在其他文章中也反復(fù)提到：“隨著企業(yè)數(shù)字化轉(zhuǎn)型，企業(yè)對研發(fā)人員的需求量大幅增加，同時對他們的要求也變得更加嚴格和高標準”。低代碼做解決這類問題痛點的核心手段，才會反復(fù)被提及。只是數(shù)字化時代的低代碼需要具備面對復(fù)雜場景的能力。用一個滑稽的話做總結(jié)：“因為市面上的低代碼是毒瘤，我們要自己做一個”。

最后，我想強調(diào)的是，低代碼平臺并非偽需求，而是企業(yè)數(shù)字化轉(zhuǎn)型過程中的重要工具。對于許多企業(yè)來說，快速構(gòu)建和迭代應(yīng)用程序是提升競爭力的關(guān)鍵。而低代碼平臺正是能夠滿足這一需求的工具之一。

19年出來創(chuàng)業(yè)時，我希望把低代碼帶進企業(yè)核心場景，推出低代碼加中臺理念，通過低代碼平臺把只是停留在理念層面的中臺概念固化到技術(shù)平臺中，甚至提出了沒有低代碼加持的中臺廠商都是在刷流氓，在收割大家的智商稅。

在我眼里中臺代表：核心業(yè)務(wù)場景、互聯(lián)網(wǎng)技術(shù)，低代碼是：新的工程化輸出。我們只是用低代碼的方式輸出，互聯(lián)網(wǎng)技術(shù)與業(yè)務(wù)的最佳實踐。 針對復(fù)雜場景的低代碼平臺，如果沒有把低代碼平臺作為核心的戰(zhàn)略定力，是做不出來的，國外的Mendix和Odoo分別做了6年和8年才嶄露頭角，在中國軟件公司太浮躁，能把一點做深做透的太少，市場規(guī)模是他們的第一追求。但軟件行業(yè)一定是厚積薄發(fā)的行業(yè)，但凡有點名頭的企業(yè)基本5年以上，數(shù)式Oinone堅信低代碼平臺會從輔助場景走向核心場景，堅信所有軟件公司都需要具備這樣的能力，我們專注低代碼平臺，把場景交給伙伴，恪守邊界，努力為行業(yè)帶來一點改變。

那企業(yè)或者軟件公司如何選型能支撐復(fù)雜場景的低代碼平臺呢？我總結(jié)了以下三點，供大家思考：

1. 確保咱們各類場景情況能被實現(xiàn)

a. 找自己場景中的一個特定頁面或字段交互，是低代碼平臺原本不支持的，去驗證低代碼平臺在交互層面沒有限制

b. 找自己場景中的一個特定邏輯，最好涉及對接第三方能力比如引入第三方開源組件，去驗證低代碼在邏輯層面沒有限制

c. 是否改變研發(fā)習慣，適應(yīng)成本有多高？

2. 驗證咱們各位緯度效率有提升

a. 針對項目或產(chǎn)品研發(fā)過程中涉及的核心角色是否有提效

i. 后端研發(fā)是否提效，具體表現(xiàn)在哪些方面？難度降低還是效率提升？

ii. 前端研發(fā)是否提效，具體表現(xiàn)在哪些方面？難度降低還是效率提升？

iii. 跟外部系統(tǒng)集成是否提效？

iv. 跟業(yè)務(wù)無關(guān)的通用能力是否有足夠支撐？

v. 針對測試，質(zhì)量是否提升？測試工作量或回歸量是否有提升？

vi. 驗證低代碼擴展能力，無需額外設(shè)計。任何研發(fā)人員寫的邏輯都具備高度擴展能力

b. 引入低代碼平臺，對研發(fā)流程有沒有改變，是否有提效

i. 后端研發(fā)、前端研發(fā)、測試之間協(xié)同效率是否有提升？

ii. 業(yè)務(wù)研發(fā)與通用能力研發(fā)之間協(xié)同效率是否有提升？

3. 證明低代碼平臺符合咱們公司未來發(fā)展的要求

a. 公司的行業(yè)特性如何跟低代碼平臺結(jié)合

i. 是否能遵循公司UI規(guī)范，涉及主題、布局、UI規(guī)范、logo等各種細節(jié)

ii. 行業(yè)組件擴充：能否基于低代碼擴充屬于自有的行業(yè)組件，在設(shè)計器中增加自有組件如頁面、圖表等

b. 促進銷售

i. 迅速完成業(yè)務(wù)需求的概念驗證（POC），以快速響應(yīng)市場變化和客戶需求。

c. 公司產(chǎn)品化發(fā)展

i. 研發(fā)專注標品，研發(fā)擴展包實現(xiàn)個性化，能否做到實施客戶時不需要改標品？

ii. 研發(fā)專注標品 ，非研發(fā)無代碼個性化實施，能否做到實施客戶時不需要改標品？

iii. 標品升級帶來的新特性，是否可以無縫給到每個客戶？

最后推薦下自己的低代碼產(chǎn)品數(shù)式Oinone，我們強調(diào)的低無一體的技術(shù)路線，一定能給您耳目一新的感覺。

首先，數(shù)式Oinone屏蔽了互聯(lián)網(wǎng)架構(gòu)帶來的復(fù)雜性。針對專業(yè)研發(fā)和公民研發(fā)提供不同的兩種方式：一種是面向公民研發(fā)的無代碼設(shè)計器，另一種面向?qū)I(yè)研發(fā)的低代碼研發(fā)框架。數(shù)式Oinone都是以元數(shù)據(jù)為基礎(chǔ)，兩種方式都是在產(chǎn)生元數(shù)據(jù)，通過使用代碼來描述元數(shù)據(jù)，可以無縫地與代碼銜接，并在不改變研發(fā)習慣的情況下降低門檻、提高效率，并進行工程化管理。

低無一體不僅僅是指兩種模式的結(jié)合，還包括兩種模式的融合應(yīng)用方式。具體來說，這種融合應(yīng)用方式可以分為兩種情況：

1、當開發(fā)核心產(chǎn)品時，主要采用低代碼開發(fā)，無代碼設(shè)計器作為輔助。這種方式可以提高開發(fā)效率和代碼質(zhì)量，同時保證產(chǎn)品的快速迭代和升級。

2、當需要滿足個性化或非產(chǎn)品支持的需求時，主要采用無代碼設(shè)計器，低代碼作為輔助。這種方式可以快速地滿足客戶需求，并且避免對產(chǎn)品的核心代碼產(chǎn)生影響。

簡單來說，低代碼模式適用于產(chǎn)品的迭代升級，而無代碼設(shè)計器則適用于滿足個性化和非產(chǎn)品支撐的額外需求。低代碼和無代碼模式在整個軟件生命周期中都有各自的價值，在不同場景下可以相互融合，發(fā)揮最大的優(yōu)勢。

想進一步了解數(shù)式Oinone給軟件公司帶來怎樣的效率提升，請看：多層次深度對比，一文看清數(shù)式Oinone帶來的效率提升

想進一步了解筆者對中臺的思考，請看：淺談企業(yè)IT架構(gòu)的十年困局