終于有人把“低代碼”講清楚了！
一、背景
低代碼對于我本身而言是挺矛盾的，畢竟工作中我?guī)缀跤貌坏剿?span style="text-indent: 2em;">一開始接觸到低代碼的時候我也是有抵觸或者鄙視心理的，畢竟手寫代碼的快樂，沉浸式的那種感覺很少能體驗到了。
我也通過最近幾年的工作經(jīng)歷慢慢的對其有了改變，嘗試去接受它。于是一開始在北京的時候是把它當(dāng)作一個提效工具，做了簡單的低代碼實踐。但是后來，當(dāng)我對大規(guī)模分布式微服務(wù)等有了深入認(rèn)識后發(fā)現(xiàn)，一個企業(yè)的服務(wù)數(shù)量，業(yè)務(wù)場景豈是一個人能模擬得來的。
所以當(dāng)我需要去實踐分布式，企業(yè)級，高并發(fā)，大數(shù)據(jù)，這些內(nèi)容的時候我發(fā)現(xiàn)我好像無法真正構(gòu)建大規(guī)模的企業(yè)應(yīng)用服務(wù)。但是因為一些原因我希望盡快搭建仿真的企業(yè)大規(guī)模的微服務(wù)應(yīng)用，所以我開始了對低代碼平臺的探索之路。
關(guān)于我做低代碼的具體動機，以及技術(shù)選型等已經(jīng)在之前的文章中有所說明，這里不再贅述。所以本文就簡單聊一聊我對于低代碼的理解和我在設(shè)計低代碼平臺的一些理念。
二、對低代碼的理解
2.1 為什么要做低代碼
這個問題我也問過自己，我做低代碼的目的是什么，我真正的訴求是什么，為什么我沒有采用其他大佬開源的東西選擇自己造輪子。當(dāng)我開始去看不同的低代碼搭建平臺的時候，我發(fā)現(xiàn)他們能做的工作確實可以降低代碼工作量，但是還不足夠。
基于腳手架的低代碼會綁定多個技術(shù)框架或者中間件，或者集成一些菜單權(quán)限用戶等數(shù)據(jù)表或者儀表盤，類似于OA這種。基于idea插件的則可以更靈活一點，但是也是需要去基于表構(gòu)建對應(yīng)的代碼元素。
或者其他框架類的諸如mybatis-generator，可以針對性的構(gòu)建DAO底層相關(guān)的代碼從而降低手寫的工作量。
但是對于大多數(shù)復(fù)雜的業(yè)務(wù)應(yīng)用其實上面的這些低代碼平臺是不夠用的，這些只生成到了方法級別的，而且只針對于增刪改查的簡單模版化操作，不夠靈活，更多情況下我們真正的復(fù)雜代碼需要的代碼元素遠遠不止service,entity,dto,dao,mapper,controller,facade。
當(dāng)我們需要繼續(xù)實現(xiàn)整個調(diào)用流程的時候發(fā)現(xiàn)工作量還是有不少的，比如要寫文檔，要定接口等等。對于前端代碼或者前后端一體的其實是一個道理，這里當(dāng)然只討論后端Java相關(guān)的代碼生成。
那么對于類似于工作流或者拖拉拽的低代碼平臺其實也不是我想要的，或者說不是最高優(yōu)先級的，因為我本身定位的用戶是開發(fā)者，首先是自己用的稍微舒服點再讓跟自己同類型的用戶用的舒服點。
所以，我仍然還是先從后端應(yīng)用為主，對于業(yè)務(wù)邏輯的編排或者業(yè)務(wù)流程的編排這里可能并不能完全用工作流或者編排工具拖拉拽實現(xiàn)，畢竟我只是去模擬仿真企業(yè)大規(guī)模微服務(wù)應(yīng)用，我也無法想象或者意淫服務(wù)之間的大多數(shù)交互流程，或者服務(wù)內(nèi)部的交互處理。
因為時間的關(guān)系或者跟我本身的訴求方向有偏差，這種類型的低代碼對我來說也不是特別合適，當(dāng)然他們這些先進良好的設(shè)計理念，落地實踐也給我?guī)砹撕芏囔`感。
在這其中我也了解了一些專門構(gòu)建低代碼平臺的創(chuàng)業(yè)公司，他們做的已經(jīng)非常好了，交互，api方面都無可挑剔，所以我認(rèn)為低代碼還是大有可為的。
那么又回到了問題的本身，為什么要做低代碼？因為市面上的低代碼實現(xiàn)其實還不夠低，還不夠讓人更少的寫代碼。所以對我而言我的真正訴求就是實現(xiàn)一個低代碼平臺，盡量覆蓋更多代碼元素，盡量寫更少的代碼。所以少寫代碼，唯快不破才是真理，當(dāng)然早點下班是正經(jīng)的。
2.2 低代碼帶來了什么
有些大佬或者有些相關(guān)的從業(yè)人員會追溯20年前的托拉拽式的低代碼場景。那時候就有人通過圖形化的界面幫助快速構(gòu)建企業(yè)要用的軟件系統(tǒng)了。
所以低代碼本身帶來的是整個軟件行業(yè)的改變，從圖形化到人機交互到數(shù)據(jù)處理，低代碼的一個顯著特征是提高軟件構(gòu)建交付效率，提高軟件企業(yè)營收。
當(dāng)然也讓更多人意識到隨著軟件技術(shù)的發(fā)展軟件系統(tǒng)的開發(fā)實現(xiàn)不再是高精尖，而是逐步變得大眾化，人們認(rèn)知應(yīng)用上更加成熟了，有種走進千家萬戶的感覺。
當(dāng)然另外一方面也帶來了一些惶恐，比如像我這樣開發(fā)了一個低代碼像是在革我自己的命，我有時候會想到我寫的低代碼會不會把我替代了。
更多的時候是很多程序員依然擔(dān)心因為低代碼會讓自己丟了飯碗，但是有些就不會，畢竟低代碼依然無法撼動他們在企業(yè)軟件開發(fā)的某一個角色。因此對于低代碼有抵觸心理的程序員對lombok等提高效率的工具組件依然抱有蔑視心態(tài)。
但是不管怎么樣，低代碼已經(jīng)存在了，而且發(fā)展了幾十年，從低端的到高端的，都沒有出現(xiàn)大的變革，對于作為程序員的我們該怎么做，我認(rèn)為可以保持開放和警惕的心態(tài)，時刻保持終身學(xué)習(xí)的態(tài)度，畢竟現(xiàn)在我敢說低代碼真的無法完全取代程序員。
2.3 低代碼的瓶頸
這里我也對低代碼的瓶頸簡單聊一下，說白了低代碼在很多有點動手能力的都可以隨手就來，但是能不能做好就不一定了。所以對于低代碼實現(xiàn)而言是很容易達到瓶頸的，比如基于某某技術(shù)棧體系，基于自研的框架體系，基于某某工具體系等等。
這里的瓶頸制約著企業(yè)無法發(fā)揮出低代碼的更多價值，或者我們僅僅只是看到了低代碼用自己的方式替代了人工的方式，而沒有看到它可以展現(xiàn)的其他潛力。
2.4 低代碼的缺陷
1、無法識別業(yè)務(wù)
對于低代碼而言它其實是一個平臺工具，或者平臺應(yīng)用，那么對于平臺應(yīng)用而言要做到非常強大肯定不能去識別業(yè)務(wù)，不能感知業(yè)務(wù)的存在。
那這樣的話，一個需求從產(chǎn)品層面到落地如果進入到低代碼平臺中可能沒人能完全懂里面是什么邏輯，就拿拖拉拽或者是流程編排式的低代碼應(yīng)用來說也是不能感知業(yè)務(wù)邏輯的，或者不能很好的梳理整個業(yè)務(wù)邏輯。
2、無法跨越編譯運行的鴻溝
這個觀點是我在前兩個月低代碼討論的火熱的時候提出的，跟群友們吹牛的時候說的。我這么說的意思是因為計算機本身的底層(網(wǎng)絡(luò)，硬件，操作系統(tǒng)等)與上層語言應(yīng)用天然存在層間隔離，那就導(dǎo)致幾乎所有除了低級語言能直接在應(yīng)用上跑而其他語言需要編譯一下借助對應(yīng)的容器環(huán)境才行。
所以當(dāng)我們通過低代碼構(gòu)建應(yīng)用邏輯的時候我們依然需要去借助人工也好借助機器平臺也好去讓他變得可運行。
所以不同語言，不同技術(shù)體系下依然需要對應(yīng)的工具平臺去輔助完成低代碼從創(chuàng)造到運行的完整過程。
比如宜搭等這種輕應(yīng)用的基本上是可以做到0代碼的，所以這種可以很容易翻越這個鴻溝。但是當(dāng)我們需求有變化或者提供應(yīng)用環(huán)境的云廠商出現(xiàn)了問題那么依然需要開發(fā)者對其做可用性的保證。
3、低代碼代替不了所有軟件編程工種
這里是可以懟低代碼的最佳理由，畢竟我說我是做php的它也不能咋的，大不了我可以做C。所以對于低代碼而言數(shù)據(jù)分析，大數(shù)據(jù)，中間件，嵌入式，或者是工具類平臺系統(tǒng)它都只能尬笑。
4、低代碼無法修改它創(chuàng)建的東西
這個其實就是說我們可以用低代碼創(chuàng)造代碼，但是無法修改它，就像人一樣，你無法控制你的孩子未來每一天都按你的規(guī)劃去過活。假如我流程編排可以，配置化可以，托拉拽可以，但是保不齊哪天需求多了，修改多了，改配置也變得跟改代碼一樣了。
2.5 低代碼的悖論
這里我對于低代碼的缺點分了三條，上面已經(jīng)講了兩條了，這里我分享一下關(guān)于低代碼的幾個悖論：
低代碼只能無限趨近于0代碼 用低代碼創(chuàng)造低代碼 低代碼創(chuàng)造還是修建
上面兩條可能有點玄乎所以了，所以這里簡單跟大家解析一下，第一條的意思可以用數(shù)學(xué)的概念去解釋，就是說低代碼的極限情況下可以約等于0代碼，但是絕對達不到，類似于數(shù)學(xué)中的無限大或者無限小。
當(dāng)然第二種就類似于俄羅斯套娃，或者你可以簡單理解為先有雞還是先有蛋的場景。如果低代碼有那么它不是0代碼，如果低代碼沒有，它創(chuàng)造不了低代碼。
第三個其實算是低代碼缺陷的一種，這里姑且算一個悖論，就是低代碼可能無法感知到要創(chuàng)建的東西其實已經(jīng)創(chuàng)建過了，只是修改了。
2.6 低代碼是銀彈嗎
那些非常遵奉低代碼的人可能會說出這種話，但是對于受到軟件編程毒打的人是萬萬不信的，畢竟產(chǎn)品改需求的次數(shù)低代碼翻臉都反應(yīng)不過來。
2.7 低代碼是毒瘤嗎
這個問題跟2.6一樣，稍微理智一點的或者見識多了也不會說這種話，畢竟有很多人去做了低代碼，然后說它可以幫你早點下班，對于程序員來說沒人不想去了解它。與其說是毒瘤，我覺得倒不如像是撫媚的妖女，你懂得，有時候你會因為修改變更倒排期等等因素受到它的蠱惑?？赡苁且驗槲覀儗ζ淦谕?，期望它能背負(fù)起從需求到上線的大部分責(zé)任。但是期望越大失望也越大，企業(yè)不可能指望它可以幫助我們應(yīng)對產(chǎn)品的需求變更，實現(xiàn)更多業(yè)務(wù)價值，償還技術(shù)債務(wù)等。所以說不公正不客觀的去評價低代碼是不合理的。
2.8 簡評零代碼的低代碼平臺
對于號稱0代碼的低代碼平臺而言，就像是微信公眾號的廣告文章一樣，看個標(biāo)題就相當(dāng)于閱讀了全文。
三、低代碼的定位
3.1 腳手架
其實低代碼的功能可以從框架或者技術(shù)棧延伸出來，當(dāng)作腳手架的一個特色功能，所以這里可以將低代碼定位為腳手架，幫助軟件項目進行一些高效的構(gòu)建任務(wù)。
3.2 代碼生成工具
如果更專業(yè)一點或者說將其從腳手架脫離出來單獨發(fā)展則可以成為代碼生成工具，包括最簡單的lombok,idea插件，數(shù)據(jù)庫實體生成工具等等。這里的工具級別是做針對性的生成和解決，提高開發(fā)效率。
3.3 代碼生成平臺
如果從生成工具豐富到一定程度則會演變成一個代碼生成平臺，此時從平臺視角來看他有更多的能力特色，比如技術(shù)棧定制，流程編排，可視化等等。
3.4 代碼生成應(yīng)用
從平臺到應(yīng)用其實也是有一個跨度或者進化的，這里所指的應(yīng)用是那些靠低代碼和周邊技術(shù)服務(wù)來創(chuàng)業(yè)的商業(yè)公司的應(yīng)用產(chǎn)品。到這個地步低代碼已經(jīng)可以與需求管理，發(fā)布迭代管理，云環(huán)境交付等結(jié)合在一起了，真正實現(xiàn)閉環(huán)式的應(yīng)用軟件構(gòu)建生態(tài)。
四、總結(jié)
低代碼未來一定還存在，不同的人對其有不同的態(tài)度，對于我而言我只是想一次性構(gòu)建，后續(xù)工作中學(xué)習(xí)中都可以幫助我快速達到構(gòu)建軟件雛形的目的。所以低代碼再怎么智能，還是需要程序員去調(diào)教的。好了，本文從網(wǎng)上熱議的一些話題結(jié)合了我本人的一些想法對低代碼本身做了一些探討，希望能給大家?guī)聿灰粯拥挠^點和思維火花。
作者簡介：神帥
畢業(yè)5年,混跡于大小廠打怪刷實戰(zhàn)經(jīng)驗。
資深Java開發(fā)工程師,是個寶爸,熱愛生活做飯,讀書,在企業(yè)服務(wù)領(lǐng)域和電商領(lǐng)域均有積累,
最近一直在研究DDD和低代碼領(lǐng)域,對后端微服務(wù)業(yè)務(wù)平臺架構(gòu)的實踐和發(fā)展比較感興趣。
公眾號:神帥的架構(gòu)實戰(zhàn)
CSDN:https://blog.csdn.net/u010504064
推薦閱讀：
歡迎關(guān)注微信公眾號：互聯(lián)網(wǎng)全棧架構(gòu)，收取更多有價值的信息。