作為一個有過相關(guān)開發(fā)經(jīng)驗的碼農(nóng)，過來簡單談幾句自己的想法：
首先，低代碼平臺并不能單純說是好是壞，這樣評價太片面了，它能流行起來，肯定有它的可取之處，但是現(xiàn)在爭議之所以這么大，跟很多因素相關(guān)，先說好的吧。
它的優(yōu)勢在于能夠極大地提高開發(fā)速度和降低技術(shù)門檻。對于一些標(biāo)準(zhǔn)化的業(yè)務(wù)流程，使用低代碼平臺可以相當(dāng)快地搭建出一個穩(wěn)定的原型或甚至是生產(chǎn)級應(yīng)用，這個快是什么概念呢，大概是之前開發(fā)速度的 3-5 倍，就這么樸實無華，一點沒夸張。
這種快速迭代和驗證市場相當(dāng)有利。就像是在搭積木，你不需要知道每一個積木是怎么制造出來的，只需要知道它們?nèi)绾谓M合在一起。對于非技術(shù)背景的人來說，也有一個很大的好處，可以直接參與到應(yīng)用的構(gòu)建中，不需要深入了解編程語言和開發(fā)細(xì)節(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)化方面不如手工編碼那樣精細(xì)，就像是當(dāng)你需要一個定制化的解決方案時，預(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)編碼的擔(dān)憂了，目前算是一個還不錯的平衡。
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。