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