低代碼和無代碼(LC/NC)工具制造商正面臨一場艱苦的戰斗，試圖說服人們，尤其是專業開發人員，使用甚至只是嘗試他們的工具和平臺。少數平臺已經進入這個市場，但大多數軟件開發無疑仍然是由編寫代碼的專業人員完成的。

從工具制造商的角度來看，缺乏興趣似乎令人困惑。更快的開發、更低的成本、更少的錯誤、更容易的部署、托管的環境——為什么有人會拒絕這些烏托邦式的視覺工具制造商喜歡展示的東西?為什么這么多人寧愿繼續與困難的語言、復雜的錯誤跟蹤和晦澀的環境設置作斗爭?

我一直在與開發人員交談，閱讀文章，并在討論論壇上搜索這些問題的答案，并整理了一些提出的原因。

這對他們的事業沒有幫助

學習低代碼工具可能需要大量的時間和精力投入，但學習特定的LC/NC工具幾乎沒有專業價值。即使在軟件開發公司很少使用LC/NC工具的情況下，下一個雇主也很可能不需要員工開發人員通過學習該工具獲得的技能。

大多數開發工作都需要對廣泛使用的語言和框架有深入的了解和經驗，并且沒有像React、Angular、Python、Java或C#這樣廣泛使用的低代碼工具。

很少有開發工作需要了解LC/NC工具，而開發人員在知道LC/NC工具后找到更好工作或賺更多錢的可能性非常低。因此，開發人員最好花時間學習和完善就業市場上需求量很大的無數技能、框架和語言之一。

開發人員花了數年時間學習如何編寫代碼

在2021年 Stack Overflow開發者調查中，近70%的開發者聲稱他們擁有計算機科學或相關學科的學士學位或更高學位。這意味著大多數開發人員花費數年時間學習編程、學習各種語言、系統架構，以及普遍練習和完善編寫代碼的藝術。使用LC/NC工具通常意味著放棄他們來之不易的經驗和投資所代表的優勢。因此，大多數開發人員更愿意依靠他們已經辛苦獲得的寶貴技能也就不足為奇了。

如果LC/NC工具確實兌現了它們的承諾，那么未來將不再需要編寫代碼來創建應用程序。編程將移動到更高的抽象級別，應用程序將從現有組件組裝而不是編碼。因此，程序員基本上威脅要通過使用和支持更多地使用LC/NC工具來使他們來之不易的技能變得多余。因此，LC/NC工具不成功實際上符合他們的利益。

開發人員不太關心速度

當開發人員為軟件公司工作時，他們通過交付具有特定特征的代碼獲得報酬。這些包括易于閱讀、可測試、結構良好、可靠、高效、遵循標準等。維護中等復雜應用程序的開發人員會明白確保代碼盡可能簡單和易于理解的重要性。這些品質對于代碼的可維護性至關重要。

代碼通常由更高級的程序員審查，他們也關心這些品質并強調它們。與開發人員相比，他們可能對更快地完成工作更感興趣，但他們知道代碼錯誤、效率低下、編寫晦澀難懂且難以擴展是難以維護的。

這個糟糕的代碼會導致很多麻煩，并且會變得非常昂貴。雖然交付代碼的速度是相關的，但代碼的組織和編寫方式通常優先于交付速度。

因此，向開發人員推銷LC/NC工具的開發速度實際上可能不會產生預期的影響。

開發人員喜歡編碼

人們是模糊的和情緒化的。他們有相互沖突的優先事項，經常不確定、不準確和撒謊。通常他們甚至不知道自己在做什么以及為什么要這樣做。人們可能會很困惑。計算機要簡單得多。計算機只是按照程序員給出的指令進行操作，如果這些指令不正確，程序就會失敗。定義一組任務并看到它們立即準確地完成的精確度給了許多人一種安全感和快樂感。

編碼中有許多開發人員真正喜歡的創意元素。編程是一個非常復雜的謎題，充滿了腦筋急轉彎，跨越了幾十個模塊、多層和數千行代碼。單個Web應用程序可以很容易地包含五種或更多不同的語言一起工作（例如HTML、JS、CSS、C#、SQL)。制作由聯鎖運動部件組成的復雜物體，并觀察它們在微妙的循環中工作，因為它們發揮了內置邏輯的后果，這可能會令人著迷，并帶來強烈的成就感。

軟件存在的原因是為了讓生活更輕松，我們從根本上構建軟件來幫助人們做得更好。一旦你知道如何編寫代碼——用任何語言——你就可以構建任何你能想象到的東西。想象一些東西然后從無到有創造它是一種快樂，尤其是當它對他人有用并讓他們快樂時。

開發人員不會選擇技術堆棧

開發人員在項目中停留的時間越長，他們在擴展應用程序方面就越好，他們在發現和解決問題方面的效率就越高。當開發人員離職時，他們通常會隨身攜帶有關應用程序復雜細節的深入了解。這種知識很難重新獲得，當這些員工被替換時，他們支持的應用程序往往會進入不穩定階段，有時甚至會陷入混亂。因此，盡管軟件公司對穩定性很感興趣，但軟件開發人員通常只在一個雇主那里呆幾年。

軟件公司用來減輕知識損失的一種策略是使用在開發人員社區中廣泛使用和眾所周知的技術。使用眾所周知的堆棧可以更容易地找到有技能的人來雇用。它還可以幫助這些人了解使用他們構建的應用程序的來龍去脈。開發人員可能是決定將哪些技術用于項目的影響者，但通常是高級工程師甚至管理層使用這些標準來決定堆棧。因此，向開發人員推銷LC/NC工具可能會錯失良機。

押注工具是有風險的

客戶往往很難確定他們將來可能會在哪里申請。這是可以理解的，因為未來很難預測。因此，應用程序所有者需要適應不斷變化的需求，以確保應用程序的商業成功。這通常意味著修改商業模式并改變支持這種模式的技術。經驗豐富的開發人員知道這一點，并且喜歡構建能夠適應未來不斷變化的需求的開放系統。創建這種適應性強的系統的最佳方法是使用支持良好的語言和框架對其進行編碼。

許多 LC/NC工具都是新的、不成熟的，并且具有很大的技術限制。這些限制通常不會被宣傳，而且通常也只是很少記錄。軟件公司真正找到這些限制的唯—方法是嘗試一個工具并構建一個真正的應用程序。大多數限制只有在投入大量時間和精力后才會變得明顯。軟件開發既昂貴又冒險，而這些未知因素進一步增加了開發人員、軟件公司及其客戶的風險。

鎖定交易

許多平臺不允許將該平臺中構建的應用程序導出為通用的、可編輯的格式。他們鎖定應用程序，從而要么將開發人員綁定到平臺，要么要求他們從頭開始重建他們的應用程序。考慮到未來的需求是不確定的，而且 LC/NC 工具的局限性通常會一直隱藏到項目的后期，因此開發人員可能會非常警惕被鎖定也就不足為奇了。

LC/NC過去曾多次失敗

可視化開發工具并不新鮮。視覺發展的早期嘗試已經在50年前進行。從那時起，大量好的和壞的可視化開發環境和平臺來來去去，但它們都沒有對應用程序的創建方式產生重大影響。

任何押注任何這些工具、投入時間和精力來學習它們并說服客戶在其中任何一個上構建項目的人都輸了。這段歷史表明，我們今天遇到的任何工具都不太可能在十年后仍然存在。許多開發人員可能會仔細考慮這些事實，并認為LC/NC是一條死胡同。

怎么辦?

那么，LC/NC是失敗的原因嗎?在嚴肅的軟件開發世界中是否沒有LC/NC的位置?LC/NC工具制造商能否以某種方式克服這些障礙并激勵更多開發人員使用LC/NC產品?

由于對 LC/NC工具和宣傳它們的營銷傳播缺乏信任，許多開發人員更喜歡代碼。為了說服任何專業人士使用LC/NC平臺，平臺制造商要求開發人員信任他們。為了建立這種信任，工具制造商最好聽取開發人員和軟件公司提出的擔憂，并在規劃平臺功能和與目標群體溝通時將其考慮在內。

誠實和真實地披露功能限制、發布克服限制的方法、拉平平臺的學習曲線以及允許將應用程序導出為可編輯格式，雖然它們可能無法說服所有開發人員，但它們朝著正確的方向邁出了一步。