程序員為什么害怕低代碼？

程序員為什么害怕低代碼？

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

恐懼來自哪里？

我是一名年近40歲的程序員，在這家公司里先后從事過WinForm、Web和移動APP的開發。不能否認，面對低代碼技術時，我是有些恐懼的：沒有受過專業訓練的平民開發者可以先學習SQL（甚至可以跳過這一步），然后學習一種低代碼工具并投入開發過程中，我的工作可能也就終結了。

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

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

低代碼平臺只是一款工具

在科幻電影中，我們看到過不止一次的“人工智能大災難”，軟件最終會完成自我開發并最終征服人類。低代碼是否也會像電影中那樣，自己完成軟件開發？答案當然是否定的，低代碼平臺僅僅是一種工具而已。和其他所有的工具一樣，其價值源自于它的使用者。設想一下，大多數軟件都可以基于低代碼平臺進行開發，這意味著老板們隨便雇用張三、李四，而不是專業的程序員就可以進行在低代碼開發平臺上拖拉拽出一個報銷系統、填報表單。但是，如果沒有必要的軟件基礎知識，他們的能力也就到此為止了。

與標榜為無代碼的“開發工具”不同，低代碼開發平臺具備更強的擴展性，比如活字格就提供了自定義JavaScript/CSS，高級SQL查詢和C＃接口。這使得經驗豐富的專業開發者——比如我——可以在低代碼平臺上完成那些可視化開發不能滿足的需求，最終交付更復雜的系統。

（使用低代碼構建的ERP系統頁面，圖片來自活字格官網）

更重要的是，開發者更了解軟件、計算機架構、數據庫、Web端等的基本原理。這種知識儲備使他們能夠提高工作效率，進行平臺優化，少走彎路。這遠遠超過了張三、李四等平民開發者能做的。所以，沒有受過專業編程訓練的平民開發者能夠使用低代碼開發平臺構建出面對特定場景的簡單應用，但是，對于ERP、MES等為核心應用場景而生的更高價值的大型系統，依然是專業開發者的主舞臺。低代碼只是專業開發者手邊更趁手、更高效的工具罷了。

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

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

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

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

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

與對失業的恐懼不同，這種擔憂是有價值的。就我個人而言，我屬于A組——就是我剛才很友善地稱贊過的那個組——因為我不僅是一個值得信賴的程序員，而且喜歡自夸。

但是，當我與專業開發者討論低代碼時，他們向我保證，這些低代碼開發平臺是個危險的黑盒子，他們擔不起在無法控制的“黑盒”上開發關鍵任務帶來的風險，比如平臺不穩定怎么辦、開發進度過半發現有問題無法解決怎么辦等等。首先，這種邏輯看起來沒毛病，所以，我將花更大的篇幅來解釋為什么這種恐懼是不合理的。

低代碼的技術棧并不特殊

首先，低代碼的黑盒子是在開發者熟悉的技術棧上運行，而這些技術棧本身和低代碼類似，也經歷了被逐步認識、喜愛、鄙視并再次喜愛上的過程。比如活字格低代碼開發平臺就是的服務端是采用.net開發的（畢竟葡萄城在1980年代加入了Microsoft Early Adopter Partnership），前臺則完全使用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、企業微信和釘釘。所以，也許是時候給低代碼這個不算很新的黑盒子多點信心了。

（使用低代碼構建的SCM系統門店銷售終端頁面，圖片來自活字格官網）

對了，前面提到的那些控件的廠商也推出了低代碼開發平臺，如果你對低代碼行業的初創企業實在沒有信心，可以先從那些來自開發控件廠商的產品（如Kinvey、活字格等）開始。

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

到這里，我們已經粉碎了失業的威脅，粉碎了對黑盒子的恐懼。那還剩下什么？應該是對失去挑戰及成就感的擔憂，因為它比其他所有類型的恐懼更可怕。

每當深夜下班，程序員們結束工作離開辦公室時，手中都掌握著自己所擁有的技能。有些人可能會會心滿意足地休息，太陽再次升起之前都不會使用這些技能。但是其他的，譬如那些激情四射的黑客，他們會利用個人時間來擺弄一些業余項目。他們也許會修補開源代碼，也許在學習新的框架，還有可能會回答StackOverflow、知乎或其他社區上的問題。

（不眠不休的騰訊辦公樓，圖片來自網絡）

他們熱愛編碼，因為編碼可以解決復雜的問題、憑空構造產品，作用相當于現代煉金術。他們的技能賦予自己力量和尊重。而低代碼則有可能威脅到他們的地位。

畢竟，只需花費很少量時間來掌握軟件工程知識，就能學會低代碼開發。當低代碼成為企業軟件開發的首選工具后，專業開發者的威望很可能會隨之降低。這些平臺可以預先解決大多數復雜的問題，如負載平衡、資源分配、加密甚至界面交互等。這意味著使用低代碼做開發的人在日常工作中幾乎沒有什么需要克服的障礙和挑戰。程序員該如何獲得成就感呢？事實上，低代碼能夠幫我們解決更大的問題，那就是如何更快速的完成軟件交付，而這才是成功的關鍵。

企業想要快速發展

企業需要以一種能夠匹配競爭對手、供應商和現代消費者稍縱即逝渴望的速度來進行變革。如果仍保持以蝸牛般速度升級的舊版軟件，企業如何能夠實現這樣的速度？

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

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

辦法確實存在，但已經超出了編碼本身。也許你正在企盼自己成為一個領導者，而不單是一個程序員，而要想成為領導者，就要超越自己的角色，看清大局。

這里的大局并不是 “解決復雜問題”或“重新考慮解決方案”，而是如何快速發布產品，快速發布用戶滿意的產品。如果你不得不緩慢、費力、容易出錯的工作，而有一種技術能夠以同樣成本獲得快速、精確、準確的結果，我想你的選擇是顯而易見的。

所以，對程序員這份工作來說，最大的成就感應該源于其通過自己開發的軟件讓更多人的生活更加美好，而不是加班工作本身。我寧愿擁有一個低代碼庫和無窮多的滿意用戶，也不愿抱著自己編寫的專有源代碼，以及一堆褒貶不一的評論。

開始行動吧

當然，專業開發者還可能出于一些本文沒有提及的原因害怕低代碼平臺，因為人們可能對每種特定產品都存在更狹隘的懷疑。然而，對失業、黑盒、喪失成就感的恐懼是常見且真實的。如果你已經克服了這些非理性的恐懼，那就開始使用低代碼工具，乘著軟件開發技術的發展趨勢，從更高效率的開發中獲益吧。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。