作者 | David Linthicum
策劃 | 言征
代碼再簡單，老板們也不會去寫。不只是因?yàn)樗麄兲?，還因?yàn)楹唵蔚拇a，坑也很多。
低代碼和無代碼開發(fā)平臺最近獲得了巨大的關(guān)注，隨著 2023 年人工智能的興起，情況更是如此。這項(xiàng)技術(shù)有望實(shí)現(xiàn)應(yīng)用開發(fā)的民主化，公民開發(fā)者。
其實(shí)早在 70 年代就曾用Cobol嘗試過這一點(diǎn)，此后也曾多次嘗試過。無論代碼多么簡單，高管都不會編寫。
低代碼和無代碼平臺提供可視化界面和預(yù)構(gòu)建組件來簡化編碼過程，以便具有最少編碼經(jīng)驗(yàn)的人可以快速創(chuàng)建應(yīng)用程序。雖然預(yù)構(gòu)建組件簡化了開發(fā)并提供了靈活性和速度，但要注意可擴(kuò)展性、安全性和集成問題。
因此，盡管這些平臺具有優(yōu)勢，但它們帶來的麻煩也必須留意：必須在示例性云計(jì)算架構(gòu)中仔細(xì)權(quán)衡，包括設(shè)計(jì)、開發(fā)和部署。
1、靈活性與定制化
低代碼和無代碼平臺擅長通過提供預(yù)打包的組件和模板來簡化開發(fā)流程。這與在文字處理程序中使用模板（例如通用感謝信或簡歷）的概念相同。今天，我們使用我們最喜歡的生成式人工智能平臺來為我們編寫它們。
這些平臺在定制方面可能存在局限性。隨著應(yīng)用程序復(fù)雜性的增加，開發(fā)人員可能需要幫助來實(shí)現(xiàn)他們想要的定制和細(xì)粒度控制。對于具有獨(dú)特或高度專業(yè)化要求的組織來說，這可能是一個障礙。這與我們在 90 年代的企業(yè)資源規(guī)劃 (ERP) 平臺遇到的問題相同。我們必須使用 ERP 提供商提供的任何定制技術(shù)來重寫它們，以使其可用。許多公司發(fā)現(xiàn)他們可以自己編寫應(yīng)用程序并節(jié)省 90% 的資金。
2、速度與可擴(kuò)展性
低代碼和無代碼平臺通過抽象化編碼的復(fù)雜性來實(shí)現(xiàn)快速應(yīng)用程序開發(fā)。這并不是什么新鮮事，但今天可以通過AI層來幫助我們做得更好。
這一點(diǎn)，對于需要快速構(gòu)建原型和啟動應(yīng)用程序的組織來說是有利的。然而，隨著需求的增多，擴(kuò)展這些應(yīng)用程序可能會暴露低代碼平臺的局限性。大多數(shù)平臺都需要處理大量用戶群或高數(shù)據(jù)量。所以由于你一開始就沒有創(chuàng)建系統(tǒng)，想要修復(fù)問題將非常困難。
3、安全與控制
低代碼和無代碼平臺的構(gòu)建是為了讓更廣泛的受眾能夠進(jìn)行開發(fā)。它們通常包含安全功能，但與安全應(yīng)成為整體開發(fā)一部分的傳統(tǒng)方法相比，控制級別和粒度可能受到限制。
組織必須仔細(xì)評估平臺提供的安全措施，并確保它們符合其特定的安全要求和行業(yè)法規(guī)。我還沒有找到能夠解決這個問題的低代碼或無代碼系統(tǒng)。許多人為了方便而利用這項(xiàng)技術(shù)，卻失去了足夠的安全性，這是不明智的。
4、與現(xiàn)有系統(tǒng)集成
低代碼和無代碼平臺可以簡化獨(dú)立應(yīng)用程序的開發(fā)。然而，將這些應(yīng)用程序與遺留系統(tǒng)或其他云服務(wù)集成可能是一個挑戰(zhàn)。這很大程度上取決于平臺的功能和API集成，并且可能需要額外的開發(fā)工作才能實(shí)現(xiàn)與現(xiàn)有系統(tǒng)的無縫集成。
就像我們剛才提到的安全權(quán)衡一樣，這降低了低代碼和無代碼技術(shù)帶來的價值。我們必須將復(fù)雜的代碼分層到我們真正不理解的系統(tǒng)中，因?yàn)槲覀儧]有開發(fā)它們而機(jī)器人做到了。
5、寫在最后
低代碼/無代碼可能會成為一項(xiàng)對許多企業(yè)來說似乎可以改變游戲規(guī)則的技術(shù)。但我擔(dān)心的是，如果在使用和應(yīng)用時如果不夠謹(jǐn)慎，低代碼和無代碼會導(dǎo)致更多工作并增加更多風(fēng)險。如果我戳破了一些泡沫，抱歉。
