低代碼甚至是零代碼工具一直被人非?？春煤妥放?，尤其是在云技術(shù)各種催生的背景之下，人們總是期望有一種工具或平臺能夠快速實(shí)現(xiàn)應(yīng)用開發(fā)和部署，不寫代碼或者寫少量代碼就能夠?qū)崿F(xiàn)客戶的需求，對軟件廠商或云廠商來說都是省心省力的事情。而最近特斯拉ERP開發(fā)用了低代碼工具（平臺）的消息在坊間一直流傳，導(dǎo)致人們對低代碼工具又掀起了一股狂潮，甚至歡呼低代碼工具的春天來臨了...

冷靜下來想一想，低代碼工具無非就是通過工具/系統(tǒng)自帶的組件組合拖放快速生成我們所需要的應(yīng)用，在特定的環(huán)節(jié)里還能夠允許寫入少量的腳本代碼來擴(kuò)充一定的功能，這類工具目前存在不少。典型的就是OA廠家開發(fā)的系統(tǒng)定制部署工具，只需要在后臺做做頁面UI設(shè)計，套一下固定模板，設(shè)置一下目錄，很快一套OA審核流程的頁面就出來了，功能強(qiáng)大到足以應(yīng)對大部分的審核需求。就連跟SAP系統(tǒng)做RFC接口的對接，都只需要做一下簡單地配置就能夠成功調(diào)用并拉取到數(shù)據(jù)。

想想都覺得很靠譜，感覺程序員都要沒飯吃了對不對。

但，這真的靠譜嗎？

1、不要迷信這些工具。

低代碼的前提是廠商做了非常大量的封裝和功能模塊，這些都是超大量的代碼堆出來的，而且是需要經(jīng)年累月的累積才有的成果，這個非?？简?yàn)軟件廠商的技術(shù)能力。很可惜，目前國內(nèi)的廠家技術(shù)都達(dá)不到讓人放心可用的“低代碼”階段。

2、靈活性不高。

雖然它們在一定程度上可以減輕代碼量，快速部署應(yīng)用，但這些應(yīng)用幾乎千篇一律，就連上傳個Excel數(shù)據(jù)文檔，它上傳的步驟都一模一樣。

很榮幸我就被這樣的工具坑過，前東家買了一套類似“低代碼”的OA開發(fā)工具，一個簡單的上傳Excel的功能要點(diǎn)七八個鼠標(biāo)，跟開發(fā)人員反饋進(jìn)行用戶體驗(yàn)上的優(yōu)化，被告知行不通：軟件廠商根本沒有做這個上傳Excel窗口的定制后臺，加上沒有源碼，所以實(shí)現(xiàn)不了。

于是乎用這個低代碼工具做的Web應(yīng)用系統(tǒng)，操作、UI、權(quán)限設(shè)置、框架、模板幾乎雷同，讓人審美疲勞和無感，架構(gòu)技術(shù)缺陷，用戶抱怨連天。

3、功能局限。

面對國內(nèi)復(fù)雜多變的企業(yè)業(yè)務(wù)環(huán)境，僅依靠拖拉幾個控件和模塊，用有限的代碼量來支撐是絕對不可能的。做過外包和企業(yè)技術(shù)人員的都很清楚，很多時候一套系統(tǒng)最根本的命脈就是那套“源碼”，只有它才能盡最大可能實(shí)現(xiàn)企業(yè)想要實(shí)現(xiàn)的功能，而不是那些什么封裝好的接口和模塊，畢竟那些都比較粗獷和有限。

所以你看SAP為何能夠得到廣泛認(rèn)可？

1、它本身足夠強(qiáng)大。

后臺功能的配置以及原生支持的業(yè)務(wù)模式多到讓人懷疑人生，配置靈活性極強(qiáng)；

2、它提供了自由的系統(tǒng)開發(fā)能力。

SAP有自己獨(dú)特的開發(fā)語言，幾乎所有畫面都能查看到源碼，也能做一定程度的修改，可以做到不停機(jī)部署（熱部署）；部署SAP的企業(yè)可以根據(jù)自己的業(yè)務(wù)需要進(jìn)行二次開發(fā)而不通過SAP原廠的介入，就好比如你買了一套Visual Studio開發(fā)工具。

你知道自由的系統(tǒng)二次開發(fā)能力對于制造業(yè)/供應(yīng)鏈管理的企業(yè)有多么重要么？你知道這些企業(yè)業(yè)務(wù)的最大特點(diǎn)么？——多變！

好，就以上2點(diǎn)，其他ERP有誰能做得到的？SAP這套系統(tǒng)才是所有企業(yè)應(yīng)用廠商應(yīng)該仰望的目標(biāo)，這才是當(dāng)下“低代碼工具“的標(biāo)桿。

（想到這里，我特別感慨：啥時候才有屬于中國人自己的編程語言啊？別提易語言，謝謝！）

這也就是為什么專業(yè)的視頻工作者剪輯視頻的時候都喜歡用專業(yè)的Adobe Premiere Pro和Final Cut Pro，而不會用什么愛剪輯、剪映等小軟件。難道還不明白嗎？平臺最重要，而不是簡單的工具。

其實(shí)阿朱說的很對：企業(yè)應(yīng)用廠商現(xiàn)在做的所謂的低代碼工具，其本質(zhì)和30年前的雅奇MIS、OA、BPM這些東西沒啥區(qū)別。