“滿地都是六便士，他卻抬頭看見了月亮”。

毛姆寫下的這句話時，那個為追求藝術的斯特里克蘭為追求心中的藝術夢，拋妻棄子，窮困潦倒，留下劃時代的藝術作品。

低代碼誕生，也是源于程序員對減少工作量的追求，工作之余能抬頭看看看月亮

所謂的低代碼，顧名思義，就是以不用或者很少用寫代碼的方式，來構建企業(yè)應用。一聽到不用寫代碼，很多人當然非常的歡迎。畢竟，請程序員來寫代碼是一件很費錢費時間的事情，鼠標點點，就把應用程序給構建好，是看起來很爽的事情。所以既有非常支持的一堆人群在，也有很反對的一堆人群在，這顯然是可以理解的。

上面這個例子，至少說明，如果有合適的工具，即使不寫代碼，也可以干很多的事情。低代碼開發(fā)應用程序，我們這里需要仔細定義開發(fā)是什么？才能夠理解低代碼的未來到底怎么樣。

關于開發(fā)，或者目前市場上關于低代碼開發(fā)程序，至少有兩種不一樣的觀點。第一種觀點，開發(fā)過程中依然會涉及到代碼，只不過代碼的生成是在后臺，由系統(tǒng)自動生成并且產生。

這種低代碼開發(fā)的方式，并不是什么新鮮玩意。在2000年以前，就有了Visual Basic， Delphi等很多著名的可視化開發(fā)工具。它們倡導和鼓吹的，其實也就是機器可以幫你寫代碼，所見即所得的。你自己不需要寫什么代碼。

這種開發(fā)方式成功了嗎？沒有。為什么呢？代碼這個東西，并不是一個好的抽象層面的東西，里面涉及了太多的細節(jié)。如果說低代碼就是系統(tǒng)后臺幫助生成代碼的話，只要有點問題，客戶還是要翻出后臺自動生成的代碼去改。Visual Basic和Delphi其實都無法逃脫這種命運。于是乎，可以看到未來必然是一地雞毛。因此，我們可以說，以系統(tǒng)后臺自動幫助用戶生成代碼的方式提供的低代碼平臺，前途是非常有可能一地雞毛的。

我們再回頭來看一下Photoshop這個例子。最終用戶在制圖的過程中，并沒有使用和接觸到背后的代碼，相反的，用戶使用的是系統(tǒng)提供的非常全面，細致而復雜的各種模塊。用戶正是用這些模塊提供的功能，完成了自己對圖像處理的創(chuàng)作。

這種創(chuàng)作也可以對應到低代碼市場來。低代碼的另外一個實現(xiàn)形式，我們不妨叫做搭建應用，以區(qū)別于生成源代碼的開發(fā)應用。平臺提供了大量豐富的可以定制的功能和組件，用戶則聚焦于自己要實現(xiàn)的業(yè)務邏輯，利用這些組件進行“創(chuàng)作”，搭建應用。

可以想象，這里只涉及到對已經實現(xiàn)很完善的各種組件的調用和組合，并不涉及到代碼本身，所以這種平臺的低代碼應用是可以做到零代碼搭建成功的。

這就是目前APaaS的概念。不同于SaaS直接提供應用，也不同于PaaS提供平臺，它的主要作用是給真正的應用提供各種各樣的組件。用戶可以在這組件的基礎上搭建自己的應用。

當然，這并不是說低代碼可以開發(fā)所有的應用，事實上幾乎每個APaaS在提供組件的時候都需要聚焦于某個行業(yè)某類應用，就像Photoshop聚焦的是圖像處理一樣。

在這個行業(yè)這類應用下進行深耕，用最優(yōu)秀的開發(fā)者開發(fā)出易用強大的組件，然后開放給更多的應用搭建者，以無代碼的方式進行搭建，這種方式的低代碼平臺，如果做好了，自然是前途一飛沖天。

而且這種方式搭建應用，和傳統(tǒng)的請專業(yè)開發(fā)者來給自己構建系統(tǒng)的好處是不言而喻的。通常來說，市場上并不缺乏開發(fā)者，但是對特定應用來說，比如說企業(yè)的ERP管理軟件，優(yōu)秀的開發(fā)者，同時還需要懂業(yè)務，是很寶貴的資源。很難做到每個企業(yè)都可以網(wǎng)羅一批優(yōu)秀開發(fā)者，投入足夠的時間進行開發(fā)給自己企業(yè)使用的系統(tǒng)，無論是時間成本還是錢，代價都是巨大的。

相反的，通過應用平臺APaaS的方式，公司可以集中市場上對特定領域的業(yè)務流程非常熟悉，同時開發(fā)能力也非常優(yōu)秀的開發(fā)者，開發(fā)出適用于這個行業(yè)這個領域這個業(yè)務的對應組件。

這些相關組件的開發(fā)并不容易。開發(fā)出高質量的組件往往意味著更大量的時間成本和金錢成本。然而，好處也同樣是不言而喻的。這些由既懂業(yè)務，又懂技術的人開發(fā)出來的組件，無論是專業(yè)性還是可用性都非常的高。

由于在APaaS這樣的環(huán)境下，這些組件得到了廣泛的復用。平均成本分攤下來，就不顯得那么的吃驚了。這樣，企業(yè)應用者可以聚焦于應用本身，通過APaaS平臺提供的組件來搭建自身的應用。APaaS平臺則通過給大家復用組件，不但分攤了成本，更能賺取豐厚回報。而這又會促成APaaS進一步升級其組件。良性循環(huán)得以形成。

當然，這種做法并非沒有缺點，一旦使用組件進行搭建，必然會遇到一些靈活性的問題。比如說我想做這個事情，如果我請專業(yè)人員專門為我開發(fā)的話，就是一個功能。如果我通過組件搭建的話，可能會落在幾個模塊里。

模塊化必然帶來靈活性的犧牲，然而和收益比起來，靈活性的犧牲并非是天大的問題。和模塊化帶來的各種好處比起來，這點靈活性的犧牲是可以容忍的。

所以，在我看來，低代碼如果是以系統(tǒng)幫助用戶生成代碼的方式來提供服務的，其結果很可能是一地雞毛。如果是通過APaaS的方式來提供豐富的模塊，用戶使用模塊來搭建應用程序的話，那應該有一番天地。

當然，這樣的APaaS平臺要是能成功的話，前提條件是其能夠聚焦特定的應用領域和行業(yè)，讓對業(yè)務非常熟悉的，好的開發(fā)人員，打磨出一套適合行業(yè)應用開發(fā)的，高質量的組件。

從這個角度看，低代碼顯然也并不是萬能仙丹，可以用來開發(fā)所有的軟件。但是我們可以看到，如果APaaS的平臺模塊化做得足夠好，搭建應用的時候對用戶的門檻就會足夠的低，這就能促進更多人來使用。最終低代碼開發(fā)是不是能一飛沖天，還是取決于APaaS平臺自身產品有多硬。