近兩年，從國外傳入的"低代碼"概念在國內愈演愈熱，對此有一定研究的人會發現低代碼平台數量正在逐日增加，一場搶奪"低代碼"市場份額的拉鋸戰正在上演。 可是比起國外大火的低代碼平臺，如Mendix和Outsystems，國內"低代碼"概念好像還沒有被完全普及，市面上也沒有一個耳熟能詳的低代碼平臺被大眾所熟知。

對於低代碼的爭論一直沒有停歇過，從這些爭論中，我們希望能夠分析出低代碼平台沒有受到廣泛關注的真正原因。 通過對國內現有低代碼產品的分析，我們也希望這篇文章能夠説明大家找到真正實用高效、值得被關注的低代碼平臺。

---

爭論一：使用門檻並沒有降低多少

很多使用過低代碼產品的人一定會發現，在開發應用時，特別是複雜應用，最後還是逃不開寫代碼。 這也是「低代碼」這個名字所詮釋的，「低」只是代表了使用的代碼量降低了，但並不代表完全不用一行代碼就能獨立開發出一個應用來。

這也是為什麼低代碼沒有被普及的原因之一。 簡單的應用開發者只需要下載模版進行修改或者通過已有元件進行搭建。 但遇到複雜應用時，開發者還是必須具備資料庫和代碼編寫的專業知識。 這樣看來，消費者的門檻並沒有降低。

很多平台因為自身「低代碼」的屬性，最終需要藉助代碼來完成開發。 當然我們也發現有個別例外。

比如iVX這一平臺，雖然也提供代碼編寫功能，但是憑藉它功能和邏輯的完備，複雜應用的開發也可以做到不使用一行代碼。

其實這是因為iVX從一開始的定位就是一套"開發語言"，因為iVX直接對原生開發邏輯進行了優化，"去掉程式語法，保留程序邏輯"，學習者掌握的是完整的開發技能，而不是元件拼接模式，即使處理複雜應用也不需要代碼的輔助，與其他低代碼平臺相比，自然而然它的使用門檻是最低的。

---

爭論二：開發效率並沒有提高

就爭論一的門檻問題而言，"絕大多數低代碼平臺要求消費者有程式設計基礎"意味著"使用者不僅要會寫代碼，還需要花時間學習使用這些平臺"，所以便會看到"程式師不喜歡也不想使用低代碼平臺"的現象。 因為相比於繼續使用自己熟悉的方式進行開發，去學習一種新的方式需要花費大量的時間。 誰也不能保證這些花費的時間最終能在低代碼開發過程中節省回來。

另外，程式師費勁使用低代碼平臺開發，後期發現還是需要使用代碼來解決問題，那這一切又是何苦呢？ 所以你會發現大部分低代碼的消費者還是開發小白，包括國外Mendix、Outsystems的大客戶也是使用外包模式，真正的程式師依舊在寫著代碼做開發。

當然，對於程式設計小白、或者開發專案是簡單的、模式化的應用而言，開發效率絕對是成倍提升的。 這也是目前市場上消費者對低代碼最大的需求所在。

那難道對於程式師而言，低代碼就真的完全不值得被使用了嗎？ 當然不是。 像之前提到的iVX，它是一套完備的開發語言，也就意味著，只要熟練掌握了它，就不需要再去花時間學習其他的語言了。 同時，它的可視化操作介面能夠為使用者節省大量的開發時間。

---

爭論三：只能開發簡單的應用

想必看過討伐低代碼文章的讀者一定會看過這一條評論，低代碼工具只能用於一些簡單的應用開發，它自己本身的特性就決定了這一點。 沒錯，絕大部分低代碼工具都把自己定位成"企業應用開發工具"，提供表單、流程圖等基本模型，使用者若是想要開發複雜的、個人化的應用，需要花費大量的時程去研究，或者直接在平臺上選擇定製服務。

跳脫出流程圖、表單這些企業應用，市面上還有那麼多低代碼工具無法滿足的其他應用需求（如：小遊戲、小程式、3D動效應用等）。 這也是為什麼低代碼工具沒有得到普及的原因之一。 它們的特性是為企業應用開發提供便捷，但是由於自身的缺陷，使得只能用於開發簡單企業應用。

在我們的調查中發現只有少部分低代碼平臺提供各種應用的開發功能。 牛刀作為國內老牌的低代碼產品，功能相對較完善。 借鑒了國外產品的"畫代碼"功能，通過流程圖去實現一些代碼邏輯。 但是在複雜的開發部分，還是需要藉助代碼的支援。

iVX自稱是「零代碼可視化程式設計」工具，也就是說在「低代碼」概念上更進一步，實現了不使用任何代碼也可以製作出各種複雜的應用。 在其平臺上也發現了很多它們開發出的有趣作品，感覺是對"低代碼"的一個突破，這裡不再過多贅述。

---

總結

針對以上三個最大的爭議的討論，我們發現"低代碼"的未來其實也並非一片灰暗，只是因為大部分平臺都在集中搶佔小部分的市場份額，滿足小部分的市場需求（企業的表單、流程圖等應用），而忽略了其他的應用類型和使用場景。 就目前看來，iVX和牛刀在功能豐富性方面做的相對不錯。 尤其是「零代碼」特點的iVX，雖然還沒有完全打開市場管道，獲得大眾的認識，但是相信在自身"語言屬性"和"可視化編輯"的特點下，通過不斷的維護與優化以及後期的宣傳運營，一定會被更多人熟知與喜愛。 我們相信國內的低代碼市場未來可期。