作為2021年技術類中的頂流，低代碼的火爆并非空穴來風，根據IDC預測：“2024年將有65%的應用軟件通過低代碼開發。”

據企業網D1Net觀察，將低代碼用于軟件開發的CIO不在少數，但是其中既有悲觀者，也有樂觀者，究竟CIO是如何看待低代碼的，低代碼選型過程中要注意哪些關鍵點，考慮哪些側重點，又有哪些注意事項呢，接下來筆者將一一道來。

CIO眼中的低代碼

低代碼的優勢顯而易見，能夠幫助企業降低開發人員的門檻，縮短應用開發時間，也能節約很多開發成本，大部分企業都已開始應用低代碼敏捷開發技術。但是在實際應用的過程中，企業網D1Net發現，CIO們對低代碼的態度各有不同，既有悲觀者，也有樂觀者。

CIO中的悲觀者認為：低代碼開發平臺顯得有些雞肋，開發能力強的不需要，開發能力弱的即使用了也做不出功能完善的系統。低代碼平臺的初衷是抽象常用的CURD(增刪改查)功能，降低開發門檻，但是隨著周邊生態的快速發展，缺點也逐漸顯露出來——低代碼平臺的發展速度很難跟上周邊技術日新月異的發展，覆蓋實際生產中比較復雜和個性的應用場景，乍一看去很美麗，進入深水區以后就會發現到處都是坑。

這位CIO認為：目前來看低代碼開發適配企業復雜的應用場景還是個偽命題。他建議企業用低代碼自研應用時，要做好心里準備，好的結果是企業能接受項目后期的進度停滯，差的結果是項目推翻重構。即使擁有低代碼開發源碼，甚至自己可以更新低代碼開發工具的功能，依然要面對2-3年后主流技術更新換代后要償還的更新債務。

而樂觀者認為：低代碼和無代碼對于研發效率的提升非常明顯，已經有了大規模應用，而且案例越來越多。某公司研發負責人表示：“從開發人力來講，低代碼平臺收益很明顯，以前很多開發排期不允許的需求，現在可以自助解決，這是一個從0到1的突破。”

某公司CIO則直接表示：“公司培養二次開發人員，但是不會培養全棧開發，去從零開發一個系統。如果一定要開發自己的系統，一是這個系統在市面上找不到，二是可以用低代碼平臺開發完成。”

而喜茶數字化高級副總裁沈欣則在演講中提到：“我們在系統選型時要求軟件開發商自己要有自己的低代碼環境：一是能提升響應速度，在業務部門的想法發生變化時能夠盡快改正;二能降低我們的成本，因為低代碼平臺只需要進行靈活配置就可以了，一眼就能看出它用了多少工時，價格會非常透明。”

而理智的CIO則認為：低代碼平臺主要有兩類應用場景，一是從0到0.5的場景，公司沒有現成的系統，用低代碼搭建，可以湊合用;二是快捷應用，例如調查問卷，要臨時收集一些數據，上線快，修改快。然而，對于那些經典、復雜的應用，低代碼平臺恐怕難當大任，后期的瓶頸會越來越多，應盡量避坑。

低代碼選型的六個要點

低代碼平臺在前期確實能讓CIO們嘗到諸多甜頭，但是項目后期投入產出不成比例也是CIO們普遍擔憂的。某低代碼公司的CEO曾向企業網D1Net表示：“CIO們最擔心的是低代碼平臺只實現了80%的功能就被迫停止，另外的20%無法實現，或是需要付出很高的代價，必須由原廠服務來完成剩余的項目。”

有了這樣的擔心，低代碼平臺的選型就顯得至關重要了。目前低代碼平臺在中國尚無明確統一的行業標準，市場上的平臺靈活性參差不齊，如何找到適合企業自身的平臺對于CIO而言是一個非常大的挑戰。

Gartner劃定了低代碼的四個特性：模型驅動、可視化開發、表達式語言、腳本語言。筆者認為，軟件工程和開放集成也至關重要，這恰恰是中國企業需要的。

1)模型驅動。使用模型驅動的低代碼平臺，用戶手冊會講怎么做數據建模和處理，包括怎么定義實體、實體間關系、主鍵、唯一性、索引、數據怎么訪問、篩選、分組、統計等等，還提供SQL或類似擴展。

2)可視化開發。可視化開發不是拖拉拽做個界面，而是有完整的可視化編程語言系統，能夠編寫業務處理邏輯。

3)表達式語言。表達式語言有些類似Excel里的公式，例如各種操作符、內置函數，可以做一些比較復雜的計算。

4)腳本語言。腳本語言就是用JavaScripts、Python、Java等做擴展，也就是支持專業的編程語言。優秀的低代碼平臺會把工程復雜性封裝好，而開發者無需配置和部署環境，寫完代碼一鍵發布就可以立即運行。

5)開放集成。企業軟件是相互依賴和集成的，因此還需要具備能夠調用外部API和開放API給別人的能力，這也是大多數CIO最關心的。低代碼平臺如果沒有這兩方面的功能，開發出來的應用相互之間無法連通和集成，必將成為技術債。

6)軟件工程。軟件開發都會出現bug，低代碼平臺基本消除了語法層面的bug，但對語義層面的bug無能為力，而且業務需求也在時刻變化，所以，測試、debug、版本控制這些支持必不可少。

有些CIO認為，Powerbuilder和Delphi也算低代碼平臺，但是有過5年Delphi開發經驗的IT人告訴筆者，Delphi雖然實現了界面的可視化開發和數據庫的ORM，依然要寫很多Pascal代碼，不僅包括邏輯代碼，甚至把數據顯示在表格里都要寫代碼，其根本原因在于Delphi不是模型驅動。

相比之下Powerbuilder比Delphi要好一些，無需代碼就可以增刪改查，但是不支持實體關系，模型驅動能力也并不完整，沒有可視化的邏輯開發，因此這兩種語言都逐漸沒落。

實際上，今日的Mendix、OutSystems等專業的低代碼產品的能力，已經遠超二十年前PC時代的Delphi和Powerbuilder，并且也在逐漸提升人工智能和大數據方面的能力，這也是早期的產品所不具備的。

低代碼選型中的五個側重點

對于魚龍混雜的低代碼市場，前沈陽遠大集團CIO張瑩在接受企業網D1Net采訪時表示：“很多低代碼敏捷開發平臺給的也是表單和工作流，但實際上是在偷換概念。真正的低代碼敏捷開發平臺，控件要足，數據支撐要足夠多元化，要具備自主的ESB總線，要能與其他系統打通。”

張瑩認為低代碼平臺的出現，就是為了在企業應用ERP、MES、WMS、CRM、SRM等專業軟件時，彌補上游或下游之間的承接關系，因此更要有集成的概念。他強調：敏捷開發也需要上層信息化戰略規劃的支撐，需要界定BPM、ERP、WMS等各個軟件之間的界限，不能越界，這一點尤其重要。如果今天做個審批，明天做個流程，那就是頭痛醫頭腳痛醫腳了，對于CIO來說這是大忌。

在張瑩看來，國內和國外的低代碼平臺各有千秋，側重點各有不同。國外的低代碼平臺確實十分強大，但是更是一種純粹的開發工具，減少了用Java或.net在底層寫代碼的工作量，但是其受眾人群是架構師或專業開發人員，而中國用戶期望的低代碼平臺是快速實現，不需要專業的開發人員查bug、做注釋、寫語句等等基礎性的開發工作。

實際上，低代碼平臺對于一個企業而言，并不是一道單選題，而是多選題，側重點不同，選擇的平臺自然不同，這也是低代碼產品市場百花齊放的原因。

如果企業要統計年會服裝尺碼，統計哪些員工打了疫苗，這類用后就會丟棄的工具，OA或IM內置的無代碼工具就可以靈活實現。因此，要實現用后棄之的表單型功能，可以選擇OA或IM里的無代碼工具。

如果企業在信息化基礎層面并沒有那么扎實，側重點在于如何把流程和邏輯梳理清楚，而表單和實現只是第二個側重點，那么選擇炎黃盈動、易正等BPM類的低代碼平臺和工具可能更合適。

如果企業想選擇某些特定的業務軟件，需求靈活度高，表單之間有很強的關聯關系，數據量又很大，可以選擇那些擁有低代碼開發環境的軟件開發商，提升企業IT的響應速度，并降低研發成本。

如果企業要開發復雜應用，且市面上沒有成熟的產品，那么就需要參考上述六個低代碼選型要點，對國內外的低代碼平臺進行綜合評估，并且要結合這些平臺積累的企業所在行業的Knowhow，因為擁有行業Knowhow的低代碼平臺已經擁有現成的模型，因此開發速度的提升可能不止幾倍，而是幾十倍，會更具優勢。

如果企業內部是基于Excel的管理體系，受限于Excel的分發模式，安全系數低，需求的靈活度不高，差異性大等因素，而且隨著業務的發展越來越復雜，那么選型時可以選擇那些支持私有化部署的低代碼平臺，并且將其納入IT管控，作為業務數字化的重要手段，為業務部門提供高效的IT支持。

警惕低代碼平臺壁壘

為了推進低代碼，喜茶數字化高級副總裁沈欣先后與20余個低代碼供應商進行深入交流。在他看來，各家產品的技術代差并不大，也就6-8個月左右的技術差異，很快就能追趕上來，因此CIO們在選型時不必太過擔心。

沈欣強調：低代碼的關鍵壁壘在于應用的增值維度，這些廠商可能會通過打深、打通自身的核心生態來形成一些業務壁壘。例如A廠商打通了一個地圖軟件、支付軟件、IM軟件，那么用A的低代碼平臺可以非常簡單的將這些功能集成進來，但是用B或C的地圖、支付或IM軟件，要么不行，要么會花費很大代價，這是沈欣在選擇系統時遇到的最大的壁壘。

除此之外，沈欣提到，專業的程序員寫出來的代碼依然會存在bug，如果讓那些沒有太多開發經驗的入門級開發者做開發，低代碼平臺首先需要更強大的自動測試工具，還需要更加輕量級的DevOps體系，只有足夠靈活，才能不影響業務的開發。此外，高度靈活的低代碼平臺開發出的系統，還有可能面臨數據合規的問題，尤其是那些即將上市的企業，必須考慮到這一點。

最后是低代碼的文檔管理，很多企業在進行低代碼開發時往往會忽略這一問題，這恰恰是低代碼無法推進下去的直接原因，因為后期介入的開發者可能完全不知道之前的開發者到底做了哪些功能，因此，低代碼選型也需要考慮文檔管理的問題。