作者 | Alex Hudson
譯者 | 風車雲馬，責編 | 唐小引
封圖 | 付費自東方 IC
最近幾年裡越來越流行一句話，「2020 年將是無代碼的一年」。這意味著你即使不是軟體開發人員，也可以編寫業務邏輯甚至整個應用程式。這樣做固然有一定的好處，有些「無代碼」工具確實很強大，但我也認為這是不大可能的。
為什麼會有「No Code」？
從表面上看，「不用代碼」的原因是顯而易見的：軟體開發人員成本昂貴，供不應求，而且軟體本身的開發也是需要周期的，後期還要根據需求變化進行調整，並且運行和維護的成本都很高。
然而對軟體的需求是與日俱增的。現代數字化企業需要大量的軟體，大部分都是高度定製的。
如果我們可以創建數字業務，甚至數字產品，那不是更好嗎? 或許一開始新技術很難使用，但隨著時間的推移會變得更容易獲得。
將業務流程轉換到軟體領域主要有兩個明顯的好處：
-
「變更控制」成為一個軟體問題，而不是人員問題。您僅僅做一個軟體發布，而不需要通過大量的人員再培訓，就可以改變現有的流程或引入新的流程。從而實現更快地回滾或疊代。
-
創新使企業與眾不同，尤其是企業的競爭對手也在做同樣的產品，將業務流程轉換到軟體領域，這對一些企業來說是好事，但大多數企業不想從事軟體產品服務。
許多企業試圖通過數字化轉型來獲得這些好處，但都失敗了。你會突然發現公司會變成（至少在某種程度上）一個軟體開發公司，而大多數公司都不擅長這個! 雖然軟體環境具有無限的可能性，但要有足夠的資源（時間、金錢、人員），大多數人都會夢想各種可能性，但在實踐過程中受到很多限制。
「無代碼」是什麼？
「無代碼」意味著軟體開發不需要編寫代碼。人們可以在某個「更高的層次」上進行操作，在這個層次上，開發要簡單得多，但最終的結果是相同的。
具體來說，按照計算機程式語言的語法形式編寫業務邏輯是令人討厭的。打個比方：軟體開發人員就像汽車修理工一樣，了解引擎的內部。但大多數人只需要能夠駕駛汽車，會使用方向盤和一些踏板就行。隨著時間的推移，我們不斷提高了機械化程度。有人可能會喜歡手動擋，但大多數人更喜歡自動變速箱，這樣駕駛我們就讓它簡化了！
簡單的抽象
在這個行業的早期試圖簡化編程就已經開始了：BASIC 是一種嘗試，它允許人們用看起來像英語的語言來編寫軟體，這也是非常成功的。
然而，抽象作為編碼系統的一個關鍵概念，它往往不會過於簡化：實際上，許多開發人員都在積極地嘗試確保代碼足夠具體，使其易於理解。
簡單的語法
主要的問題是編寫文本，已經有人嘗試簡化語法甚至完全去掉——有許多圖形開發系統。
這些語法的簡化也會帶來表達的問題。一旦它們足夠簡單，可以快速掌握，它們就不再具有足夠的表達能力，無法在許多場景中使用。還有些計算機語言專注於某個應用程式領域，稱為領域特定語言(dsl)。但這些語言很少有真正在開發中獲得成功的，主要是因為它們再次使事情變得極其複雜。
配置代碼
許多不會寫代碼的人正在通過整合現成的應用程式來構建重要的系統。使用像 Zapier 這樣的工具可以更直接地做到這一點，這些工具可以廣泛地集成到不同的系統中。
這種情況有兩方面的原因。首先，您已經將邏輯擴展到各種不同的系統中，因此很難再對整個應用程式進行梳理。
其次，邏輯是通過配置來實現，而不是代碼。程式設計師經常面臨這樣的兩難境地：我們是信任外部系統並投入大量的配置工作，還是嘗試自己處理更多的邏輯？
無論應用程式如何擴展，邏輯不會消失。即使使用 Zapier 規則進行連接，也不會消除任何維護的成本或負擔。
代碼的等價性
開發人員仍然使用純文本是有原因的——主要是為了提高效率和清晰的表達。當然，如果出現了更簡潔的工具，許多（不是所有！）開發人員會像扔熱石頭一樣丟掉文本。
但是無論以什麼方式的邏輯表達，都不會減少所描述事物本身的複雜性。就比如編寫「two」和「2」，表示相同的東西。
假想視覺開發環境中的過程是這樣的：
完全等價於：
def process_email(self, address):
if not self.validate_email(address):
raise InvalidDataException(_("Address is not valid"))
self.store(address)
在第一個例子中，我需要知道該視覺環境系統是如何工作的。在第二個例子中，我需要了解一種語言和開發環境。但這兩種技能都是很容易獲得的。它們之間的共同點是，我要理解邏輯是什麼，以及它將如何工作。
要理解軟體——任何類型的軟體——你需要能夠在頭腦中對所表示的系統建模，並基於此對它在不同場景下的工作方式進行預測。
這正是許多人在現代數字設備上遇到麻煩的原因。問題是由於硬體的輸入按鈕很少，但內部工作非常複雜:所以用戶需要在他們的頭腦中保留設備內部狀態的高級模型。
有些人認為這是一種不可習得的技能。如果你不能推斷出某物的內部狀態，那麼很可能將無法編程。我敢說沒有大量的實踐，你肯定做不好。坦率地說，邏輯是文本的還是可視化的並不重要。
「無代碼」就不好嗎？
絕對不是。
在 70 多年的可編程計算機的發展歷史中，我們仍然在使用 20 年前的開發工具，這才是最大的不幸。
當然，我們仍然應該努力改善我們的語言和環境。看以下兩段代碼：
#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;
}
以及這個：
function add_domain_name(username: string): string {
return username + "@example.com";
}
第一個例子是 C（發明於 1972 年左右），第二個例子是 40 年後的 TypeScript（發布於 2012 年）。它們在很多地方有大致相同的語法，但是 TypeScript 比 C 高級得多。特別是，開發人員不需要擔心內存分配、字符串的編碼或其他事情。
實際上，對於足夠大的應用程式，大部分業務邏輯將在相當高的級別上實現，而且語言之間的差異將更加不明顯。
在實踐中，「無代碼」的不足之處？
目前有一些非常高級的系統，例如，您可以在 Salesforce Cloud 中定義非常複雜的軟體，而不需要編寫任何代碼。它包含了可視化編程、規則設置和配置。
對於其他人的平台，實際上根本無法實現所需的功能。您常常需要構建複雜的解決方案來彌補功能缺失。舉個例子，我曾經使用過一個平台，它有一個電子郵件自動回復器，但是不能放在垃圾郵件檢查器中。使用它意味著產生垃圾郵件反向散射，這是許多電子郵件系統迅速禁止的接收方式。
假設它能根據您的需求完全實現特性，那麼隨著項目的進展，在產品化方面就會遇到麻煩。變更控制就是一個明顯的例子。
我們習慣於使用代碼創建更改，然後將其部署到單獨的測試環境中，最後部署到生產環境中（要逐步地啟用該特性）。如果出現錯誤，我們可以快速地處理它們並解決問題，而不會影響到所有用戶。
由於系統「無代碼」，非生產環境中的測試往往很難或不可能實現。Salesforce 有一些優秀的工具可用來完成這項工作，即使在那樣的環境中，這也是非常困難的。
「無代碼」的成功之處？
質疑對軟體的需求也無非好壞，「無代碼」系統對於概念驗證階段有很好的指導作用。
作為非 IT 系統，它們在獲取實際業務設計輸入和反饋方面也非常有用。雖然我們談論了很多關於敏捷開發的內容，但是我很少看到開發團隊中的最終用戶。
有許多工具，雖然本身不是「沒有代碼」，但也允許用戶生成更多的技術輸出。我最喜歡的例子是商業智能工具 Looker，在不同的細分市場中還有許多類似的工具。我發現它們的模型開發都是純文本的，都使用常規的軟體開發工具，這非常有趣。
總結
我認為「無代碼」作為大多數主流開發的替代方案是一個白日夢。在過去的 70 年裡，還沒有出現任何先進的技術讓我們敢於取代基於文本的開發。
作為一名軟體開發 CTO，雖然我認為各種「無代碼」工具非常有價值，但必須謹慎部署。它們不是軟體開發的萬能包，很可能使情況變得更糟而不是更好。
對我來說，最理想的用戶是「超級用戶」：那些已經非常熟練的 IT 用戶，他們可能會設計出更好的工具，給他們一個交付的環境是極其重要的，但這應該是我們技術人員的共同努力——「有/無代碼」雙方不應該對立。
原文：The 'No Code' Delusion
連結：https://www.alexhudson.com/2020/01/13/the-no-code-delusion/
作者：Alex Hudson，Fractional CIO/CTO at Freeman Clarke
譯者：風車雲馬
你覺得無代碼開發靠譜麼？