“零代码”时代已来！程序员真的要去送外卖了？
作者：流水不爭先??編輯：Emma
來源|?技術領導力(ID：jishulingdaoli)
“零代碼”和“低代碼”的概念是同時提出的，二者經歷的背景都一致，所以就不做贅述了。
軟件業經過幾十年的發展，對于可視化編程語言和高級編程語言的開發逐漸成熟，同時市場對于SaaS軟件的需求逐漸旺盛。
程序員都希望把軟件項目的開發成本降低、開發效率提高，于是著名的咨詢公司Forrester提出了“零代碼”和“低代碼”的概念，并帶動小眾的ISV開始研究“低代碼”和“零代碼”應用開發平臺，開創出一條軟件行業新賽道。
回顧一下“低代碼”和“零代碼”的概念：只需用很少甚至幾乎不需要代碼就可以快速開發出系統，并可以將其快速配置和部署的一種技術和工具。
由于“零代碼”對編程工具可視化、簡潔性的要求非常高，很少ISV能開發出完全“零代碼”的產品，也因此“零代碼”的發展速度比“低代碼”稍慢一些。
“低代碼”應用平臺在2014年左右進入中國市場，目前處于成長期；而“零代碼”應用平臺則晚了兩年，還在市場導入期。
在今天來看，國內相對知名的低代碼軟件廠商有34家，但零代碼軟件廠商只有17家。（數據來自中軟網海比研究院《2021年中國低代碼&無代碼市場研究報告》）
“零代碼”的技術特點
如果你試著百度搜索“零代碼”就會發現，現在市面上的零代碼開發平臺除了色彩不一，內部的功能設計、列舉的產品特色都大同小異：
功能靈活，隨改隨用。
實時生成應用搭建效果，所建即所見，所見即所得。
交互設計友好化，直觀化：拖拽小組件來完成表單配置；以垂直流程圖的視覺來呈現自動化工作流或智能機器人的流程動作。
靈活對接外部系統或插件：釘釘、企業微信對接是標配，Zapier、Processon對接是極客玩法，各種電商、SAP、供應鏈系統對接則是高水平動作。
支持跨平臺使用：PC、Web、APP、H5、小程序。
以上“零代碼”的技術特點自然能延伸出它的優點：
高效開發應用，節省時間和人力成本。
操作界面和開發邏輯都視覺化、交互化，對電腦小白而言更容易理解和使用。
開發和維護費用低，因為底層的功能都做好了，開發和維護都只是功能調用的工作，復雜度降低，所以比傳統軟件定制開發的項目報價便宜不少。
和外部系統的兼容性、互補性強，只要外部系統提供數據接口，雙方就可以測試接通，在數據傳輸和響應上靈活互動。
作者本人也是“零代碼”賽道的從業者，要說好話是十分容易。而談到缺點，我更希望以我在工作中的所見所歷，幫助大家代入場景去理解。
高度靈活化、去代碼化會犧牲平臺固定設計的自定義自由度。
我曾經碰過一個客戶，她對某個零代碼平臺的界面設計不滿，堅持要求數據要橫向排列而非縱向排列；應該提供一個調色板，讓界面所有色彩部分都能自定義搭配。對于產品要求如此“擰巴”的客戶，產品經理聽到了恐怕只能扶額擺手，感慨不易。
處于市場進入階段的零代碼產品，會更注重功能完善、平臺穩定、用戶理解和使用門檻。過度強求產品固定設計的編輯自由度，就有點舍本逐末了，倒不如直接走全定制開發來得痛快。我相信，對于比較常見、確實影響使用的功能需求，產品經理一定會認真考慮，納入規劃路線圖的。
超出現有功能的需求仍然需要寫代碼來實現。
將用戶的新歷生日自動換算成農歷生日，從用戶的身份證號碼中提取出生日期和性別，去掉手機號字段中的“+86”……這些需求看似還挺日常和普遍的，但其實現在大部分零代碼應用平臺都無法做到這么細致的功能點。不過，平臺開發者留出了“代碼塊”功能，讓IT極客們滿足特殊需求。
CSDN上有部分程序員提出：一些簡單但少用的數據處理動作，在Excel上用函數也能輕易完成，用代碼塊反而會變得更繞了。的確，這一點也是當前“零代碼”的劣勢。
外部系統集成需求無法完全滿足。
目前雖然絕大部分“零代碼”廠商都宣稱能做到外部系統對接，但真正成功的例子卻較少，因為它除了考驗平臺擴展能力外，還考驗廠商技術團隊的服務能力和甲方技術團隊的配合度。
一家大型國有傳統制造集團曾經找過一家零代碼ISV，希望做一個ERP系統，并把他們老ERP系統的部分功能對接過來，以便集團員工逐步從老系統過渡到新系統。理想很豐滿，現實卻泡湯了。
失敗的原因是綜合的：甲方光提需求，沒有配合乙方提供老ERP系統的接口數據；甲方和老ERP系統開發商的溝通也是難題，一般老開發商不太情愿配合，畢竟是要把自己的生意讓出去；乙方的實施顧問“手藝”未精，也很容易把項目弄垮。
很多技術人員都會從產品功能角度說用“零代碼”集成外部系統的無能；但作者反而認為，是現實項目中多方解決實施困難的決心和行動力不一致導致了這個問題。
看完以上的缺點，或許有讀者會覺得：那“低代碼”還是比“零代碼”好一點呀，畢竟還能更靈活地實現比較復雜的需求。對此，我找到一張“低代碼”和“零代碼”的對比圖，幫助大家做多維度對比，對號入座，選擇更適合自身情況的一種。
圖自：明道云博客《零代碼與低代碼快速開發平臺的區別》
關于“零代碼”，我的三個觀點
上一篇科普“低代碼”的文章里，我寫了不少關于“低代碼”行業前景的觀點和材料。這次，我給大家分享三點感觸，希望幫助大家對“零代碼”樹立新的體會。
“零代碼”是中年編程小白的末班車
互聯網行業爆發以來，人人都見證了程序員在社會地位上的躍進。招聘網站上鋪滿了程序員急招信息，高校、中小學、甚至連幼教都開設編程課，朋友圈和公眾號上充斥著“30天快速上手Python”的網課。時代在告訴每一個人：不學點編程，你就落后了。
可是對80年代以前的編程小白而言，學編程談何容易，能把房子、工作、一日三餐處理好就不錯了。“零代碼”對他們而言，算得上是“學編程”的替代品，能借助“零代碼”做出和代碼處理效果類似的成果，也能多添一個本領。（當然，替代程度大概僅為50%，也不錯了）恰好，這個群體在職場上也到了管理者的位置，熟悉業務運轉和行業特點，十分適合挑起大旗，搭建業務管理應用。
用什么來證明“零/低代碼”有好未來：4.5億個應用
我讀過一篇很有意思的文章，里面提到：微軟曾簡單計算過，未來5年將有4.5億款新應用程序將被開發出來，這比過去 40 年里開發的所有應用程序都要多。微軟公司公民應用平臺副總裁Charles Lamanna說：“如果這是真的，那么這4.5億款軟件必須使用低代碼或零代碼工具。而專業的開發人員應該專注于比費用提交表單或審批表單更困難的挑戰。”
截至2019年4月，AppSheet已經在谷歌的零代碼平臺上創建了180 萬個應用——4.5億的進度條已啟動了0.4%。
別讓人人都自信地成為“零代碼”應用開發者
“零代碼”雖然降低了業務管理應用的開發門檻，但也很容易讓對業務架構理解不當的員工盲目自信，開發出設計不當的應用，引發更大的管理問題。
曾有一家美國大型保險公司繼承了1.6萬個基于Quick Base（一款低代碼開發平臺）的應用程序，但業務員把它們運行在Quick Base的退役版本上，導致系統運作混亂。我遇到過某家公司的業務經理，他梳理的業務流程圖就像縫衣服一樣，線路交錯，只找到流程開頭和結尾，叫人哭笑不得。至于后續他把零代碼應用做得如何，就不得而知了。
個人認為，真正對客戶負責的“零代碼”ISV，必然是對客戶教育負責的。他會建立適當的流程和基礎設施，作為使用引導；并配備豐富的功能學習資源，如標準的業務應用模版、學習資料、定期用戶交流活動等。先給用戶賦能了，再讓他們開始大干一場。
尾語
有人瞌睡，就會有人送枕頭。有人看到了軟件開發過程復雜、漫長的痛點，于是做出低代碼應用平臺。有人看到了低代碼應用平臺在使用門檻和靈活度上的不完美，于是做出“極致”的零代碼應用平臺，讓“Less is more”的“Less”做到“Least”。
軟件行業作為一個反脆弱的系統，必然會生生不息，不斷迭代。“零代碼”不會是軟件開發的句號，總有一個新名詞會取代“Least”。我們一起拭目以待，距離下一個替代零代碼的“枕頭”出現，還會有多遠。
參考：
《零代碼與低代碼快速開發平臺的區別》，明道云博客
《無代碼編程》，phodal?
《無代碼，低代碼開發，未來5~10年發展趨勢》，xyyy
《2020低代碼/無代碼行業發展研究報告》，海比研究院
有道無術，術可成；有術無道，止于術
歡迎大家關注Java之道公眾號
好文章，我在看??
新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！總結
以上是生活随笔為你收集整理的“零代码”时代已来！程序员真的要去送外卖了？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SpringBoot 如何生成接口文档，
- 下一篇： 数据交换格式Json与XML