不要讓低代碼技術為“炒作的概念”背鍋

圖片來源@pexels

近期，突然又火起來的“低代碼”可謂是賺足了人們的眼球，大家各抒己見，也不乏針鋒相對的意思。當我看到這些爭論的第一反應，是非常高興的。為什麼呢？古時的治國之術有百家爭鳴，如今為低代碼也有“諸子論道”，這本質上是一件有助於推動低代碼發展的事情。

但凡事都應該有個邊界，我們在討論低代碼的時候，如果關注點放在了超出邊界之外的事情上，對於低代碼本身而言是不利的。業內的朋友們一定知道，關於低代碼的熱點不止發生過一次，然而多數是曇花一現之後即戛然而止。由於我本身也是低代碼行業從業者，ZOHO的低代碼產品已經迭代十多年，正好借這個機會與大家分享一些拙見。

追溯這次爭論的起源，貌似是來自釘釘落地低代碼應用開始，業界巨頭的每一個動作都能牽動整個市場的反應。有人説，低代碼革命來了，我覺得這未免有點誇張炒作的嫌疑。實際上，低代碼這個概念早已有之，只不過它的定位處於不上不下的中間地帶，發展這麼多年還是不温不火的狀態，也情有可原。

低代碼的起源，還得從上個世紀八十年代説起。1980年，IBM的快速應用程序開發工具（RAD）被冠以新的名稱——低代碼，由此，低代碼的概念首次面向大眾。低代碼是英文“Low Code”的翻譯，當然，此“Low”非彼“Low”，它意指一種快速開發的方式，使用最少的代碼、以最快的速度來交付應用程序。

幾乎所有的低代碼開發平台有兩個共同特點，這兩個特點的演化也決定了低代碼平台的走向：

1. 編程語言

低代碼並非無代碼，在應用開發中，完全脱離代碼去執行腳本、完善業務邏輯是不太現實的。低代碼開發平台通常會有一套語言邏輯，用於補充不足，幫助執行應用的業務邏輯，使應用更加完整。

為了瞭解現在的低代碼，我們需要從編程語言開始——低代碼意味着將人為的編程轉換為機器語言的過程。正如我們所知道的，計算機只能理解二進制數，編程語言成為了人和機器之間的橋樑。起初，這些語言是基礎語言，功能有限，它們以諸如Write、Display等詞彙開頭，比如在PASCAL中輸入命令“Writeln “Hello World!””，將通過二進制指令轉化為“Hello World”顯示在屏幕上。

到這裏，就會出現一個問題：為什麼這些語言從一開始就沒有設計為可模仿拼寫呢？其實是因為當時技術的限制。如今，速度更快的微處理器出現、硬件性能的成倍增長，同樣，語言設計也發展到用更少的代碼獲取更多成果的階段。

2. 圖形用户界面（ Graphical User Interface）

這也是低代碼最為顯著的特點。相比於傳統的敲代碼方式，低代碼將大多數字段進行封裝，將原本晦澀的代碼字段形成直觀的圖形界面，而開發人員只需要在圖形用户界面拖拽相應的模組即可進行開發工作。

圖形用户界面作為一種可視化開發技術，能得到長足發展也得益於硬件設備的迭代更新，例如處理器、顯示技術等等。隨着微處理器的出現，以及屏幕從單色到如今的彩色LED和OLED的發展，都讓圖形用户界面有了巨大的進步。也正是這個特點的發展，為“公民開發”奠定了基礎。

在近40年的發展中，低代碼主要經歷了兩個階段：

第一階段：1980-2015年，低代碼應用平台市場發展比較緩慢，表現亮眼的平台少之又少。但是，當今低代碼領域的領導者產品，諸如Outsystem、Mendix、Zoho Creator等均誕生在這一時期，國內的低代碼產品尚未完全成型，但是眾多種子選手也是在此期間生根發芽，為以後的低代碼發展打下了基礎。

第二階段：2015-2018年，低代碼市場開始升温。2015年，AWS、Google、Microsoft和Oracle等巨頭也開始入局低代碼領域，2018 年西門子宣佈以 6 億歐元收購低代碼應用開發領域的領導者 Mendix 、快速應用開發的低代碼平台 OutSystems 獲得 3.6 億美金的投資，低代碼平台市場開始火爆起來。

現在，低代碼產品在市場上究竟扮演着什麼樣的角色呢？正如前文所説，其本身不上不下的尷尬定位讓它也非常無奈。舉個例子，我們現在經常會説到企業數字化轉型，低代碼產品作為一種快速應用開發工具應該被青睞，然而現實是，員工拿低代碼產品做了一款讓大家叫好的食堂排隊管理應用，但是想用低代碼產品做一款像樣的ERP系統，卻大有力不從心的感覺。

説到這裏，就觸及到了本次低代碼之爭的論點之一：低代碼到底有沒有價值？答案是肯定的。

我們首先要明確兩個概念——專業開發者與公民開發者。專業開發者，簡單來説就是在代碼中耕耘的程序員們，而公民開發者可以是想要開發應用的任何人。表面來看，低代碼平台彷彿面對的僅僅是公民開發者，實則不然。

低代碼產品的兩個特點就是其本身的核心價值：可視化的共通語言和自我學習發展的能力。

低代碼平台的誘人之處在於它可視化的開發形式，為開發者提供了不同於傳統編碼的界面，通過拖放式操作即可將各個字段進行部署。另外，低代碼開發平台可以使用可視化建模方式來驗證應用邏輯，這無論對於IT人員、還是業務人員來説，都是一種極好的交流方式。

另外，當低代碼的編程語言觸及到機器學習領域，也會讓圖形用户界面更加直觀、使用更少的編程語言實現更多的功能，在快速演進的過程中，我們甚至可以期待通過語音命令模式構建應用程序，試想一下通過各類語音助手來幫你搭建一款應用程序，是不是就很興奮？由此看來，低代碼的未來不可限量。

實話實説，低代碼工具雖談不上萬能，但它非常強大。對於一些流程複雜的系統來説，即使低代碼會存在着一些侷限性，它也可以作為系統開發的補充手段，在小範圍、小規模、流程簡單的場景下，根據業務需求去搭建應用程序。但千萬不要因此被限制了想象力，比如特斯拉僅25人花了4個月就做出一套ERP系統，就是當時的CTO Vijayan在梳理完業務流程後，用低代碼平台Mendix實現的。

所以，企業想把低代碼作為數字化轉型的主陣地完全沒有問題，一切以自身的實際需求而定，業務流程管理是第一要務，技術手段僅僅是應用的呈現方式。企業數字化轉型不僅僅是企業IT部門的責任，整個過程會落在每一個人頭上，低代碼產品給所有人提供了都能看得懂的語言，在實際執行過程中減少阻礙，加快數字化轉型進度，也未嘗不是一件好事。

計算機技術發展至今，代碼、編程依舊是應用開發的中流砥柱，但我相信，低代碼的出現一定是市場的選擇，國外的低代碼產品已經過長時間的打磨和積累，國內驟然颳起的低代碼風潮也絕非偶然。雖然它已經不是一個新概念，但我們還是應該以一種接受新事物的開放心態去迎接低代碼。

“企業IT應用系統實施或者數字化轉型，本質是管理問題和業務問題，不是技術問題。”這一點我是贊成的，這個意思不是讓大家去抵制低代碼產品。我認為，無論是專業開發者，還是非IT出身的業務人員，都應該去迎接低代碼。作為管理者，從更加簡單的技術平台着手業務和管理問題，行動起來一定會更加輕鬆一些吧！

最後，塵歸塵土歸土，雖然我希望關於低代碼的討論始終存在，但不希望它被過度炒作。如今，各路玩家藉着低代碼的風進入賽道，但也需要玩家捫心自問一下：玩得轉概念，真的能玩得轉低代碼技術嗎？

所以，我們應該將關注的重點放在技術本身，而不是概念。計算機編程技術的不斷髮展成就了今天的數字信息時代，雖然現在的低代碼更多是作為技術的補充手段，但我也同樣相信，它也能像編程技術一樣不斷完善自身，擁有不可限量的未來。