工具與資源中心
幫助開發者更加高效的工作，提供圍繞開發者全生命週期的工具與資源
developer.aliyun.com/tool?spm=a1z3...
什麼是低程式碼？
說起低程式碼（Low-Code）這個詞，是在 2014 年，Forrester Research 第一次正式使用低程式碼來描述這個市場。國內也就是近幾年開始流行的，以前我們這邊叫「視覺化搭建」，視覺化搭建講起來有個很大的缺點，就是很容易和資料視覺化傻傻分不清楚。我還記得， 18 年的時候，當時做一個分享，主題是 「泛視覺化搭建的解決方案」，我老闆的老闆說建議我把「泛視覺化」改為「低程式碼」，我當時回覆說不改，低程式碼聽著有點 low，「泛視覺化」高大上些。後來也不知道什麼時候開始習慣了一口一個低程式碼，而且衍生了 Node-Code/Pro-Code。現在回想起來，當時是自己 low。
看下業界領軍者對低程式碼的定義：
outsystems: 「低程式碼是一種軟體開發方法，可以更快地交付應用程式，並且只需很少的手工編碼。低程式碼平臺是一組工具，這些工具可以通過建模和圖形介面來視覺化應用程式開發。可以使開發人員可以跳過手工編碼，從而加快了將應用程式投入生產的過程。」
mendix: 「低程式碼開發是一種視覺化應用開發方法。通過低程式碼開發，不同經驗水平的開發人員能夠通過圖形使用者介面，使用拖放式元件和模型驅動邏輯來建立 Web 和移動應用。低程式碼開發平臺減輕了非技術開發人員的壓力，幫其免去了程式碼編寫工作，同時也為專業開發人員提供了支援，幫助他們提取應用開發過程中的繁瑣底層架構與基礎設施任務。業務和 IT 部門的開發人員可以在平臺中協同，建立、迭代和釋出應用，而所需時間只是傳統方法的一小部分。這種低程式碼應用開發方法可針對不同用例開發各種型別的應用，包括將原有應用升級為支援 IoT 的智慧應用。」
可以提煉出幾個詞：模型/建模、圖形介面、拖放元件、加快、減輕。
連起來就是：通過模型/建模、圖形介面拖放元件可以加快應用開發，減輕了非技術開發人員的壓力。
其實從前端的角度看，低程式碼的鼻祖應該是它：
從我目前階段的理解，低程式碼是這個：
當前市場分析
市場規模
根據 Forrester 的報告，2019 年該領域的規模估計為 38 億美元，預計在 2021 年這一賽道的市場規模將增長到 152 億美元，75％ 的應用程式將在低程式碼平臺中開發。到 2022 年該市場規模將達到 212 億美元。
根據 Gartner 預測，到 2021 年應用開發需求的市場增長，將至少超過企業IT交付能力的 5 倍。到2024 年全球約有 65％ 的應用程式都將涉及低程式碼開發。（Forrester 、Gartner 全球最具影響力的獨立研究諮詢公司）
1、領導者：行業領導者既要表現出超強的執行能力（好的產品與良好的銷售業績相匹配），又要表現出具有遠見（產品創新和相稱的營銷策略）的戰略計劃。LCAP 的領導者主要包括雲 SaaS 提供商（Microsoft、Salesforce、ServiceNow），專業的低程式碼提供商（Mendix、OutSystems）以及混合 RPA 和低程式碼應用程式供應商（Appian）。這些供應商具有強大產品能力、市場影響力以及使用者體驗。
2、挑戰者：在市場佔有率、產品能力方面與領導者的差距並不是很大，未來有能力成為該行業領導者。
3、特定領域者：成為利基市場參與者不僅可以提供低程式碼應用平臺技術，還混合了其他技術，例如，RPA、業務流程挖掘、BPM等技術。他們是 LCAP 行業的中流砥柱，擁有良好的發展空間。
4、遠見者：遠見者具有良好的合作生態以及市場發展策略，在產品創新方面也有很強的能力。但是在業務執行方面與領導者有著較大的差距。相信隨著時間的推移他們會更上一層樓。
市場分類
目前我看到的市場上主要有兩類：
一種是基於表單驅動，核心能力是表單、流程、報表，在一定的場景下，可以快速的做業務交付，上手成本也比較低。比如：宜搭、簡道雲、明道雲、氚雲等。
另一種是基於模型驅動，核心是領域模型、業務沉澱、完整性，有一定的技術壁壘，上手成本相對比較高。比如：Outsystems / Mendix / PowerApps / 奧哲雲樞 / 金蝶雲蒼穹等。
市場佈局
拿 PowerApps 來舉例，上面四個分別是 雲 + 端 + 協同 + 低程式碼。已經是很大、很先進的佈局了。從中我們能看到低程式碼平臺只是其中的一部分。獨木不成舟。獨木舟，雖然簡易也能用，但畢竟能力有限。
探索過程
用兩句話來概括下：1. 始於表單終於表單；2.從技術到產品。
從 2015 年開始我們一步一步探索，做了很多很多，無論是技術上還是產品上。比如模型驅動、小程式搭建等。這裡面的每一塊都可以單出拿出來講很久。這裡我舉幾個例子簡單描述下。
釘釘審批-表單
釘釘審批，這個搭建當時只有 8 個元件，功能也很簡單，和現在相比也更易用。畢竟簡單，這個僅僅是我們的開始，之後一發不可收拾。
中後臺頁面搭建
後來我們開始做中後臺頁面搭建，但在開始推廣時，卻受到了很大的阻力。
我們開始給前端用，技術同學是來寫程式碼的，就排斥這種高不成低不就的搭建平臺產品，而且功能又不全，被罵的很慘。
後來，我們給服務端開發用，當然服務端也是排斥的，不只排斥搭建，你說讓我一個寫 Java 的做前端的頁面我就是排斥。
但沒辦法，前端資源就是不足，再加上從上層開始推，那一年，效果突出，有些服務端的同學用的簡直飛起, 他們自己做頁面特別快，沒有聯調成本，介面都是自己定義的，想怎麼搞就這麼高，而且程式碼寫的很規整。
再後來，隨著我們的功能逐漸的完善，比如多分支、回滾等功能。前端也開始漸漸接受了，平臺側有很多頁面都是用平臺自己搭建的。
服務化
當時我們部門的業務，大部分中後臺系統服務端都能自交付。減少了很多前端投入。
我們自己用舒服了，那我們就開始想讓其他團隊也能使用。但每個業務場景都不一樣，預設的平臺無法滿足其他部門的訴求。所以我們開始做服務化。
服務化就是我可以讓其他團隊也快速擁有低程式碼搭建的能力，並且可以做定製，比如元件定製、設計器皮膚定製。這樣思路就開啟了，不僅能支援其他團隊的中後臺場景，凡是和搭建相關的場景，都可以做。
比如這裡例子，這個場景特別有趣，每次分享我會拿出來這張圖，絕對佈局的畫布，構建好後，服務端會自己做特殊解析，最終顯示在石墨屏上。類似這種例子有很多。包括後面要做的線上設計都是通過服務化來完成的。
程式碼互轉/WebIDE
隨著我們的使用者量越來越多，複雜功能的實現和後續的可維護性受到了很多的挑戰。
典型的例子是：開始我的需求比較簡單，用搭建快速完成了，但後面的需求評估下來，發現搭建滿足不了…然後我們開始做出碼，將搭建產物轉成程式碼，繼續開發。但是單純做出碼，沒什麼挑戰，我們也考慮了不同角色的開發。
當年的 WebIDE 也很火，預計我們通過 WebIDE 做了一套搭建和程式碼互轉的功能。我們創造了我們自己的 DSL，其實也參考了 salesforce，有了自己的語言，很多事情都好做了，也可控。小程式也是這樣的。
後面的路怎麼走？
靈魂三問：1. 如何能把價值再做大？2. 低程式碼 or 零程式碼？3. 使用者是誰？
再問：能否商業化呢？要不要商業化呢？如何商業化？
看競品分析。
Salesforce / Power Platform / 金蝶雲蒼穹，他們的 PaaS 都是有明確支撐的業務領域，CRM / ERP。PaaS 是基於自身的 SaaS 長出來的。我們要主打那塊業務？哪塊業務能找到市場？如果單純的做 PaaS，感覺最後做出的可能還是工具。工具類的競品，像 Outsystems/ Mendix，他們提供是軟體工具、方法和架構，可以快速建模、測試、部署、管理等，是一套完整應用開發的閉環（測試、部署、除錯、穩定性等）。
所以，單純做工具, 最後被收購？像 Mendix。支撐 SaaS 為目標？我們要打的 SaaS 行業？蛋糕還有嗎？要考慮多租、二開等，技術複雜度極高。
再看看國內，簡道雲，背後是帆軟-資料出身，氚雲-流程出身。兩個產品都偏零程式碼，產品體驗做的都很不錯。猜測應該都是先有獨立的能力，後發展後低程式碼平臺的。
結論呢？當然沒有。競品分析只能幫助我們多瞭解，具體的方向還需要自己去探索，去挖掘。
疫情帶來的變化
疫情讓我看到了：
- 疫情，業務變化之快。
- 企業創新，業務變化之快。
- 企業發展，核心是提效降本。
去年因為我留杭過年，所以參與到了疫情專案，用宜搭來做健康打卡，從大年三十一連續在家幹了兩週，7 * 24 小時待命。健康打卡應該大部人都用過吧，看著簡單，其實背後有很多複雜，有針對員工的，有針對 HR 的，還有針對海外的。需求變化之快，今天加個高風險城市、明天加個海外地區，又需要各種定製。
一個前端，全鏈路完成，快速試錯，快速上線。如果沒有宜搭，真搞不定。後面我也去其他類似的競品看過了我們這邊的定製場景還真都無法完成。這次專案讓我更深刻的認識了宜搭產品的價值。
總結
冰山理論。部分人認為的，包括 5 年前的我也是這樣認為的，拖拽設計器 == 低程式碼。
後面在深入做了兩年後，發現有 物料、多端、出碼、佈局、邏輯、國際化、監控、模板、協議、服務化、幫助體系 這麼多功能要做。
再往後做，要從 2B 的視角去看，就像之前微軟的那邊的區域性，雲、協同、端。
後面還有很多的未知等著我們…
再回到現實，總結五個點。
場景壁壘。我覺得我們需要尋找更多的「場景壁壘」，比如，疫情下，快速交付的場景，為什麼疫情下大家會選擇宜搭而不是選擇其他開發模式，因為快且場景不是特別複雜，快需要找需要快的場景，這種場景其他方式無法完成，這就是壁壘。
完整性。使用者需要在這個一個平臺上能把所有研發相關的事情全部做完。完整性也包括了可維護性。可控的開發質量、維護性和升級成本；二次需求開發。
生態。產品完整性有了後，就可以打造開發生態，通過更多的開發者生產更多的物料、服務。同時平臺可以連線更多的物料、服務。
連線。這裡的連線有兩層含義，一個是產品之前的連線，一個是資料的連線。產品的連線可以產生 1 + 1 > 2 的效果。目前的趨勢，在改變傳統的 ERP/CRM 大而複雜的軟體系統。越來越多小而靈活的應用產生，而且隨著企業的創新需求變化越來越快，系統越來越多，但不能做成煙囪，資料的連線尤其重要。
靈活性和易用性。靈活性和易用性的平衡如果做不好，那把平臺做屎也很容易。我看過一個競品，真的做到了程式碼完全互動化，0 程式碼，但稍微複雜點的應用那個邏輯流，就是前端的邏輯用互動編排的方式。那個複雜，根本沒法二次維護。
講了這麼多，並沒有確切的回答之前自己提的問題，因為沒有完全正確的答案，我們會繼續不斷的探索。我相信未來可期，低程式碼將成為B端服務領域的基礎設施，低程式碼必將顛覆傳統開發方式。
本作品採用《CC 協議》，轉載必須註明作者和本文連結