盡管承諾簡化和填補 IT 技能差距，但它可能更像是一種錯覺，而不是提升團隊交付實際價值的能力。

翻譯自 Broken Promises of the Low-Code Approach 。

圖片來自 Shutterstock 的 seamind224

這是一個三部曲系列的第一部分。

很容易被低代碼和無代碼解決方案的熱情所席卷（我將簡稱為低代碼），特別是考慮到它們誘人的簡單性和用戶友好的界面的吸引力。它們被譽為解決 IT 技能差距的答案，使非技術用戶能夠在無需編寫一行代碼的情況下創(chuàng)建功能應用。然而，這些工具對于您的團隊的實際效果往往更像是一種幻覺，而不是一個能夠徹底改變局面的東西，尤其是在不斷演變的編程趨勢和工具的背景下進行審視時。

低代碼的誘人之處

低代碼平臺具有不可否認的吸引力，尤其適用于渴望釋放團隊速度和敏捷性、實現(xiàn)快速應用開發(fā)的領導者。對廣泛編碼知識的需求被消除，節(jié)省了 IT 資源，并使能夠為應用開發(fā)做出貢獻的能力民主化。對于擁有有限 IT 資源的中小型企業(yè)而言，這可能是一個重要優(yōu)勢。

同樣具有吸引力的是低代碼解決方案的成本效益。通過減少對經(jīng)驗豐富的程序員的依賴，這些平臺有可能大幅降低勞動力成本，而這些程序員往往成本更高且更難以留住。此外，許多低代碼平臺提供內置的可擴展性，使應用能夠處理隨著用戶群體增長而增加的負載。

低代碼核心的誤解

事實是，許多低代碼解決方案在軟件開發(fā)方面存在根本誤解：它們將理解編程語言語法的挑戰(zhàn)與設計有效的應用邏輯的挑戰(zhàn)混為一談。編程語言只是工具；它們的語法僅僅是表達解決方案的手段。軟件開發(fā)的真正核心在于問題解決，即制定算法、數(shù)據(jù)結構和接口，以高效地滿足應用的需求。

通過圖形用戶界面（GUI）來簡化軟件開發(fā)，低代碼解決方案在不必然簡化設計強大應用的基本挑戰(zhàn)的情況下替代了語法。這種方法可能會引入多個缺點，同時未能減輕軟件創(chuàng)作的真正復雜性，最終可能對團隊交付真正價值的能力產(chǎn)生負面影響。

低代碼解決方案的其他陷阱

低代碼解決方案經(jīng)常在有限的定制性方面掙扎，通常無法滿足特定、復雜或獨特的業(yè)務需求。供應商束縛的風險是另一個重大不利因素，如果定價、功能提供或供應商關閉，用戶可能會陷入困境。我曾親身經(jīng)歷過這些事件，團隊的結果相當災難性。他們面臨嚴重的技能缺口和長時間的低生產(chǎn)力期。

性能和效率問題也是一個問題。通過低代碼平臺開發(fā)的應用可能不如使用傳統(tǒng)代碼精心設計的應用性能好，特別是對于大型復雜應用而言。

簡單的承諾往往導致意想不到的復雜性現(xiàn)實。雖然低代碼平臺在創(chuàng)建簡單應用方面表現(xiàn)出色，但在處理更復雜場景時往往不夠出色。當這些工具由缺乏開發(fā)復雜系統(tǒng)經(jīng)驗的人使用時，這種挑戰(zhàn)通常會加劇。

最近的趨勢提供了一種替代方法

考慮到上述挑戰(zhàn)，隨著幾乎適用于各種情況的代碼庫和框架的不斷增多，低代碼解決方案的價值進一步削弱?？紤]一些框架，如 Next.js 和 Nitric ，或平臺如 Supabase 和 Vercel。這些較新的面向開發(fā)者的工具通常比低代碼等價物更具生產(chǎn)力，而且肯定使最終的應用更具未來可靠性。

這些解決方案采用了一種不同的提高生產(chǎn)力的方法。它們簡化了開發(fā)人員的工作流程，保持了傳統(tǒng)編碼中固有的靈活性，而不是替代小眾的低代碼選擇。這使得低代碼解決方案經(jīng)常難以適應的定制性、適應性和復雜性的能夠保持開放，同時允許有限的開發(fā)團隊以更少的代碼實現(xiàn)更多的成果。

我管理的團隊通常更熱衷于使用面向開發(fā)者的框架和工具；它們提供更愉快的開發(fā)體驗，并擁有更廣泛的社區(qū)支持。這使得開發(fā)團隊有動力學習和擴展技能，這些技能將為實現(xiàn)他們個人目標以及團隊目標提供幫助。

總結

低代碼解決方案雖然實現(xiàn)了軟件開發(fā)的民主化，但也帶來了一系列限制和潛在的缺陷。在某些情況下，根本的誤解在于將編程語法與軟件開發(fā)的真正挑戰(zhàn)——問題解決和應用設計等同起來。

此外，全面的代碼庫和開發(fā)者友好的框架的出現(xiàn)，挑戰(zhàn)了低代碼工具的相關性。通過賦予開發(fā)者權力并簡化其工作流程，同時保持靈活性，這些現(xiàn)代解決方案提供了一種更具未來可靠性的軟件開發(fā)方法。

我們認為目標應該是更少的代碼，而不是低代碼，我們關于這個主題的下一篇文章將討論為什么以及如何使用新工具來實現(xiàn)這一點。

與此同時，可以了解一下我們在開源的 Nitric 框架中通過自動化來減少所需代碼的做法。

這兩種方法無疑必須共存，根據(jù)項目的復雜性和需求提供不同的服務。然而，了解這些微妙之處對于有效地導航軟件開發(fā)領域并在每種情況下利用適當?shù)墓ぞ咧陵P重要。