最近一段時間，“低代碼”概念特別流行，有的人特別推崇它，也有的人對此不屑一顧。

推崇它的人，認為它有很多優(yōu)點，比如說能夠降低開發(fā)周期，提高系統(tǒng)開發(fā)效率，降低開發(fā)成本，學(xué)習(xí)成本低等。并且認為它會成為一個未來的趨勢。

而對其不屑一顧的人則認為，低代碼貌似提高了效率，實則應(yīng)用場景要求很苛刻，一旦需要低代碼平臺不能提供的功能，就要折騰好大一圈，甚至還可能完成不了需要的任務(wù)。就好像有的人說的，用普通代碼花一周完成了100%的任務(wù)，而用低代碼一個小時就完成了99%的任務(wù)。那么剩下的1%呢？答案是，沒法完成。

那么，究竟低代碼到底有意義嗎？靠譜不？今天我們就來討論一下這個問題。

首先我們來看現(xiàn)狀，低代碼的現(xiàn)狀就是：概念很美好，實現(xiàn)很拉胯。

事實上，低代碼的工具十幾年前就有，比如說大名鼎鼎的Webmethods中就提供了一套圖形化編程工具，基于Java的Flow語言，通過簡單的圖形化操作，就能夠完成很多的任務(wù)。并且支持自己創(chuàng)建圖形化模塊，以及修改圖形化模塊中的代碼。用起來是非常方便的。但是這套東西賣得挺貴，至今也沒有特別流行起來，基本上也沒有什么開源軟件能夠達到Webmethods工具包的效果。目前也就是像Scratch這類哄小孩的圖形化編程工具比較流行。

而目前宣稱能夠大幅提高開發(fā)效率的各個低代碼平臺，實現(xiàn)都很一般，不僅實現(xiàn)的功能很簡單，不適用于一些復(fù)雜場景。而且生成的產(chǎn)品也非常難以維護或者是修改其功能。

例如某款流行的低代碼平臺，創(chuàng)建表單的時候，可以很輕松地通過頁面操作生成一張表單，而一張表單就會在后臺生成一張表。而生成的表既不具有正常在設(shè)計數(shù)據(jù)庫表結(jié)構(gòu)時要考慮的表間關(guān)聯(lián)關(guān)系，也很難從表的自動命名中看出其實際意義。這意味著如果想基于這種自動生成的表去進行復(fù)雜的查詢功能開發(fā)，是非常困難的。

而類似于這種的問題還有很多。當然如果從產(chǎn)品的角度來講，這些實際的問題是可以逐漸優(yōu)化的。所以這些問題只是暫時的。

低代碼最大的問題在于，一個項目的復(fù)雜度簡化，是有限度的。而對于不同的開發(fā)人員來講，所能接受的信息復(fù)雜度是不同的。

除去非常簡單的應(yīng)用以外，大部分項目的需要都是比較復(fù)雜且具有很多自定義功能的。這就意味著如果一款低代碼平臺如果想兼容所有的功能的話，那么勢必要增加非常多的功能模塊。那么對于開發(fā)人員來講，與普通代碼的區(qū)別可能就是，普通代碼要記憶幾百個函數(shù)或接口，而低代碼要記憶一百多個模塊及其屬性和適用范圍。而這個學(xué)習(xí)成本，和可能出現(xiàn)的潛在問題，其實是差不多的。

固然我們可以將很多代碼模塊化，事實上這本來也是大部分程序員在做的工作一樣，開源的中央倉庫里諸多可直接引用的庫即是這一工作的成果，大部分時間，程序員們只需要知道哪些庫能夠完成自己的功能，并且閱讀一下其使用手冊就好了。

而如果把大部分功能組合起來，那么勢必會導(dǎo)致很多過程對于開發(fā)者而言成了黑盒，從而在需要修改的時候無從下手。

而如果組合的功能不夠，則開發(fā)者就需要學(xué)習(xí)更多的模塊。這兩者的本質(zhì)是一樣的。因此低代碼的本質(zhì)就決定了，它只適用于非專業(yè)人士，用一些通用的模塊化功能來完成自己的簡單需求。而對于專業(yè)人士來講，需要學(xué)習(xí)和了解的，則遠遠超出了低代碼平臺所能提供的功能。

當然，如果低代碼平臺真正流行起來之后，很可能會出現(xiàn)介于兩者中間的半吊子程序員。

這就好比是所有的手機品牌都在那里，各種配置甚至各個部件的廠商、參數(shù)信息都能很清楚的拿到。

但是對于大部分人來說，可能完全無法分辨，兩個1599的不同品牌手機，技術(shù)上來說，到底哪個好。所以經(jīng)常會咨詢一些似乎很懂，但實際又不很懂的半吊子專家。最終隨便買一個專家推薦的品牌型號。

這種事情我們也會在選購電腦和買車的時候常見。

低代碼平臺普及之后，想必開發(fā)程序的時候，也就會出現(xiàn)大批的這類專家了。

喜歡本文的話，歡迎關(guān)注活在信息時代哦：）