失業？黑盒？一文破解：程式員為何害怕低代碼？

失業？黑盒？一文破解：程式員為何害怕低代碼？

——低代碼是一種近些年興起的軟體快速開發技術和工具，借助低代碼使用者無需編碼即可完成企業應用的常用功能，少量編碼擴展出更多功能，低代碼憑借低門檻、高效率和易集成等特性，被越來越多的軟體開發團隊青睞，Gartner預測，到2024年四分之三的大企業將會使用至少4種低代碼開發平臺，用于資訊化應用開發，屆時，65% 的應用開發將通過低代碼完成，

看上去，低代碼是一種顛覆性的技術，那么，低代碼會不會取代專業開發者？如果你是一名企業軟體領域的程式員，這篇文章也許可以減輕你的恐懼，

恐懼來自哪里？

不能否認，很多資深程式員面對低代碼技術時，或多或少有些恐懼的：沒有受過專業訓練的平民開發者可以先學習SQL（甚至可以跳過這一步），然后學習一種低代碼工具并投入開發程序，那專業程式員的作業可能也就終結了，

（傳統的軟體開發方式，圖片來自網路）

這個想法也曾變成我內心短暫而真實的恐慌，在與捷碼低代碼開發平臺的核心員工進行過幾次討論之后，我意識到了自己邏輯上的錯誤，而這個錯誤恰好就是低代碼永遠不會取代我，也根本不打算取代我的原因，我想，充分了解這些論點，可以緩解你和你的團隊對低代碼的恐懼感，并防止他們陷入對低代碼的恐懼中，

低代碼平臺只是一款工具

在科幻電影中，我們看到過不止一次的“人工智能大災難”，軟體最侄訓完成自我開發并最終征服人類，低代碼是否也會像電影中那樣，自己完成軟體開發？答案當然是否定的，低代碼平臺僅僅是一種工具而已，和其他所有的工具一樣，其價值源自于它的使用者，設想一下，大多數軟體都可以基于低代碼平臺進行開發，這意味著老板們隨便雇用張三、李四，而不是專業的程式員就可以進行在低代碼開發平臺上拖拉拽出一個報銷系統、填報表單，但是，如果沒有必要的軟體基礎知識，他們的能力也就到此為止了，與標榜為無代碼的“開發工具”不同，低代碼開發平臺具備更強的擴展性，比如“捷碼”低代碼平臺，在技術和框架上就對深度二開提供了友好的支撐與實作，這使得經驗豐富的專業開發者——比如我——可以在低代碼平臺上完成那些可視化開發不能滿足的需求，最終交付更復雜的系統，

更重要的是，開發者更了解軟體、計算機架構、資料庫、Web端等的基本原理，這種知識儲備使他們能夠提高作業效率，進行平臺優化，少走彎路，這遠遠超過了張三、李四等平民開發者能做的，所以，沒有受過專業編程訓練的平民開發者能夠使用低代碼開發平臺構建出面對特定場景的簡單應用，但是，對于很多應用場景復雜、資料接入、整合與治理要求高的高價值的軟體系統，依然是專業開發者的主舞臺，低代碼只是專業開發者手邊更趁手、更高效的工具罷了，

低代碼是一個值得信賴的“黑盒子”

低代碼平臺不會取代專業開發者，相比于平民開發者，專業開發者依然有著很強的優勢，但這一發現并不能真正將開發者變成低代碼的支持者，尤其是當他們第一次開始嘗試去了解低代碼的時候，

（典型低代碼開發平臺的設計器界面）

開發者對這些低代碼平臺所見即所得設計器有兩種反應：

A： “我的天啊，看看我能以多快的速度開發出XXX！”，這是一個了解時間價值并欣賞抽象之美的人，另一種更為突出的反應是B：“我不相信有人能用這個搞出YYY！”，

與對失業的恐懼不同，這種擔憂是有價值的，就我個人而言，我屬于A組——就是我剛才很友善地稱贊過的那個組——因為我不僅是一個值得信賴的程式員，而且喜歡自夸，但是，當我與專業開發者討論低代碼時，他們向我保證，這些低代碼開發平臺是個危險的黑盒子，他們擔不起在無法控制的“黑盒”上開發關鍵任務帶來的風險，比如平臺不穩定怎么辦、開發進度過半發現有問題無法解決怎么辦等等，首先，這種邏輯看起來沒毛病，所以，我將花更大的篇幅來解釋為什么這種恐懼是不合理的，

低代碼的技術堆疊并不特殊

首先，低代碼的黑盒子是在開發者熟悉的技術堆疊上運行，而這些技術堆疊本身和低代碼類似，也經歷了被逐步認識、喜愛、鄙視并再次喜愛上的程序，比如“捷碼”低代碼開發平臺，就貫通了軟體開發的前端、后端和系統運維等開發程序的全技術鏈，也全面支持WEB、APP、小程式、3D可視化、大屏可視化等方向的開發實作，設計前臺完全使用JavaScript，資料庫方面兼容SQLite、SQL Server、MySQL等主流資料庫，這些完整的技術堆疊確保開發者不需要在不同的平臺之間切換，無需擔心不同平臺的兼容性障礙，更保障了低代碼開發平臺自身的穩定性和可靠性，而且，重要的是，平臺的編程介面也基于這些技術，所以，開發者可以將現有的服務器代碼、SQL視圖及存盤程序、樣式表等添加到使用低代碼開發的專案中，這么看來，你對低代碼的穩定性、擴展性等擔心，是不是有些多余了呢？

人人都愛黑盒子

事實上，我們都愛“黑盒子”，尤其是可以幫我們大幅節省時間的黑盒子，Java及其姊妹語言Scala，Groovy，和其他語言一樣依賴于開發者中最受歡迎的黑盒：JVM；而C#、VB.net依托在.net Framework上才能運行，那么，為什么我們會信任JVM、.net而不是低代碼呢？因為時間可以為這些平臺證明，

21世紀初，.net在誕生時也受到開發者社區的嚴格審查，但在看到它年復一年地順利運行后，信任度增加了，開發者知道C#和.net仍然會存在很長一段時間，而微軟將繼續支持這兩者，我不知道微軟將會如何執行我的C#，但是我依然信任著它，就像我相信V8引擎執行我的JavaScript，JVM運行我的Java一樣，當然，我也不能忘記曾經依賴的其他著名的黑盒：Spread、KendoUI、ActiveReport等前端控制元件，正是因為有了這些控制元件，我們開發應用的效率得到了數倍的提升，如果你從事程序式界面的開發，我相信你一定會和我有同感，事實上，低代碼并不是一個這兩年橫空出世的技術，只是近些年更受媒體關注而已，十幾年來，已經有太多的案例能向你證明這個“黑盒子”的真實實力，應用場景從MES、ERP到SCM以及SCRM，終端平臺也支持PC瀏覽器、APP、企業微信和釘釘，所以，也許是時候給低代碼這個不算很新的黑盒子多點信心了，

低代碼能夠帶來更大的成就感

到這里，我們已經粉碎了失業的威脅，粉碎了對黑盒子的恐懼，那還剩下什么？應該是對失去挑戰及成就感的擔憂，因為它比其他所有型別的恐懼更可怕，每當深夜下班，程式員們結束作業離開辦公室時，手中都掌握著自己所擁有的技能，有些人可能會會心滿意足地休息，太陽再次升起之前都不會使用這些技能，但是其他的，譬如那些激情四射的黑客，他們會利用個人時間來擺弄一些業余專案，他們也許會修補開源代碼，也許在學習新的框架，還有可能會回答StackOverflow、知憾訓其他社區上的問題，他們熱愛編碼，因為編碼可以解決復雜的問題、憑空構造產品，作用相當于現代煉金術，他們的技能賦予自己力量和尊重，而低代碼則有可能威脅到他們的地位——畢竟，只需花費很少量時間來掌握軟體工程知識，就能學會低代碼開發，當低代碼成為企業軟體開發的首選工具后，專業開發者的威望很可能會隨之降低，這些平臺可以預先解決大多數復雜的問題，如負載平衡、資源分配、加密甚至界面互動等，這意味著使用低代碼做開發的人在日常作業中幾乎沒有什么需要克服的障礙和挑戰，程式員該如何獲得成就感呢？事實上，低代碼能夠幫我們解決更大的問題，那就是如何更快速的完成軟體交付，而這才是成功的關鍵，

企業想要快速發展

企業需要以一種能夠匹配競爭對手、供應商和現代消費者稍縱即逝渴望的速度來進行變革，如果仍保持以蝸牛般速度升級的舊版軟體，或者經常因為各種原因不得不推遲向甲方交付軟體專案，那么程式員如何賺到更多錢？養程式員的企業，如何能夠實作事業的快速發展與壯大？

然而，使用傳統的開發方式撰寫軟體是一項艱巨且緩慢的任務，容易出現人為錯誤，根據我的經驗，程式員撰寫代碼的速度和他們出錯的數量之間存在指數關系，寫的越快，Bug越多，因此，更快地編碼其實并不是一個可行的選擇，還有沒有別的辦法？

站在領導者的角度考慮這個問題

辦法確實存在，但已經超出了編碼本身，也許你正在企盼自己成為一個領導者，而不單是一個程式員，而要想成為領導者，就要超越自己的角色，看清大局，這里的大局并不是 “解決復雜問題”或“重新考慮解決方案”，而是如何快速發布產品，快速發布、交付用戶滿意的產品，如果你竭力想避免緩慢、費力、容易出錯的成果交付，那么低代碼平臺帶來的快速、精確、準確的結果，應該就是你所渴求的，所以，對程式員這份作業來說，最大的成就感應該源于其通過自己開發的軟體讓更多人的生活更加美好，而不是加班作業本身，我寧愿擁有一個低代碼庫和無窮多的滿意用戶，也不愿抱著自己撰寫的專有源代碼，以及一堆褒貶不一的評論，

開始行動吧！

當然，專業開發者還可能出于一些本文沒有提及的原因害怕低代碼平臺，因為人們可能對每種特定產品都存在更狹隘的懷疑，然而，對失業、黑盒、喪失成就感的恐懼是常見且真實的，如果你已經克服了這些非理性的恐懼，那就開始使用低代碼工具，乘著軟體開發技術的發展趨勢，從更高效率的開發中獲益吧，我個人從專業度及切身感受出發，偏向認同“捷碼”低代碼平臺——是一款值得廣大同行去體驗的SAAS化平臺型工具，

東看西看，不如動手快人一步~

添加捷碼微信~

回復《博客園》領取《阿里巴巴大資料實踐（338頁資料）》資料禮包
回復《試用》免費申請試用賬號

合作咨詢：400-6565-277

標籤：其他

上一篇：Vulnhub實戰-dr4g0n b4ll靶機👻

下一篇：學習方法：用輸出倒逼輸入