怎么看待爭議 低代碼？（怎么看待爭議 低代碼的問題）

作為一個有過相關(guān)開發(fā)經(jīng)驗的碼農(nóng)，過來簡單談幾句自己的想法：

首先，低代碼平臺并不能單純說是好是壞，這樣評價太片面了，它能流行起來，肯定有它的可取之處，但是現(xiàn)在爭議之所以這么大，跟很多因素相關(guān)，先說好的吧。

它的優(yōu)勢在于能夠極大地提高開發(fā)速度和降低技術(shù)門檻。對于一些標準化的業(yè)務(wù)流程，使用低代碼平臺可以相當快地搭建出一個穩(wěn)定的原型或甚至是生產(chǎn)級應(yīng)用，這個快是什么概念呢，大概是之前開發(fā)速度的 3-5 倍，就這么樸實無華，一點沒夸張。

這種快速迭代和驗證市場相當有利。就像是在搭積木，你不需要知道每一個積木是怎么制造出來的，只需要知道它們?nèi)绾谓M合在一起。對于非技術(shù)背景的人來說，也有一個很大的好處，可以直接參與到應(yīng)用的構(gòu)建中，不需要深入了解編程語言和開發(fā)細節(jié)。

傳統(tǒng)軟件開發(fā)步驟最大痛點是什么？不是代碼、不是bug、也不是什么業(yè)務(wù)邏輯，是溝通！

大部分的問題都是老板或者產(chǎn)品經(jīng)理不知道自己想要啥，做成什么樣，對軟件需求不明，你在一開始沒有一個完善的解決方案，導(dǎo)致我們就要邊做邊改，有可能產(chǎn)品今天冒出個什么想法，改！明天又冒出個什么想法，改！市場遭遇冷淡？改！于是，無數(shù)夾雜著唾罵、瑣碎、怨恨和無力的情緒在瑣碎的修改和推翻重來的時間里默默自己消化。

現(xiàn)在就跟以前不一樣，在低代碼平臺上快速搭建起基本模型， 再根據(jù)實際應(yīng)用的使用體驗反饋完善方案，這種速度不曉得快過以前多少，起碼推翻重來的是很少數(shù)了。

不過，實際應(yīng)用中，低代碼平臺也不是萬能的，往往適用于中小型項目，或者是企業(yè)內(nèi)部的一些工作流程自動化。這些場景下，低代碼平臺可以大大減少開發(fā)工作量，提高工作效率。

但是，一旦涉及到更復(fù)雜的系統(tǒng)，特別是需要高度定制化的場景時，低代碼平臺的局限性就顯現(xiàn)出來了——無法提供足夠的靈活性來滿足特定的業(yè)務(wù)需求，或者在性能優(yōu)化方面不如手工編碼那樣精細，就像是當你需要一個定制化的解決方案時，預(yù)制的積木可能就不夠用了，你得自己做這塊積木出來。還有一種情況是，很多低代碼平臺本身就是個黑盒，一旦內(nèi)部出現(xiàn)bug或崩潰，我們就只能干瞪眼，完全沒有辦法，只能等官方的維護修理。

上面的缺點都還能忍受，但低代碼最大的問題，在于它可能會導(dǎo)致技術(shù)債務(wù)。

在低代碼平臺上快速搭建的應(yīng)用，可能在未來難以維護和擴展，一旦業(yè)務(wù)需求超出了平臺的能力范圍，就可能需要進行大規(guī)模的重構(gòu)，甚至是重新編碼。

另外，過分依賴低代碼平臺也可能導(dǎo)致程序員群體的技術(shù)能力退化，因為不再需要深入底層技術(shù)，這就像是一直使用計算器做數(shù)學(xué)題，久而久之可能就會忘記如何手動計算了。

我覺得能解決上述問題的唯一方法就是導(dǎo)出源碼，所以后面我們自己的團隊也換用 iVX 了，獨立導(dǎo)出源碼，獨立部署，生成代碼的質(zhì)量還高，也不會說喪失我們自己的專業(yè)能力，把代碼導(dǎo)出到其他平臺，照樣能用，也沒有重構(gòu)編碼的擔憂了，目前算是一個還不錯的平衡。