軟件正在吞噬世界，但世界上隻有0.5% 的人會編寫軟件。另一方面，超過 20 億人知道如何使用電子表格。

随着 Zapier 和 Airtable 等成熟無代碼平台的出現，運用無代碼進行開發的人數在急速上升——這讓開發人員十分焦慮。

1979年，VisiCalc 正式面向市場推出。作為 Excel 的前身，VisiCalc 允許非開發人員以點擊的方式構建自己的程序。

VisiCalc 在當時并不像預編譯的會計軟件那麼容易使用。早期的評論者指出，這是十分關鍵的，“因為 VisiCalc 不是預編譯的，這使它比同類程序強大、靈活得多。”

換句話來說，這相當于擁有一個較低門檻的無代碼平台允許用戶解決無數其他用例。

StackOverflow 的年度調查發現，VBA（ Excel 的編程語言）多年來一直是最不受開發者歡迎的語言之一。這些工具在生産環境中通常很難遷移，因為他們缺少通用軟件的“版本控制”“測試”等關鍵功能。

無代碼自誕生以來也常伴随着不少的争議。較為早期時，部分開發人員将整個無代碼系統視為無法擴展，服務于業務關鍵型工作流的原型平台，認為無代碼隻能構建簡單的應用，過于局限從而沒有較大的發揮空間。

為什麼開發人員會拒絕無代碼

無代碼，僅其名稱是不是就意味着開發人員的工作将被自動化？事實并非如此。

據統計，目前中國會寫代碼的開發者隻有700萬，業務管理者會用 Excel 的可以達到2個億。即使随着開源、API 經濟以及更多技術出現，數字化人才缺乏依舊是企業轉型的一大痛點。麥肯錫今年的一項調查報告稱，87% 的企業已經看到開發人員短缺，或者預計幾年後會出現短缺。

抛開對自動化的擔憂，缺乏可擴展性才是開發人員對當今無代碼平台擔憂的關鍵點。

大多數開發人員認為，很多無代碼MVP（ Minimum Viable Product ，憑借其快速測試和試錯，幫助許多企業獲得産品在市場中的快速反饋，并以此方法循環和快速叠代，以最小的代價去獲得産品最大化成效）都具有 “ complexity wall ” 。即當無編碼人員将 MVP 交給開發人員以進行進一步增強時，開發人員要麼必須編寫大量不穩定的中間件，要麼完全重新重構新的中台系統。例如：

• Airtable（低代碼工具，可以讓非技術性的終端用戶使用類似電子表格的界面來構建自己的關系型數據庫）當用戶希望将現有的的數據遷入 Airtable 時，開發人員常被 Airtable 嚴格的速率所限制，即使從 Airtable 到數據庫大規模遷移，也必須替換無代碼邏輯 UI 層。
• Zapier（無代碼工具，可以整合兩個或以上應用程序，自動執行重複性工作，從而提高效率）。開發人員希望在版本控制和測試中分層，但 Zapier 缺乏對這些基礎功能的支持。開發人員必須将 Zapier 中的所有内容重建為 AWS lambda（一項計算服務，無需預置或管理服務器即可運行代碼）。

大多數無代碼平台中的 “ complexity wall ” 阻礙了無代碼的大規模投入使用。

無代碼如何變得更具可擴展性

很多企業都承認無代碼為公司帶來了積極的影響。無代碼可以賦能開發人員提升開發效率，将更多時間和精力專注于核心産品，并允許業務人員自主學習搭建符合業務需求的應用系統。

但還是有部分企業拒絕大規模使用無代碼，其主要原因可簡單概括為：他們認為無代碼缺乏可擴展性和可維護性。

可擴展性

可擴展性決定了用戶在生産系統添加新功能的難易程度。開發人員如何輕松地将新功能添加到工作流程中？是一定要寫中間件嗎？還是完全重新平台化？

無代碼工具又該如何實現可擴展性呢？

一、通過良好的 API 和 Webhook 提升協同能力

由于無代碼數據存儲很少能像 SQL 那樣被訪問，開發人員必須編寫大量中間件來從一個存儲遷移到另一個存儲，并且時常擔心擔心數據是否同步，在次過程中還會有 API 的速率限制，以及較低的安全性等問題。

意識到這一點後，很多無代碼廠商都通過設置良好的 API 和 Webhook 以提升協同能力。

以無代碼廠商輕流為例。在輕流，Webhook 位于「流程中」，可以在流程的任意環節向第三方系統伸出「hook」，推送相關事件，拓展了「流程」的便捷，并且可以觸達到外部的第三方系統。同樣的，輕流還推出了 OpenAPI ，任意的系統，可以在任意時間對輕流做系統數據的調用。API不僅可以用于系統的連接，也可以做系統的存量備份，在輕流提供的安全防護下進一步的對數據進行再次的保障和容災備份。

二、在需要時提供回退到代碼編程的方式

開發人員通常希望能夠使用代碼來處理工作流中的複雜任務，而無需搭建新的平台。腳本在無代碼平台中很常見，但最好的腳本形式常常涉及對多種語言的支持（尤其是用于錯誤檢查的 TypeScript ）、對庫（npm模塊）的支持和版本控制。

最好的例子是 Pipedream（一個集成和計算平台，借助 Pipedream ，開發人員可以利用 700 多個預構建的集成應用程序并編寫任何Node.js、Python、Go 或 Bash 代碼，以使用自己的自定義邏輯擴展集成），它提供讓用戶将各種 API 連接在一起的功能，并且在你需要時進行代碼級控制，在你不需要時不需要代碼（直接進行簡單的 UI 操作）。

在此案例中，Pipedream 用戶可以 通過UI界面快速選擇一種方式獲取到 Google 表格的數據，然後根據需要修改代碼。Pipedream 還允許開發人員使用大多數其 npm 軟件包，與其他代碼沙盒不同，這些代碼沙盒通常嚴重限制可以使用哪些類型的庫。Pipedream 還将很快推出對 Python、bash 和 Golang 運行時的支持。

三、良好的開放性

無代碼系統一定不能是封閉的系統，它更應該與其他系統做好連接和交互。

僞開源無代碼産品無法維護，當廠商進行代碼更新後，會産生代碼一緻性問題，導緻代碼差異沖突，造成不可逆後果。但無代碼産品的接口能力和 API 能力需要重點關注，所以，在無代碼産品上實現的二次開發非常類似“插座”和“積木”，把二次開發定義的代碼塊，同 API 和無代碼産品進行交互。

可持續升級

可持續升級，決定了業務關鍵系統已經投入生産後對其進行叠代修改的難易程度。

現如今，運用無代碼構建初期原型是很容易的，但是，一旦投入生産系統後進行叠代是非常脆弱和易碎的。

這是當今無代碼被歸入簡單的工作流的最大原因之一——不是因為不可能構建複雜的工作流，而是因為随着時間的推移，任何非微不足道的複雜性都是無法管理的。

我們需要将更多的概念從 DevOps（一組過程、方法與系統的統稱，用于促進開發應用程序 /軟件工程、技術運營和質量保障QA部門之間的溝通、協作與整合） 引入無代碼，從版本控制和可監控開始。

一、版本控制

較為理想的狀态是：一旦無代碼工作流成為業務關鍵型并部署到生産中，用戶就能夠對其進行版本控制。

因此，開發人員可以将系統的配置（模式、邏輯等）聲明為代碼，以及使用 git（開源的分布式版本控制系統）進行版本控制，這樣就能夠擴展到盡可能多的系統——不僅僅是數據結構，還有邏輯，甚至是無編碼的UI界面。

二、可監控性

當今的無代碼中，邏輯在平台上廣泛分布，很多無代碼平台都在構建自己的邏輯模塊。但當産品出現問題時，開發人員很難了解事情的來龍去脈。如果不知道系統中發生了什麼問題，就沒辦法對其進行改進。

所以很多無代碼平台都大力提倡功能的可監控性。例如，SwitchboardSwitchboard（雲共享辦公空間，通過将團隊和工具聚集在一起進行并肩協作，為遠程工作提供動力）正在為 Zapier 和 Integromat（RPA廠商，其産品可以幫助用戶将十多種日常辦公軟件的，數據輸入、提取、上傳、下載等操作流程實現自動化 ）構建錯誤監控和事件管理平台。此外，無代碼平台還為用戶提供更多的日志記錄， 可以更輕松地與 Datadog 等警報堆棧集成的 API 。

無代碼，不僅僅是MVP

無代碼給很多企業的初印象，是構建 MVP 的利器。很多公司常常在業務拓展期利用無代碼平台自研的套件來構建産品的初期原型，快速核驗核心功能，以降低開發成本。但當無代碼平台能夠賦能開發人員對其産品進行擴展修改時，無代碼同樣可以用于構建 MMP（ Minimum Marketable Product ）幫助企業縮短開發時間，解決業務痛點。

在無代碼産品的應用與實踐中，越來越多的無代碼廠商已經意識到産品缺乏可擴展性所帶來的弊端，并通過多種方式來提升平台的可擴展性，不斷拓寬無代碼平台能力邊界。

數字化浪潮下，企業信息化建設必然需要借助無代碼技術提升系統開發效率，加速企業數字化轉型。無代碼的未來将不可估量。為什麼開發人員都要了解無代碼？

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!