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