低代碼有人說是毒瘤，也有人說是銀彈。到底應(yīng)該怎么看呢？存在即合理。

“存在”包括兩個角度：

• 銀彈論
• 毒瘤論

無論從哪個角度看，既然存在這樣的論調(diào)，就有它們的合理性。

先把關(guān)注點(diǎn)移到低代碼本身，低代碼到底是要革程序員的命？還是成為程序員工具箱里的另一個工具？

如果你覺得低代碼的目的是為了革程序員的命，是要把程序員的手腳給捆住，是要束縛程序員的創(chuàng)造性，是要把復(fù)雜的現(xiàn)實(shí)世界強(qiáng)制機(jī)械化、特例化、流程化，那么大概率你會接受毒瘤論。你甚至?xí)翢o保留地否定低代碼，認(rèn)為Low Code除Low以外，不會有Code。畢竟，變革有成本的，而且往往成本巨大，無論是一個人還是一個團(tuán)隊(duì)，保持慣性，留戀舒適區(qū)才是正常的。我們幾十年來用的軟件從來都是雙手敲代碼創(chuàng)造出來，拋棄這個已被無數(shù)次證實(shí)可行的方法，擁抱一個“飽受爭議”的新方法，這本身就需要有莫大的勇氣，也要承受風(fēng)險(xiǎn)。

雖然會有很多勇于探索、期望嘗試新方法的人和團(tuán)隊(duì)，也有很多受困于Pro Code（手敲代碼的方式）的各種痛點(diǎn)被迫自我變革的人和團(tuán)隊(duì)，但是更多的人和團(tuán)隊(duì)是傾向于保持現(xiàn)狀的，即使嘴上不說，身體卻很誠實(shí)。每次回顧會都能復(fù)盤出一堆的代碼問題，然后一而再、再而三地立flag說要改進(jìn)，但多數(shù)會給出各種借口說明問題無解，然后繼續(xù)這樣的循環(huán)。有慣性就有排斥，有排斥就有各種負(fù)面論調(diào)，毒瘤論是典型代表。

1 Pro Code 創(chuàng)造的軟件更“香”嗎？

換個角度，把低代碼當(dāng)做程序員工具箱里的另一工具，我們再次審視銀彈論和毒瘤論的沖突時，會發(fā)現(xiàn)一些不同點(diǎn)。工具不會革誰的命，只會讓大家的日子更好過。工具有好有壞，不好用時就丟棄，好用時就多用用。

條條大路通羅馬，我們前往羅馬除了傳統(tǒng)的步行、馬車外，還能開汽車、坐飛機(jī)，甚至也可以在路況好的時候開汽車，風(fēng)景好的時候下車漫步抑或縱馬馳騁，只要能按時到達(dá)羅馬，我相信沒人會太關(guān)注過程，所以在去羅馬的旅途只要你開心就好。

開發(fā)軟件寫bug也是類似的，Pro Code方式創(chuàng)造的軟件不會比其他方式生產(chǎn)出來的軟件更香、不會賣更多米，因?yàn)檐浖脩敉耆魂P(guān)注軟件是怎么被創(chuàng)造。

軟件研發(fā)里的“羅馬”不僅僅是一個目的地，所以這里帶上雙引號了。在軟件業(yè)里，“羅馬”除了指代交付的業(yè)務(wù)功能外，它的內(nèi)涵還有：交付物可維護(hù)性、可擴(kuò)展性、可測試性、交付過程的成本，甚至是團(tuán)隊(duì)的新陳代謝等等許多因素。同樣地，我們審視到底是“騎馬”好，還是“開車”好的時候，需要關(guān)注的不僅僅是心情，而需要關(guān)注到所采用的方式是否能在各個方面都有比較好的表現(xiàn)。這是一個極復(fù)雜的評判過程，且各個團(tuán)隊(duì)有各自的側(cè)重，沒有標(biāo)準(zhǔn)答案。

但早已業(yè)界共識： Pro Code不是軟件開發(fā)的銀彈，要不然就不會有低代碼等多種新方式被提出來甚至展開實(shí)踐。

門檻高

雖然我們自貶為“碼農(nóng)”，但是根據(jù)GitHub的統(tǒng)計(jì)數(shù)據(jù)，去年國內(nèi)只有大約755萬多開發(fā)人員，一個人可能只會寫hello world就被算進(jìn)來，攤到各個細(xì)分研發(fā)領(lǐng)域后，人數(shù)就少得可憐了。

跨界難

雖然都是寫代碼的，但是Java程序員可能很難玩得轉(zhuǎn)C/C++，前端程序員很難玩得轉(zhuǎn)Java/Scala等后端。

一個典型例子是：全棧這個詞是在在Node.js火熱起來之后才被發(fā)明出來的，在這之前，前后端通吃的只能是極少數(shù)頂尖骨干。但是，即使現(xiàn)在有了node.js實(shí)現(xiàn)前后端跨界，我們跨越到其他領(lǐng)域依然困難。總之，即使在具體業(yè)務(wù)場景下，要端到端交付一個完整業(yè)務(wù)，對一個人，甚至一個團(tuán)隊(duì)來說，都不是一件簡單事。

代碼編寫只是第一步

之后還有許多問題需要解決。像代碼所依賴的第三方庫的開源合規(guī)治理、第三方和己方的代碼安全漏洞檢測和治理，還有代碼性能、代碼測試、運(yùn)行時運(yùn)維等，這些工作不是難度大，就是繁瑣。最后，為了對抗代碼庫的熵增，避免代碼倉庫越來越混亂，越來越難維護(hù)，還必須引入代碼走查機(jī)制，讓經(jīng)驗(yàn)豐富的程序員來把關(guān)。

Pro Code問題顯然不止這些，但已足夠說明問題。許多問題由于代碼自身導(dǎo)致，引入一些工具降低代碼量，許多問題也就緩解甚至解決。代碼本身無直接價(jià)值，業(yè)務(wù)才有直接價(jià)值，從來沒聽說過哪家公司是憑百萬千萬行代碼repo作為資產(chǎn)上市。公司之所以能上市肯定是由于資本市場認(rèn)可它的業(yè)務(wù)價(jià)值，代碼只不過是用于實(shí)現(xiàn)業(yè)務(wù)的一種場常見方式，但絕不是唯一。

不管是白貓黑貓，能抓老鼠的就是好貓，吃喝拉撒越少的貓則是更好貓。只要能實(shí)現(xiàn)相似價(jià)值的業(yè)務(wù)，并且承載該業(yè)務(wù)的方式的副作用比代碼要少，那么這就是一種更好方式。

相信你有足夠的理性來把低代碼作為一種工具來看待，而不認(rèn)為這是一種程序員自我革命手段。

2 Low Code 銀彈論合理嗎？

既然Pro Code不是銀彈，那Low Code是不是銀彈呢？當(dāng)然也不。

Pro Code和No Code一個純代碼，一個無代碼。假設(shè)Pro Code的代碼量是100，那No Code就是0，所以Pro Code和No Code是截然不同的，甚至你可以認(rèn)為這兩者毫無關(guān)系。No Code最典型形態(tài)莫過SaaS類產(chǎn)品。

Low Code應(yīng)擺在哪個位置？關(guān)鍵點(diǎn)不在于多少，而在于有沒有！

Low Code當(dāng)然是有代碼的，所以它和Pro Code是一路貨色，從創(chuàng)建業(yè)務(wù)價(jià)值的最根本上說，它們是一樣的，都是通過代碼來創(chuàng)建業(yè)務(wù)價(jià)值。而No Code則不是，它只是對已有業(yè)務(wù)的二次組合來創(chuàng)建業(yè)務(wù)價(jià)值，No Code創(chuàng)建業(yè)務(wù)的全過程都沒有源碼的參與。

Pro Code和Low Code的差異

本質(zhì)差異在于源碼在這兩者創(chuàng)造業(yè)務(wù)價(jià)值的過程中所扮演的角色：

• Pro Code是把代碼當(dāng)作關(guān)鍵輸入來創(chuàng)建業(yè)務(wù)的
• Low Code則不是，它的輸入是一些結(jié)構(gòu)化的數(shù)據(jù)

Low Code工具有能力將結(jié)構(gòu)化數(shù)據(jù)生成為源碼，然后再采用與Pro Code相同的方式將源碼轉(zhuǎn)為業(yè)務(wù)能力。很顯然的一點(diǎn)是，Low Code把源碼當(dāng)做中間產(chǎn)物，而Pro Code則將源碼做為關(guān)鍵輸入。相信現(xiàn)在你應(yīng)該可以分清楚Pro Code、Low Code、No Code之間的差異了。

那么Low Code為啥也不是銀彈呢？關(guān)鍵就在于，Low Code是采用無邏輯的結(jié)構(gòu)化數(shù)據(jù)來描述業(yè)務(wù)的，對于相同業(yè)務(wù)，Low Code的描述能力要弱于有邏輯的Pro Code。所以，Pro Code都做不到的事情，Low Code當(dāng)然也做不到。

根據(jù)前面與Pro Code的比對，我們可以看出， Low Code對業(yè)務(wù)的描述能力既弱于Pro Code，也與Pro Code沒有實(shí)質(zhì)差異，看起來Low Code一無是處啊。我認(rèn)為這可能是低代碼毒瘤論的理論基礎(chǔ)。別急，繼續(xù)往下看。

Pro Code開發(fā)方式是指令式的，它的開發(fā)過程是告訴計(jì)算機(jī)如何一步步實(shí)現(xiàn)某個業(yè)務(wù)。Low Code則不然，它的開發(fā)過程是不停地在描述和細(xì)化這個業(yè)務(wù)最終的樣子。

可以說，Low Code的開發(fā)人員的思維方式與Pro Code的開發(fā)人員完全不一樣，他們始終在思考這個業(yè)務(wù)應(yīng)該是啥樣的，而Pro Code的開發(fā)人員則是在開發(fā)過程中不停地思考如何將業(yè)務(wù)翻譯成一條條指令。其中關(guān)鍵的一點(diǎn)是，對于Pro Code開發(fā)人員來說，這個業(yè)務(wù)最終的樣子不是天上掉下來的，抑或大風(fēng)刮來的，而是要在他們著手翻譯成指令之前先想清楚的。

所以結(jié)論就是，Low Code開發(fā)人員要比Pro Code開發(fā)人員少做一個事情：無需將業(yè)務(wù)翻譯成指令，從而他們得以用更高的效率實(shí)現(xiàn)相同的業(yè)務(wù)，在單位時間內(nèi)創(chuàng)造更多業(yè)務(wù)價(jià)值。

低代碼模式除了效率外，還有另一個賣點(diǎn)，那就是低技術(shù)門檻。它可以賦能更多人，使其可以快速參與業(yè)務(wù)開發(fā)。沒錯，就是實(shí)現(xiàn)外卷！

根據(jù)我們前面說的，Low Code依然有代碼，但70%~90%甚至更多比例的代碼是自動生成的。這里要特別注意的是，其中100%的框架性的代碼都是自動生成的，這部分代碼不但與業(yè)務(wù)無直接關(guān)系，即沒有直接業(yè)務(wù)價(jià)值，還是最難開發(fā)的，一出問題都是大問題。而剩余的小部分需要開發(fā)者填寫的代碼，則基本上都是表達(dá)式，或者部分復(fù)雜業(yè)務(wù)邏輯。

表達(dá)式也好，強(qiáng)業(yè)務(wù)邏輯代碼也好，都是在直接實(shí)現(xiàn)業(yè)務(wù)功能，所以即使在低代碼平臺上寫代碼，那也是在直接實(shí)現(xiàn)業(yè)務(wù)邏輯。那些只有業(yè)務(wù)能力但無開發(fā)能力的人、需要寫UI的后端開發(fā)，或者是需要寫業(yè)務(wù)的前端開發(fā)等人群，都可以在低代碼平臺上實(shí)現(xiàn)跨界開發(fā)，實(shí)現(xiàn)端到端的業(yè)務(wù)交付能力。賦予原本沒有技術(shù)能力的人快速參與的能力，是低代碼的另一個重要能力。

基于以上提效和賦能兩點(diǎn)，我們有足夠的理由來認(rèn)為低代碼銀彈論是合理的，銀彈論并非一群“不務(wù)正業(yè)”、“整天想著再造一個輪子”的人的自嗨。

Low Code離銀彈還有多遠(yuǎn)？

低代碼毒瘤論者只看到表面，或者思考深度不足，沒能從實(shí)質(zhì)上看到Pro Code和Low Code的差異。即使如此，我也認(rèn)為毒瘤論是有合理性的。畢竟很多實(shí)現(xiàn)Low Code的人自己也沒想明白就匆匆動手，為了達(dá)到少代碼（而非低代碼）的目的而做出各種各樣無理約束，你不能這個、不能那個，最終不但沒能發(fā)揮出低代碼的優(yōu)勢，反而降低了效率，被他人詬病。

即使拋開這類情形不說，Low Code本身的成熟度也需要改進(jìn)， 一個重要改進(jìn)點(diǎn)是：如何有效解決強(qiáng)邏輯場合下的可視化配置方法，這是Low Code采用無邏輯的結(jié)構(gòu)化數(shù)據(jù)描述業(yè)務(wù)常見的重要短板。這個問題至今也在困擾著我，我認(rèn)為我們目前給出的解決方案并非最優(yōu)解，仍然需要孜孜不倦地探索出更合適的手段。

低代碼要真正成為銀彈，除了解決強(qiáng)邏輯的可視化配置外，要做的事情還有很多。有一部分我在前文已經(jīng)有過描述了，這里再給你簡單總結(jié)和拓展一下，一方面是為了用作毒瘤論非合理性的額外論據(jù)，另一方面也是為了給這個專欄后續(xù)的內(nèi)容埋點(diǎn)伏筆。

首先，快速部署能力是要有的，最基本的需要一鍵導(dǎo)出所有運(yùn)行時需要的文件，最好能做到一鍵部署和運(yùn)行時，這樣的能力將給業(yè)務(wù)的小伙伴提供巨大的便利，大幅減少他們的試錯時間。

其次，也是最重要的，低代碼平臺還需要關(guān)注生成的App的可測試性。如果生成的App是一個黑盒，出錯時無從下手，日志打印惜字如金，要是這時候平臺再對業(yè)務(wù)團(tuán)隊(duì)的困境置之不理甚至推諉，那無論是誰都會厭惡這樣的開發(fā)方式的。

可測試性是一個非常綜合的能力，從最基本的部署運(yùn)行開始，到豐富準(zhǔn)確的日志，再到直接給予業(yè)務(wù)團(tuán)隊(duì)調(diào)試支持，甚至到直接提供自動化測試的能力，這里頭涉及的不僅是技術(shù)，還有團(tuán)隊(duì)間如何協(xié)作的問題。

還有一個容易被無視的能力是，低代碼平臺需要支持多人協(xié)作開發(fā)，當(dāng)業(yè)務(wù)越來越復(fù)雜，多人協(xié)作是剛需。 這個問題往往在平臺建設(shè)初期就容易被無視，在后期隨著應(yīng)用的復(fù)雜度上升后才被提出，這時候再去實(shí)現(xiàn)，成本會非常大。此時平臺有可能會簡單粗暴地采用互斥的方式來掩耳盜鈴。

要知道，業(yè)務(wù)團(tuán)隊(duì)往往面臨巨大的交付工期壓力，如果小李無法在小王編輯時上手，一急之下他們可能將數(shù)據(jù)復(fù)制一份來同時編輯，結(jié)果發(fā)現(xiàn)無法手工合并結(jié)構(gòu)化數(shù)據(jù)，這樣的情形放誰身上都會抓狂。所以支持多人協(xié)作開發(fā)是低代碼平臺非常必要的一個能力，而這背后其實(shí)還隱藏著編輯歷史管理、分支管理等潛在需求，這些都對業(yè)務(wù)團(tuán)隊(duì)多人協(xié)作效率有很大的影響。

再者，兜底能力也是很重要的。 低代碼平臺不可能面面俱到，它總有能力邊界，但這個能力邊界不能束縛業(yè)務(wù)團(tuán)隊(duì)的探索。業(yè)務(wù)需要緊隨市場甚至引領(lǐng)市場，而市場是千變?nèi)f化的，任何公司都無法決定，所以要把“業(yè)務(wù)提出低代碼平臺能力之外的需求”當(dāng)做一種常態(tài)。此時，低代碼平臺需要有一種策略幫助應(yīng)用快速實(shí)現(xiàn)需求，哪怕直接上手編碼乃至Hack。這樣的策略就是兜底策略。

此外還有一些增值功能，包括UX設(shè)計(jì)規(guī)范自動對齊、提供UX設(shè)計(jì)稿轉(zhuǎn)代碼（D2C）能力、App的可維護(hù)性、App的埋點(diǎn)&數(shù)據(jù)采集、App的開源合規(guī)治理、App的安全漏洞治理、App的性能等等。簡單來說，這些都是低代碼平臺的亮點(diǎn)能力，并且是拉開與Pro Code差距的重要能力。

講到這里我們可以看到，低代碼平臺只關(guān)注開發(fā)能力是遠(yuǎn)遠(yuǎn)不夠的。而毒瘤論的另一個重要基礎(chǔ)就是來自于許多低代碼平臺只注重開發(fā)能力，而無視業(yè)務(wù)交付過程的其他能力，特別是對App可測試性的漠視。

作為低代碼的堅(jiān)定支持者和踐行者，我當(dāng)然不同意低代碼是毒瘤這個論斷，但是我不會輕易去噴這些言論，而是努力去理解和挖掘毒瘤論的言論基礎(chǔ)，從中分析出那些容易被我們無視或者輕視的需求。只要我們常常能細(xì)心、謙虛地觀察業(yè)務(wù)開發(fā)過程中的方方面面，并及時發(fā)現(xiàn)業(yè)務(wù)團(tuán)隊(duì)的痛點(diǎn)和需求并及時解決，以一種服務(wù)者的態(tài)度來為業(yè)務(wù)提供服務(wù)，我相信，毒瘤論會漸漸消散的。

總結(jié)

很少有一種技術(shù)像低代碼這樣同時被兩種極端言論評價(jià)，今天我們從一個理性的角度審視了這兩種言論，并嘗試去理解它們的思路和痛點(diǎn)。

我們從Pro Code、Low Code、No Code的對比中了解到Pro Code與Low Code的關(guān)鍵差異不在于代碼量的多少，而在：

• 代碼在這兩者創(chuàng)造業(yè)務(wù)價(jià)值的過程中所扮演的角色，對Pro Code來說，代碼是關(guān)鍵輸入，而對Low Code來說，代碼僅僅是中間產(chǎn)物、是副產(chǎn)品；
• 使用Low Code開發(fā)雖然也需要少量編碼，但是基本上都是在填寫表達(dá)式，直接實(shí)現(xiàn)業(yè)務(wù)價(jià)值，與業(yè)務(wù)價(jià)值無關(guān)的代碼則幾乎全都被自動生成；
• 使用Low Code開發(fā)業(yè)務(wù)的人幾乎時時刻刻都在描述和細(xì)化業(yè)務(wù)最終的樣子，使用 Pro Code的開發(fā)人員不僅需要思考業(yè)務(wù)最終的樣子，還要將其翻譯成一條條計(jì)算機(jī)指令。

這些差異正是Low Code的比較優(yōu)勢，這也是為啥Low Code可以幫助業(yè)務(wù)提效和賦能的原因：無需長篇累牘地編碼可以大幅降低使用的門檻，實(shí)際上就是對無編碼技能者進(jìn)行賦能；幾乎所有框架性、非功能代碼全部自動生成，以及無需將業(yè)務(wù)翻譯成一條條計(jì)算機(jī)指令，可以大幅壓縮開發(fā)周期，實(shí)際上就是在提效。

但即使如此，當(dāng)下的Low Code也不是銀彈，因?yàn)槲覀冊诜治龆玖稣摰倪^程中意識到Low Code除了注重開發(fā)能力之外，還應(yīng)該具有諸多其他能力以覆蓋業(yè)務(wù)研發(fā)全生命周期，包括一鍵導(dǎo)出和部署、較高的可測試性甚至自動化測試能力、多人協(xié)作、兜底能力等等，若低代碼平臺不具備這些能力，則很難發(fā)揮低代碼技術(shù)的優(yōu)勢。

Low Code許多增值功能：

• 自動對齊UX設(shè)計(jì)規(guī)范、UX設(shè)計(jì)稿轉(zhuǎn)代碼（D2C）能力
• App的埋點(diǎn)&數(shù)據(jù)采集
• 開源合規(guī)治理
• 安全漏洞治理

都是拉開Pro Code差距的重要抓手。

FAQ

低代碼平臺是否只需把開發(fā)能力發(fā)揮到極致就可以了？除了開發(fā)能力之外，低代碼平臺還需要注重哪些能力的建設(shè)？你認(rèn)為其中最重要的是哪些？

低代碼平臺的確需要開發(fā)能力的支持，但除此之外，還需要注重以下能力的建設(shè)：

1. 可視化設(shè)計(jì)能力：低代碼平臺需要提供可視化的界面設(shè)計(jì)工具，讓用戶能夠通過拖拽、配置等方式快速構(gòu)建應(yīng)用界面。

2. 數(shù)據(jù)建模能力：低代碼平臺需要提供數(shù)據(jù)建模工具，讓用戶能夠通過簡單的操作定義數(shù)據(jù)模型，實(shí)現(xiàn)數(shù)據(jù)的存儲和管理。

3. 組件化能力：低代碼平臺需要提供可復(fù)用的組件庫，讓用戶能夠快速構(gòu)建應(yīng)用功能。

4. 自動化部署能力：低代碼平臺需要提供自動化部署工具，讓用戶能夠快速將應(yīng)用部署到云端或本地環(huán)境。

其中，我認(rèn)為可視化設(shè)計(jì)能力和組件化能力是最重要的兩個能力，因?yàn)檫@兩個能力可以大大提高開發(fā)效率，降低開發(fā)成本。

再分享我整理匯總的一些 Java 面試相關(guān)資料（親自驗(yàn)證，嚴(yán)謹(jǐn)科學(xué)！別再看網(wǎng)上誤導(dǎo)人的垃圾面試題！?。。?，助你拿到更多 offer！

點(diǎn)擊獲取更多經(jīng)典必讀電子書！

2023年最新Java學(xué)習(xí)路線一條龍：

再給大家推薦一個學(xué)習(xí) 前后端軟件開發(fā) 和準(zhǔn)備Java 面試的公眾號【JavaEdge】（強(qiáng)烈推薦！）文章來源地址http://www.zghlxwxcb.cn/news/detail-623096.html

到了這里，關(guān)于低代碼：解放生產(chǎn)力的利器還是一場空洞的炒作？的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！