零程式碼時代即將到來？沒那麼簡單
大資料文摘出品
編譯：木槿、徐玲、楚陽、錢天培
“零程式碼”概念如今變得越來越流行。
“零程式碼”意味著，無需專業的軟體知識，你也能輕鬆規劃一個商業邏輯或者開發一個應用程式。
這當然是一個好的趨勢，而且，市場上已經出現了一些優秀的“零程式碼”工具。
所以，“零程式碼”時代真的要到來了嘛？沒那麼簡單！
為什麼要“零程式碼”？
“零程式碼”的優勢很明顯。培養一個軟體開發人員的成本很高，人才稀缺，而且一般的軟體開發人員資歷尚淺，再加上運維成本很高，軟體專案的開發也就困難重重。
一個“數字化企業”需要大量的軟體，而且絕大部分都是量身定製的，無法實現量產。於是，整個市場對軟體的需求量是十分大的。
如果有一種全新的方式可以取代開發大量軟體的過程而同樣實現產業數字化，何嘗不是一種重大的突破呢？然而，萬事開頭難。
將整個商業流程數字化有以下兩個明顯的好處：
整個專案的更新迭代將由軟體完成從而節省了人力成本。釋出一個新的軟體明顯比重新修改流程和培訓工人輕鬆得多。創新使企業在競爭同行中脫穎而出。當所有企業的想法都一致時，整個行業的服務會變得單一而平庸。這對一些企業來說不算什麼壞訊息，但消費者可不一定會喜歡。
然而，許多企業的數字化轉型都以失敗告終。因為要實現這一質的飛躍，一般企業先得轉型成為至少半個軟體開發公司，當然，大多數企業並不具備這樣的條件。只要擁有足夠的資源（時間，資金，人員），開發軟體並非一件難事，但人們大都善於表達各種奇思妙想而缺乏把這些想法落實到位的能力。
“零程式碼”解決了什麼問題？
編寫程式碼不僅是數字化轉型的關鍵也是其制約。因為程式碼通常不是那麼好些的，於是，簡化程式碼或者實現“零程式碼”的意義是巨大的。
簡言之，用規範的程式語言語法來編寫和實現商業邏輯是一件枯燥乏味的事情。就像會開車的人只需掌握簡單易操作的駕駛技巧而無需知道發動機如何工作一樣，程式碼界也需要這樣的運作模式以實現軟體開發的普適化。
不幸的是，這個問題已經被仔細研究過很長時間了，卻沒有被很好地解決。
抽象語言具體化
然而，程式碼的抽象性往往決定了它很難被簡化。程式設計師一般都力求程式碼具體化以保證其簡單易懂。
複雜程式碼簡單化
考慮到主要矛盾是編寫文字的複雜性，人們嘗試著開發了許多圖形化程式語言。例如Scratch（麻省理工學院的“終身幼兒園團隊”開發的圖形化程式設計工具，主要面對青少年），只需稍做改變就可以實現不同邏輯。
然而，魚與熊掌不可兼得。簡單易操作的語法架構通常難以實現複雜場景的邏輯，反之亦然，一些領域特定語言（DSLs）又因其強針對性而難以推廣到其他領域。
用配置取代程式碼
許多“零程式碼”擁護者透過使用Zapier這樣的工具將不同的應用程式整合整合在一起來使事情變得簡單。
然而，這麼做會有兩個缺陷：
第一，邏輯被分散到不同的應用程式中從而使反向推理變得困難。
第二，也是更重要的一點，邏輯由不同應用程式的配置而非編寫某種具體程式碼實現會使得其效能表現受制於這些應用程式的水平。於是，程式設計師經常面臨這樣的困境：我們是信任外部系統並在其中投入大量的配置工作，還是嘗試自己處理更多的程式碼邏輯？
邏輯不會消失。因此將其嵌入到Zapier規則的佈線中並不能減輕任何維護和測試的負擔。
程式碼的等價性
軟體開發人員仍然使用純文字的程式語言是有原因的，主要是為了提高工作效率和流程的簡潔性。毫無疑問，如果有很多更好的工具出現，軟體開發人員會像扔燙手的山芋一樣放棄文字。
然而，不同的邏輯表示方式並不意味者邏輯本身的簡化，就像“2”和“two”來表達“兩個”的性質一樣。當然，實現商業邏輯的方式還有很多種。
也就是說，在視覺化開發環境中的這個過程：
可以完全等同於：
def process_email（self， address）： if not self。validate_email（address）： raise InvalidDataException（_（“Address is not valid”）） self。store（address）第一種方法要求開發人員熟悉圖形化的工作介面，第二種方法要求熟悉文字形式的程式語言，兩種方法都需要開發人員理解邏輯的內在關聯，而且都簡單易學。
為了更好地理解軟體，開發人員通常需要在腦海裡建模模擬，預測其在不同工作環境下的反應。
這和許多人在使用現代數字化裝置時遇到麻煩的原因完全一樣，所謂“VCR”問題就是指因為硬體的輸入按鈕很少，但內部工作非常複雜，因此使用者需要在腦海中保留裝置內部狀態的高階模型。
這聽起來有點不大現實，因為照“心智理論”來說，貌似只有懂技術或者擅長程式設計的人才會買數字化裝置，而一般人想要用這些裝置要先經過專業的訓練。從這個層面上來講，程式語言是文字或是圖形化的都無所謂。
“零程式碼”不是一個好的趨勢嗎？
毫無疑問，“零程式碼”是一個好的趨勢。
縱觀歷史，我們發現，計算機程式語言的發展仍道阻且長。
因此，我們仍然應該嘗試改善我們的語言和環境。考慮以下兩段程式碼
#include
和這個：
function add_domain_name（username： string）： string {return username + “@example。com”；}第一個是段C語言程式碼，第二個是TypeScript程式碼。事實上，這兩種語言的語法大致都相同，但是TypeScript比C更好用，因為開發人員無需擔心記憶體分配或者字串的編碼特性之類的事情。
事實上，對於一個足夠完備的應用程式，其商業邏輯是十分強大的，以至於實現其的不同程式語言之間的差異可以忽略不計。顯然，程式語言的發展並沒有取得很大的進步。
“零程式碼”面臨的困難
眼下，已經有一些很優秀的”零程式碼”平臺出現，例如被譽為“軟體終結者”的Salesforce Cloud，它可以實現程式設計、基礎規則設定和配置的視覺化。
專案通常以“原型”開始，以表明平臺可以做到這一點。這些內容彙總起來很快，大致可以完成專案的80％。遺憾的是，成功並不能一蹴而就正如程式設計師所知：細節決定成敗。
當平臺無法實現一些功能時，開發人員通常需要自己構建詳盡的解決辦法，有時候也許根本無法解決。比如，我曾經使用平臺搭建過一個自動響應電子郵件的程式，但是這個程式無法配置在檢測垃圾郵件的程式後面，也無法檢測到SMTP郵件，因此，它是不能用的。
即使平臺可以自動修復Bug並順利的實現邏輯，你仍然會遇到困難。例如，改善邏輯。
通常的程式碼程式需要改進時，開發人員會編寫一段程式碼，然後把它部署到一個獨立的環境中進行測試，測試成功之後在將其部署到整個商業邏輯的程式碼中，或者，直接把它部署到整體程式碼中然後在一步步除錯，由此提高了應用程式的容錯性並把對使用者的影響降到最小。
而“零程式碼”增強了程式的專有性，因為，你幾乎不能把同一個更改從一個專案準確的複製貼上到另一個專案。即使Salesfoce提供了相關功能，“零程式碼”的這種缺點依然很明顯。
“零程式碼”的優勢
弄清楚軟體需求是件很重要的事。而“零程式碼”平臺善於融合不同的軟體，這些軟體的價值會隨著融合而不斷彰顯。
“零程式碼”平臺作為非IT系統，不僅能讓終端使用者親身參與到軟體設計的過程中還可以及時收集到使用者反饋。即使所謂靈活的傳統開發團隊，也很少能做到讓終端使用者參與其中。於是“零程式碼”平臺的這一優勢不言而喻。
還有很多本質上非“零程式碼”系統的平臺，但是使用者也能在其中發揮其主觀能動性。例如我的最愛Looker（商業智慧軟體和大資料分析平），和一些類似的平臺。有趣的是，在這些平臺中開發的模型大都是利用普通的軟體開發工具以純文字的形式出現的，這或許就是它們成功的秘訣。
結論
用“零程式碼”平臺代替主流的軟體開發工具迄今仍然是夢想。縱觀過去70年的發展，沒有任何跡象表明這一夢想會很快被實現。
當然，各種“零程式碼”平臺的出現並非沒有價值，但必須謹慎對待。它並非是軟體開發的靈丹妙藥，而且有可能使事情變得更糟。
相關報道：
https：//www。alexhudson。com/2020/01/13/the-no-code-delusion/
