最近一段時間，“低代碼”概念特別流行，有的人特別推崇它，也有的人對此不屑一顧。
推崇它的人，認為它有很多優點，比如說能夠降低開發周期，提高系統開發效率，降低開發成本，學習成本低等。并且認為它會成為一個未來的趨勢。
而對其不屑一顧的人則認為，低代碼貌似提高了效率，實則應用場景要求很苛刻，一旦需要低代碼平臺不能提供的功能，就要折騰好大一圈，甚至還可能完成不了需要的任務。就好像有的人說的，用普通代碼花一周完成了100%的任務，而用低代碼一個小時就完成了99%的任務。那么剩下的1%呢？答案是，沒法完成。
那么，究竟低代碼到底有意義嗎？靠譜不？今天我們就來討論一下這個問題。
首先我們來看現狀，低代碼的現狀就是：概念很美好，實現很拉胯。
事實上，低代碼的工具十幾年前就有，比如說大名鼎鼎的Webmethods中就提供了一套圖形化編程工具，基于Java的Flow語言，通過簡單的圖形化操作，就能夠完成很多的任務。并且支持自己創建圖形化模塊，以及修改圖形化模塊中的代碼。用起來是非常方便的。但是這套東西賣得挺貴，至今也沒有特別流行起來，基本上也沒有什么開源軟件能夠達到Webmethods工具包的效果。目前也就是像Scratch這類哄小孩的圖形化編程工具比較流行。
而目前宣稱能夠大幅提高開發效率的各個低代碼平臺，實現都很一般，不僅實現的功能很簡單，不適用于一些復雜場景。而且生成的產品也非常難以維護或者是修改其功能。
例如某款流行的低代碼平臺，創建表單的時候，可以很輕松地通過頁面操作生成一張表單，而一張表單就會在后臺生成一張表。而生成的表既不具有正常在設計數據庫表結構時要考慮的表間關聯關系，也很難從表的自動命名中看出其實際意義。這意味著如果想基于這種自動生成的表去進行復雜的查詢功能開發，是非常困難的。
而類似于這種的問題還有很多。當然如果從產品的角度來講，這些實際的問題是可以逐漸優化的。所以這些問題只是暫時的。
低代碼最大的問題在于，一個項目的復雜度簡化，是有限度的。而對于不同的開發人員來講，所能接受的信息復雜度是不同的。
除去非常簡單的應用以外，大部分項目的需要都是比較復雜且具有很多自定義功能的。這就意味著如果一款低代碼平臺如果想兼容所有的功能的話，那么勢必要增加非常多的功能模塊。那么對于開發人員來講，與普通代碼的區別可能就是，普通代碼要記憶幾百個函數或接口，而低代碼要記憶一百多個模塊及其屬性和適用范圍。而這個學習成本，和可能出現的潛在問題，其實是差不多的。
固然我們可以將很多代碼模塊化，事實上這本來也是大部分程序員在做的工作一樣，開源的中央倉庫里諸多可直接引用的庫即是這一工作的成果，大部分時間，程序員們只需要知道哪些庫能夠完成自己的功能，并且閱讀一下其使用手冊就好了。
而如果把大部分功能組合起來，那么勢必會導致很多過程對于開發者而言成了黑盒，從而在需要修改的時候無從下手。
而如果組合的功能不夠，則開發者就需要學習更多的模塊。這兩者的本質是一樣的。因此低代碼的本質就決定了，它只適用于非專業人士，用一些通用的模塊化功能來完成自己的簡單需求。而對于專業人士來講，需要學習和了解的，則遠遠超出了低代碼平臺所能提供的功能。
當然，如果低代碼平臺真正流行起來之后，很可能會出現介于兩者中間的半吊子程序員。
這就好比是所有的手機品牌都在那里，各種配置甚至各個部件的廠商、參數信息都能很清楚的拿到。
但是對于大部分人來說，可能完全無法分辨，兩個1599的不同品牌手機，技術上來說，到底哪個好。所以經常會咨詢一些似乎很懂，但實際又不很懂的半吊子專家。最終隨便買一個專家推薦的品牌型號。
這種事情我們也會在選購電腦和買車的時候常見。
低代碼平臺普及之后，想必開發程序的時候，也就會出現大批的這類專家了。
喜歡本文的話，歡迎關注活在信息時代哦：）
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。