大數據文摘
大數據文摘出品
來源：alexhudson
編譯：木槿、徐玲、楚陽、錢天培
「零代碼」概念如今變得越來越流行。
「零代碼」意味著，無需專業的軟體知識，你也能輕鬆規劃一個商業邏輯或者開發一個應用程式。
這當然是一個好的趨勢，而且，市場上已經出現了一些優秀的「零代碼」工具。
所以，「零代碼」時代真的要到來了嘛？沒那麼簡單！
為什麼要「零代碼」？
「零代碼」的優勢很明顯。培養一個軟體開發人員的成本很高，人才稀缺，而且一般的軟體開發人員資歷尚淺，再加上運維成本很高，軟體項目的開發也就困難重重。
一個「數位化企業」需要大量的軟體，而且絕大部分都是量身定製的，無法實現量產。於是，整個市場對軟體的需求量是十分大的。
如果有一種全新的方式可以取代開發大量軟體的過程而同樣實現產業數位化，何嘗不是一種重大的突破呢？然而，萬事開頭難。
將整個商業流程數位化有以下兩個明顯的好處：
整個項目的更新迭代將由軟體完成從而節省了人力成本。發布一個新的軟體明顯比重新修改流程和培訓工人輕鬆得多。
創新使企業在競爭同行中脫穎而出。當所有企業的想法都一致時，整個行業的服務會變得單一而平庸。這對一些企業來說不算什麼壞消息，但消費者可不一定會喜歡。
然而，許多企業的數位化轉型都以失敗告終。因為要實現這一質的飛躍，一般企業先得轉型成為至少半個軟體開發公司，當然，大多數企業並不具備這樣的條件。只要擁有足夠的資源（時間，資金，人員），開發軟體並非一件難事，但人們大都善於表達各種奇思妙想而缺乏把這些想法落實到位的能力。
「零代碼」解決了什麼問題？
編寫代碼不僅是數位化轉型的關鍵也是其制約。因為代碼通常不是那麼好些的，於是，簡化代碼或者實現「零代碼」的意義是巨大的。
簡言之，用規範的程序語言語法來編寫和實現商業邏輯是一件枯燥乏味的事情。就像會開車的人只需掌握簡單易操作的駕駛技巧而無需知道發動機如何工作一樣，代碼界也需要這樣的運作模式以實現軟體開發的普適化。
不幸的是，這個問題已經被仔細研究過很長時間了，卻沒有被很好地解決。
抽象語言具體化
然而，代碼的抽象性往往決定了它很難被簡化。程式設計師一般都力求代碼具體化以保證其簡單易懂。
複雜代碼簡單化
考慮到主要矛盾是編寫文本的複雜性，人們嘗試著開發了許多圖形化程式語言。例如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 #include char *add_domain_name(char *source) {const size_t size = 1024;char *dest = malloc(size+1);strncpy(dest, source, size);strncat(dest, "@example.com", size);return dest;}
和這個：
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/
實習/全職編輯記者招聘ing
加入我們，親身體驗一家專業科技媒體採寫的每個細節，在最有前景的行業，和一群遍布全球最優秀的人一起成長。坐標北京·清華東門，在大數據文摘主頁對話頁回復「招聘」了解詳情。簡歷請直接發送至zz@bigdatadigest.cn
志願者介紹
後臺回復「志願者」加入我們
點「在看」的人都變好看了哦！
原標題：《零代碼時代即將到來？沒那麼簡單！》
閱讀原文