為什麼低代碼最近今年又火了起來？
網上一直有意無意掀起程序員和低代碼的對立，真的降智，找了個問題展開細說了一下：
現有很多低代碼開發平台，有給不懂編程的人用的嗎？?www.zhihu.com
----下面是本回答-----
不了解的人大概不知道：2012年，Gartner就提出了「Citizen Developer」的概念：
即公民開發者/全民開發。
這個詞大意是：藉助於一些組件化、可視化平台，一些不具備編程技能、不懂代碼和開發的「小白」，也能自主組織或參與開發，從而把代碼開發由一項程序員專屬技能擴展到更廣泛的人群，甚至是全人類。
當會計、銷售、運營等業務崗需要特定的系統時，自己動手就能編寫，而無需求助IT部門的任何人……這意味著困擾大家最多的：業務需求和開發技能之間的壁壘，被打破了。
不難理解為什麼這種概念會吸引公司。
市場發展
雖然是新興概念，但並非空穴來風，從低代碼到無代碼由來已久，如果你仔細追溯，甚至可以發現在1980s，就有美國公司和實驗室開始研究程序可視化編程這個領域——從4GL（第四代編程語言）到VPL（可視化編程語言）。
自2000年以來，這塊市場就充斥著大大小小的玩家40+以上，比如國外的Appian、Salesforce、K2和Ultimus。2015年以後，迅速升溫，Microsoft、Oracle和Google紛紛下場，推出PowerApps、App Maker等，觀國內，除簡道雲之外，搭搭雲、氚雲、iVX、明道雲、APICloud等推出，低代碼/零代碼領域開始興起。
在2017的魔力象限報告中，Gartner創建了新門類——hpaPaaS（簡稱aPaas，企業高生產率應用程序平台即服務），並預測「到2020年，超過50%的企業應用將通過hpaPaaS平台搭建」：
也基本是從2018年開始，海外市場在低代碼賽道的投融資活躍起來：
OutSystems獲KKR和高盛3.6億美金融資，成為該領域的獨角獸；
幾乎同時，荷蘭公司Mendix以7億美元被西門子收購。
資本跟著機會走，市場跟著資本走。這樣的大手筆、大變局迅速引起了全球市場的關注。
2019年，Gartner重新界定並看好新概念「LCAP」（低代碼/無代碼開發平台）。著名研究機構Forrester Research也表示看好：
「企業開發團隊正在採用低代碼/零代碼開發平台，市場的增長前景似乎一片樂觀。2020年低代碼市場規模或將達到155億美元，超過75％的應用程序將在低代碼/零代碼平台中開發。公民開發者的比例將從2017年的40%提升到2020年的70%。」
——Forrester Research
到2024年，四分之三的大型企業將至少使用四個低代碼開發工具進行IT應用程序開發和公民開發計劃。到2024年，低代碼應用程序開發將佔應用程序開發活動的65％以上。
——Gartner
資本的不斷洗牌+正向的前瞻預測，推動了低代碼/零代碼的研發公司與日俱增，也帶來越來越多的企業開始嘗試以低代碼/零代碼技術重構數字化業務。
供需矛盾
Gartner曾預言，到了2021年，市場對於應用開發的需求將五倍於IT公司的產能。但研究表明，專業的IT人員只能夠滿足企業6%的IT需求。
所以明眼人都能看出來即將加劇的供需矛盾：企業的IT需求成倍增加 VS 開發新的程序需要複雜的技術、高昂的成本。
因此在過去，信息化是大型企業才會考慮的事情，因為軟體的採購周期很長，通常整個公司集中採購和部署，成本居高不下。但傳統的ERP、CRM覆蓋面非常有限，大部分大公司的部門級應用都是無法被滿足的。
中小型企業轉型面臨的陣痛就不斷暴露出來了：
1、市場環境在高速變化發展，內部系統也需要快速迭代響應，但傳統開發效率哪裡滿足得了？
2、日益上漲的人力成本和時間成本，一般企業根本負擔不起。
3、購買成型的軟體，使用後水土不服，壓根創造不出價值。
大型企業也很少能碰上省油的燈：
因為對他們來說，在軟體開發與實施過程中的第一痛點不是貴，而是需求溝通不到位。無論是交由自己的IT人員或是外包ISV來定製開發，對業務痛點都沒有切身的體會和經驗，再加上很多時候需求在實施之前都無法100%確定，最後軟體做成四不像，用著難受的比比皆是。（而且要命的是，沒付錢的時候提需求什麼都能滿足，付完錢再提需求，外包開發啥也不認。）
再者，大企業由於內部系統多，開發系統還需要不斷考量內部間系統的關聯、兼容以及系統數據切換效率等問題。
牽一髮動全身，並沒有那麼容易。
但是零代碼開發平台不一樣：
企業可以通過零代碼平台漸進地開始實施。如果整個系統過於複雜，可以先從一個具體的環節開始，局部數字化（比如先把訂單管起來）。
零代碼工具可以讓開發者和使用者之間的距離充分縮短。在極端情況下，使用者甚至可以自己就是搭建開發者自己。他們可能在一兩個小時的搭建後就能夠確認這個方案是不是能夠有效地解決問題。
這也就是為什麼代碼或低代碼開發平台在企業間逐步盛行了起來。
技術發展
在這一塊，CSDN上有篇文章分析的很好：
總結一下：
1、移動互聯網和雲計算的發展。移動辦公可以實現了，加上雲的成本比本地部署低太多了。
2、信息化和數字化的普及。落後就要挨打，越來越多企業尋求信息化，也嘗到了信息化的甜頭。
3、對在線辦公的認可度和靈活性變高。的確是SaaS開了個好頭，教育了市場，企業漸漸適應了在線辦公，同時也產生了更複雜更多的需求。
可以說就是這三點，推動了零代碼開發平台的興起。
為啥今年又火
我第一次知道低代碼這個概念從36氪發布的文章（低代碼：下一次IT技術革命？），但因為國內還處於新興，一度存疑。後來真正被吸引到的，是看到了這句話：
如果用 aPaaS 平台直接管理業務數據對象，這個數據整合工作都可以免除。用戶可以直接在各個職能相關的數據對象中建立關聯，建立匯總查詢，批量抽取數據到BI平台，建立不同數據之間的自動化。
這話的意思，用圖畫出來就是：
也就是說，零代碼開發平台搭配BI，如果運用得當，可以實現數據中台：
不知道你們能不能get到，反正當時老闆沒get到……
但一場疫情，天涯相隔，讓老闆直接付費。
時勢造英雄，沒錯的。
---更新---
原文貼的低代碼工具為簡道雲，疫情辦公系統為模板改造，直接進它們的模板中心自取即可：簡道雲
參考資料：
https://blog.csdn.net/weixin_44454062/article/details/86596733?utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~all~first_rank_v2~rank_v25-1-86596733.nonecase
https://solutionsreview.com/cloud-platforms/a-look-at-gartners-2017-magic-quadrant-for-enterprise-high-productivity-application-paas/
https://www.gartner.com/doc/reprints?id=1-1FKNU1TKct=190711st=sb
https://www.jianshu.com/p/023cafaf85c1
https://baijiahao.baidu.com/s?id=1671191132057682292wfr=spiderfor=pc
http://www.cniteyes.com/archives/36557
https://m.pedaily.cn/news/447000
https://baijiahao.baidu.com/s?id=1645974919222478094wfr=spiderfor=pc
https://www.infoq.cn/article/u01Zu6ywe9xON648fq9G?utm_source=related_read
因為需求！
隨著社會不斷的在進步，系統也在升級。
雖然難忘的2020年已經成為過去，但回顧一下，我們不難發現，因為疫情原因很多公司都採取了線上辦公的模式，這讓低代碼開發平台在2020年又火了起來。那麼，低代碼為什麼能火？
下面4個內容給到大家！
- 低代碼開發平台為什麼能火？
- 低代碼開發平台主要功能有哪些？
- 為什麼要選擇低代碼開發平台？
- 低代碼開發平台怎麼收費？
一、低代碼開發平台為什麼能火？
1、眾多巨頭公司投身於低代碼領域，如阿里、騰訊等國內巨頭公司。典型的「明星效應」帶火了國內低代碼市場。
2、移動互聯網和雲計算的發展。移動辦公可以實現了，加上雲成本比本地部署低太多了。
3、信息化和數字化的普及。落後就要挨打，越來越多企業尋求信息化，也嘗到了信息化的甜頭。
4、低代碼開發平台作為一款「開箱即用」的數據可視化工具，它能讓可視化效果更震撼，眾多SaaS 版本操作更便捷。只需通過簡單的「拖拉拽」即可完成企業系統搭建，支持雲環境下數據可視化應用的快速製作。
6、對於非技術人員來說，低代碼開發平台是一款絕佳的實用工具，無需懂代碼就可以根據自己的需求構建應用。
7、對於技術人員來講，低代碼開發平台可以用作為開發工具，它能幫助IT團隊培訓、技術部署的降低初始成本，還可以簡化開發過程、縮短開發周期、提高開發效率、節省開發成本。
8、低代碼高效的協作能力，能更加迅速的幫助企業領導者做出決策。
9、低代碼構建的應用系統具有高度靈活性，對於企業來說性價比更高。
10、一站式解決方案，多個系統在一個平台上。打破傳統應用程序，讓企業系統更加的現代化。
二、低代碼開發平台主要功能有哪些？
1、可視化構築業務對象數據表，並支持建立關聯，甚至需要支持跨應用的數據表關聯。
2、為不同的數據場景配置不同類型的視圖，能夠定義數據行和列的過濾，能夠設置列表、看板、日曆等不同界面形式。
3、能夠定義不同用戶角色，並賦予角色不同的數據訪問和改寫許可權。許可權定義越精細越好。
4、能夠建立針對數據的匯總表和統計圖表。
5、能夠建立自定義的輸入表單，分發給不同角色使用。
6、能夠建立自定義的報表，用於輸出各類形式表格，內部有幾十套圖形報表，涵蓋了所需各類行業各類服務，支持套打功能。
7、能夠管理企業用戶、部門、組織結構，並將其用於應用邏輯關係，比如應用的分發，角色的賦予和工作流中的流向信息。
8、能夠可視化配置工作流，支持特定條件下的數據新增、改寫、刪除等操作，並能夠融入數據填寫，審批等人工流程節點。工作流的運行能夠監控和保存日誌。
9、面向企業的門戶網站和內部系統界面，數據看板等特性，實現個性化使用。
三、為什麼要選擇低代碼開發平台？
1、低代碼開發平台
織信根據低代碼開發平台的模式，改變原始繁瑣的開發模式，大幅度縮短迭代周期、降低開發成本，無需大量的專業團隊就可短時間掌握產品使用。低代碼開發是近幾年異軍突起的開發模式，具有極強的開發效率和擴展性，廣受開發人員的好評。
2、PC端、APP同步開發
織信低代碼開發框架平台可以輕鬆搭建出IOS和Android系統的移動端應用，實現PC端、移動端一站聚合、多端接入，可以快速獲取各類數據同步。
3、小程序無縫對接
當前最熱門的小程序是必不可少的，織信實現與微信小程序、支付寶小程序、釘釘小程序、頭條小程序、百度小程序、QQ小程序一鍵直達，並致力於專業設計流程,全行業開發方案，實現互通互聯高效協作辦公。
4、靈活介面萬物互聯
很多企業在使用管理軟體的時候會很煩惱各個系統之間數據不共通，如信息孤島之類的問題，而織信打通各類企業系統數據、實現手機+PC聯手管控辦公，高適配開發平台 、強大介面引擎實現萬物互聯。
5、跨平台引擎平台
織信是集成了引擎平台、輕量化集成應用，更適應科技的發展需求，平台受眾更加廣泛、對開發人員的要求也低了不少。
6、滿足企業，隨需而變
低代碼開發平台的標誌性開發模式就是拖拉拽可視化配置開發，企業可根據不同的業務場景自由配置，個性化開發等。織信更簡化了開發模式，選擇資料庫、關聯資料庫、配置表單、填寫表單信息、然後生成代碼，這裡就不得不提一下織信的代碼生成器，正因為有它表單才能開發的如此迅速。
四、低代碼開發平台怎麼收費？
目前，大多數的低代碼開發平台都是基於SaaS。這意味著企業要支付訂閱費用。價格一般是從每月幾百到上千的費用。這取決於用戶數量，應用程序數量和我們使用的功能。當然還有一些低代碼平台支持私有化部署，買斷價格一般是幾萬到幾十萬不等。
一個低代碼開發平台解決企業多款應用系統的需求。這也是低代碼開發平台為什麼性價比會如此之高的緣故。
合理並且有效地運用低代碼開發平台，不僅可以讓我們工作高效地運行，還能最大程度保證團隊目標的達成。我推薦使用織信INFORMAT，它內置了100+的應用模板，覆蓋OA、ERP、CRM、績效、人事、企業服務、個人及組織等多個應用場景。點擊一鍵安裝，即可免費試用。現在註冊可享受終身免費使用權益。同時還能體驗在線搭建功能，是幫助企業開啟數字化轉型的重要引擎。
俗話說：「冰凍三尺非一日之寒」，低代碼並非突然就火了，而是時代發展的必然趨勢。
首先我們來了解一下什麼是低代碼
「低代碼」按字面意思可以通俗理解為「比正常應用開發要少寫代碼」，讓低代碼開發成功實現的工具就是低代碼開發平台，它具有簡單邏輯和拖放功能的可視化界面。通過低代碼開發平台無論你是否懂開發技術都能使用簡單的「拖、拉、拽」來創建應用，搭建屬於自己的系統。
目前國內市場已經湧現許多做低代碼開發平台的企業，比如：百數就是一款好用的低代碼開發平台。
百數低代碼開發平台的功能
- 表單體系：主要用於數據錄入、數據收集等數據處理等場景。
- 報表體系：主要是運用不同類型的表格、圖表來對錶單數據進行匯總、展示，便於對信息的直觀了解。
- 流程表單：主要是通過系統的推送快速完成企業內部的流程審批，便於優化工作流程。
- 數據視圖：主要用於複雜數據統計/多表關聯/分組匯總/分組過濾，製作複雜數據報表，還可以用來被數據聯動調用數據。
- 功能擴展：可以通過Python與lua腳本語言以及功能模塊對系統根據自己的需求進行無限擴展。
百數低代碼開發平台的優勢
1、拖拉拽設計，降低了開發者門檻
百數低代碼開發平台採用的是可視化模塊設計，在平台上任何一個用戶只需輕輕的拖拉拽控制項就能搭建成一個應用，降低了開發者門檻。
百數表單系統
百數的視頻 · 7 播放2、開發速度快，縮短了開發周期
傳統模式開發一個系統至少得需要專業團隊花費三個月時間甚至更長時間才能開發完成，開發效率更不用多說了，就是一個字慢。
用百數低代碼開發平台則只需一個人最多一個月就能完成系統的開發，有些簡單的管理系統也許幾分鐘就能完成搭建，因此這開發周期就比傳統的模式縮短了三分之二，提高了工作效率。
3、個性化擴展強，靈活自由
傳統開發模式想要在系統原有基礎上擴展新功能至少需要1個月，並且擴展的過程非常困難，不藉助專業開發人員的幫忙根本不可能搞的定。
用百數低代碼開發平台就不存在這樣的困擾了，一方面百數支持後端低代碼Python編寫開發，另一方面是支持用現成的功能模塊搭建來進行開發，兩種方式都支持隨時對系統進行修改或者擴展且都不需要依賴專業開發人員就能操作。
因此低代碼開發平台可以隨時根據企業需求隨時開發，保持應用更新，適應新的環境。
4、降低開發成本，提高效益
低代碼開發平台是通過可視化、模塊化、拖拽式來代替傳統開發方式的寫大量代碼來進行開發，減少了傳統模式中開發中需要付出的冗雜的、重複性的編碼工作，從而達到有效的降低人工成本，提高企業效益的目的。
除此之外，沒有技術背景的人也能通過簡單學習使用低代碼平台，製作一個簡單的demo共享給IT人員參考，也能大大降低企業內的溝通成本。
5、支持私有化部署，安全穩定
百數支持企業進行私有化部署，其私有化部署擁有獨立的伺服器，獨立的IP，免受公有雲Saas平台的所有不穩定因素的影響，阿里雲提供的伺服器技術。並且還可以自定義企業的網站域名、企業的Log，輕鬆打造一個屬於自己品牌的辦公平台。
百數低代碼快速開發平台隨著信息化的發展，應用程序的需求肯定是在不斷增大的。如果一味地依賴專業開發人員來量身定製進行開發的話，必定會發生「供不應求」的狀況。而低代碼開發平台卻可以在很大程度上緩解了企業的應用程序需求壓力，很早就被行業內被認證為是一個良方。
發佈於 04-13繼續瀏覽內容
知乎發現更大的世界打開
Chrome繼續
Joseph Yan輕流 CPO ｜首席產品官｜聯合創始人｜30U30｜招PM「無代碼運動」是幾千年以來驅動技術創新的核心原則的演變：
不斷對以前僅一小部分人可用的過程工具或介質進行公民化拓展並通過此倍增人類創造的潛力。
各個領域的公民化運動
在印刷機問世之前，批量生產書籍的唯一方法是手工製作，這使得傳播信息和知識不僅很慢而且昂貴。一本羊皮紙的《聖經》在中世紀可是土豪才能擁有的資產，相當於一座葡萄園的價格。
書籍如此昂貴，你還會為中世紀大部分人是文盲而感到驚奇嗎？
然而1440年印刷機的發明以嶄新的方式大規模生產和發行新文本成為可能。現如今，如果你想讓文字發布到世界各地，只需要敲擊幾下鍵盤即可。
隨著這些基礎技術的公民化普及，世界範圍內的出版數量與日俱增（配圖為200年中每100萬人中新書的出版數量增長）
同樣的事情也發生在音樂和電影領域，技術及其使用方式對人的創作產生了巨大影響。過去我們需要專業的錄音棚以及價格昂貴的錄製設備才能進行相關創作。
如今更多的數字化分發渠道、線上流量的劇增、自媒體平台的興起（BiliBili、抖音、youtube等）以及公民化設備的技術躍遷（移動手機的攝像頭質量在過去幾年有了大幅度提升）讓人們可以在沒有太多前期資源的情況下依然分享自己的創意和想法。
在B站，每天有10W條視頻被發布，而在youtube上，每天上傳的內容可以連續播放80年。這裡面90%的內容都是通過手機拍攝的。————《影視颶風》
更低成本、更多渠道的媒體技術使用讓這個時代成為了創造力爆棚的時代。人們使用某種媒介的機會越多，我們越容易獲得這種機會、創造力、產出和創新。
那麼在「軟體設計開發」這個領域，歷史會重演嗎？
軟體研發的歷史
再回答這個問題之前，讓我們先回顧一下軟體工程的大致發展歷程：
1、彙編時代（1946 年—1953 年）
「遠古時代」的軟體是通過機器語言編寫的，機器語言是內置在計算機電路中的指令，由 0 和 1 組成（二進位數字）。因此，只有少數專業人員能夠為計算機編寫程序。
2、高級程序語言時期（1954 年—1964 年）
該階段軟體開始使用高級語言（與之對應機器語言和彙編語言被稱為低級語言）編寫，高級語言的指令形式類似於自然語言和數學語言，不僅容易學習，方便編程，一定程度上提高了程序的可讀性。
在這個時期，進行軟體編寫工作的人開始被稱為：「程序員」。
3、結構化程序理論設計階段（1965 年—1970 年）
該階段處於結構化程序設計理論，伴隨著的是處理器的運算速度大幅度的提高。因此需要編寫一種程序，使所有計算機資源處於計算機的控制中，這種程序就是操作系統。
資料庫管理系統 DBMS（Database Management System）也是在這一時期出現的。
1968 年，北大西洋公約組織的計算機科學家在聯邦德國召開國際會議並正式提出了：「軟體工程」這個名詞。
4、結構化程序時代（1971 年—1989 年）
這個階段標誌性的事件有：C語言的面世、Macintosh 的可視化圖形界面徹底改變了人機交互的方式、Pascal 及Modula-2 等基於結構化規則設計的語言面世。在這個時期，更多用途的軟體逐漸面世，例如文字處理、電子製表、資料庫管理軟體等。
5、大發展階段（1990 年—至今）
萬維網（World Wide Web）的出現開啟了萬物互聯的時代；面向對象的程序設計逐步代替了結構化程序設計，成為最流行的程序設計技術。這個時期，Microsoft 公司的崛起讓軟體工程進入到了大發展階段。
開發模式的大升級下依然存在的問題
完善的系統軟體、豐富的系統開發工具、商品化應用程序大量出現以及通信技術和計算機網路的飛速發展，極大的降低了軟體研發的門檻和成本。
從國內的研發生態角度看這個趨勢，最具影響力的事件則是2018年微信小程序提出的「雲開發」理念。「雲開發」讓前端工程師從前到後完成業務發開的閉環。「雲開發」將「DB優化」、「彈性擴容」、「攻擊防護」、「災備處理」等進行了封裝，讓程序員可以專註於業務實現，這是一種開發模式的大升級。
即便如此，計算機、軟體工程的門檻依然存在，對於大部分人來說是一項難以置信的專業任務。軟體工程極高的壁壘所帶來的問題包 含但不限於以下的幾項：
問題1：生產模式在沒有本質改變——高居不下的邊際成本
軟體研發的成本不僅僅是在一期交付上，更多的是後續不斷地迭代成本，需求的增刪改所帶來的研發邊際成本非常之高。
不少的企業級軟體項目在多年的迭代維護後往往面臨「舉步維艱」的地步：代碼維護的壓力越大、關鍵的研發崗位經不起人員變動、項目推動困難……
問題2：需求增長速度與生產消化速度之間的矛盾
這幾乎是一個業內共識，即需求的消化速度永遠趕不上產生的速度。需求池的維護以及排期的制定是困擾產品經理以及項目經理的大難題。
消費級互聯網日趨飽和的大背景下，產業互聯網全面崛起。信息化成為了所有企業繞不開的話題，這勢必會帶來企業級軟體需求的激增。
近年來，我國SaaS市場規模佔全球比重不斷提升，由5年前的2.93%提高到今年的7.65%，預計2020年還會有明顯提高。如何更快、更好地響應這些需求，是一個亟待解決的問題。
問題3：需求方與生產方之間難以逾越的溝通壁壘
程序思維和業務思維是兩種截然不同的思維模式。程序不懂業務、業務不懂程序，溝通效率的地下已經成為軟體型項目最大的攔路虎。
————
為了儘可能好的解決（嚴格意義上說來應該是「適應」）上述的這些問題，各種各樣的團隊提出了各個角度的解決方案（主要偏向於方法論）：
- 敏捷研發：快迭代、小版本的模式降低高邊際成本所帶來的風險；
- MVP：最小化的可行產品，在最小的範圍測試客戶群痛點，降低前期的驗證成本。
- DevOps：通過促進開發、技術運營和質保部門之間的溝通、協作與整合從而提升開發效率的概念。
- ……
方法論及理念只能部分解決問題，核心的問題依然存在。如今，我們依然需要更好的解決方案、更快的迭代及反饋。
軟體研發的公民化運動
在《人月神話》中，Brooks博士認為軟體工程所要解決的任務分為兩個：
主要任務 ： 打造構成抽象軟體實體的複雜概念結構。
短短一句話中充滿了複雜的定義，簡單來說就是將抽象需求進行具象化地整理。產品經理每天的工作就是圍繞這個「任務」展開的。在《用戶體驗要素》這本書中，作者Garrett將這個命題進行了分解，通過5大要素及1個簡潔的工作流清晰地講解將抽象需求整合成具象模型的方法。（配圖五大要素）
次要任務 ： 使用編程語言表達這些抽象實體映射成機器語言。
緊接著的次要任務則不難理解了，根本的目的則是主要任務所產出的具象化模型映射成為機器能夠理解的語言。上文中我們提到的軟體工程的歷史則是「如何更好地解決次要任務」的歷史。
而如今的無代碼產品則是在新的時代背景下對於「次要任務」的新的解答，其核心是解決了兩個任務關鍵節點之間的根本脫節。
更高模塊化的場景中，無代碼產品具備極高的可用性
主要任務在漫長的歷史上產生了極大的變化，例如toC和toB場景下的軟體從一開始的需求開始就是迥異的；相比較toC場景，toB場景的主要任務在漫長的時間裡並沒有太多本質的區別，反而某種程度上逐步提煉出了最佳實踐，模塊化的程度更高了，這也直接影響了2B領域無代碼技術的逐漸成熟。
已經存在的一些單項能力去代碼化無一例外都是圍繞企業服務場景的：表單、報表、流程、資料庫、頁面、事件……的定義能力；這些能力在各自的領域大放異彩，具備極高的可用性。
公民化運動：從「編寫」到「創建」
上世紀60年代，軟體的編寫者自身往往是使用者，幾經波折，我們幾乎迎來了「軟體的使用者是設計者自身」的時代：
如果你需要一個個人網站，webflow可以滿足你；
如果你需要一個業務資料庫，airtable可以滿足你：
如果你需要報表，PowerBI 可以滿足你：
使用zapier，你可以生成一個工作流，並且串聯多個系統。
在從前，當你有一些創意一些想法的時候，往往需要大量的準備和投入才能實現，過程中的內容一個環節都可能導致失敗。但如今，當你準備好的時候，一個個成熟的無代碼平台也都準備好隨時聽候差遣了。軟體消費者和軟體生產者之間的界限越來越模糊，某種意義上來說我們正在經歷一場變革。
無代碼平台並不是什麼新鮮的事情，甚至具備了極高的可用性，如果將這些已有的成熟單項能力進行了 集成，那麼我們可以做很多事情。而輕流則是這中間產品矩陣完備，兼具健壯性和易用性的代表之一。
輕流的無代碼框架介紹
輕流的無代碼aPaaS架構：
輕流講系統搭建抽象成四個維度的工作，分別是：
- 展現層
- 業務層
- 模型層
- 整合層
展現層、業務層、模型層的結合滿足業務系統搭建的需求，整合層則解決了企業內多系統數據孤島的問題
展現層（界面引擎）
輕流提供了豐富的頁面框架及樣式自定義能力，通過可視化的圖形配置界面，減免了大量JS/CSS/HTML的代碼。
- 多種業務組件
- 多端適配運行良好
- 訪問許可權控制（連接企業內外）
業務層（流程引擎、表單引擎、報表引擎、事件引擎）
通過業務人員最熟悉的表單界面為載體承載大量前端自定義事件。解決了大量業務邏輯問題，無代碼的流程引擎支持串聯自動化事件，我們稱之為Q-Robot，幫助業務人員解放雙手。
- 表單構建、前後端計算能力、
- 流程模型可視化搭建
- 業務所需的報表構建
- 豐富的事件拓展、支持跨系統執行
模型層（資料庫引擎）
面向業務人員的資料庫定義工具，儘可能地將操作「去代碼化」，以業務人員能夠理解的交互和可視化界面呈現給用戶。上手簡單、配置靈活。
- 可視化的資料庫建立、
- 支持業務所需的數據增刪改查功能
- 基於許可權角色分配數據許可權
- ......
整合層（連接引擎）
高度封裝的連接模塊，簡單地配置即可進行跨系統的數據連接，將ERP、CRM中的數據進行調用和同步，消滅數據孤島，為遺留系統提供現代化的可能。
- Q-Source數據源自定義
- Q-Linker跨系統數據關聯
- Q-Reminder 跨系統提醒推送
- Q-Authentication鑒權自定義
- SSO單點登錄、webhook、openAPI
面向不同受眾（用戶畫像）的無代碼平台，設計出發點也是不同的：
- 面向業務人員：表單交互模型搭建入手 （輕流的選擇）
- 面向技術人員：資料庫模型搭建入手
輕流的產品設計初衷並非是要替代程序員原本的工作，就如前面我們講到的 「對以前僅一小部分人可用的過程工具或介質進行公民化拓展，並通過此倍增人類創造的潛力 」 ，這才是輕流真正的目的。
Give people wonderful tools and theyll do wonderful things————蘋果對於上面這句話的理解
基於這樣一個願景，我們眼下最重要要解決的則是「如何讓業務人員可以儘可能快的體驗到「親手創造」業務系統的自在和快樂」這個問題。「易用性」的重要性在這個背景下被放大了。
與此同時，易用性和健壯度的對立統一則成了我們所面對最棘手的難題。我們在不斷摸索中，也開始找到一些方法，後續慢慢會跟大家分享我們的思考。
讓我們來聊聊破壞性創新
今年初去世的 克里斯坦森 畢生最偉大的著作《創新者的窘境》中提到一概念叫：破壞性創新；
這個理念深深影響了蘋果、微軟等巨頭企業；書中所描述的「以下犯上」在整個商業史上比比皆是：個人計算機對於計算機市場的顛覆、小容量編寫硬碟對大型企業級硬碟的顛覆……
甚至到如今，我們的身邊所充斥著那些我們無法忽視的趨勢：移動端計算平台的崛起、計算能力主導的影像系統、新能源汽車……每天都在為我們演示破壞性的創新如果通過「猥瑣」的發育逐漸成為主流需求而改變歷史軌跡。
近些年，在2B企業級市場，我們看到具備破壞性創新特點的模式或產品不斷湧現：雲計算、SaaS化……
我們認為無代碼平台也是這個信息化浪潮中的一員。
一些無法忽視的趨勢
「到2024年，無代碼/低代碼應用程序開發將佔應用程序開發活動的65％以上。」————Gartner預測
在剛剛過去的國慶節，大洋彼岸的北美，一個新的無代碼獨角獸悄悄地崛起——unqork宣布已完成20700萬美元的C輪融資，估值為20億美元。總融資達3.5億美元。
稍早一些的9月14日，業務資料庫自定義工具Airtable宣布以26億美元的估值募集了1.85億美元的D輪融資，這個估值比2018年底的11億美元又翻了一番還多。
而輕流 在疫情這樣一個特殊時期下，也獲得了來自源碼資本領投的數千萬A輪融資。
很多人都覺得 如今的無代碼平台「噱頭大於實際」、「更像是玩具」、「可用性還比較低」。
對於從業的我們來說，我們也不否認通過「無代碼平台」完全替代現有企業及軟體交付模式在現階段還不是很切實際。
不過在這樣一個積累即是壁壘的賽道，明天總歸是充滿光明的~
「無代碼運動」是幾千年以來驅動技術創新的核心原則的演變：
不斷對以前僅一小部分人可用的過程工具或介質進行公民化拓展並通過此倍增人類創造的潛力。
各個領域的公民化運動
在印刷機問世之前，批量生產書籍的唯一方法是手工製作，這使得傳播信息和知識不僅很慢而且昂貴。一本羊皮紙的《聖經》在中世紀可是土豪才能擁有的資產，相當於一座葡萄園的價格。
書籍如此昂貴，你還會為中世紀大部分人是文盲而感到驚奇嗎？
然而1440年印刷機的發明以嶄新的方式大規模生產和發行新文本成為可能。現如今，如果你想讓文字發布到世界各地，只需要敲擊幾下鍵盤即可。
隨著這些基礎技術的公民化普及，世界範圍內的出版數量與日俱增（配圖為200年中每100萬人中新書的出版數量增長）
同樣的事情也發生在音樂和電影領域，技術及其使用方式對人的創作產生了巨大影響。過去我們需要專業的錄音棚以及價格昂貴的錄製設備才能進行相關創作。
如今更多的數字化分發渠道、線上流量的劇增、自媒體平台的興起（BiliBili、抖音、youtube等）以及公民化設備的技術躍遷（移動手機的攝像頭質量在過去幾年有了大幅度提升）讓人們可以在沒有太多前期資源的情況下依然分享自己的創意和想法。
在B站，每天有10W條視頻被發布，而在youtube上，每天上傳的內容可以連續播放80年。這裡面90%的內容都是通過手機拍攝的。————《影視颶風》
更低成本、更多渠道的媒體技術使用讓這個時代成為了創造力爆棚的時代。人們使用某種媒介的機會越多，我們越容易獲得這種機會、創造力、產出和創新。
那麼在「軟體設計開發」這個領域，歷史會重演嗎？
軟體研發的歷史
再回答這個問題之前，讓我們先回顧一下軟體工程的大致發展歷程：
1、彙編時代（1946 年—1953 年）
「遠古時代」的軟體是通過機器語言編寫的，機器語言是內置在計算機電路中的指令，由 0 和 1 組成（二進位數字）。因此，只有少數專業人員能夠為計算機編寫程序。
2、高級程序語言時期（1954 年—1964 年）
該階段軟體開始使用高級語言（與之對應機器語言和彙編語言被稱為低級語言）編寫，高級語言的指令形式類似於自然語言和數學語言，不僅容易學習，方便編程，一定程度上提高了程序的可讀性。
在這個時期，進行軟體編寫工作的人開始被稱為：「程序員」。
3、結構化程序理論設計階段（1965 年—1970 年）
該階段處於結構化程序設計理論，伴隨著的是處理器的運算速度大幅度的提高。因此需要編寫一種程序，使所有計算機資源處於計算機的控制中，這種程序就是操作系統。
資料庫管理系統 DBMS（Database Management System）也是在這一時期出現的。
1968 年，北大西洋公約組織的計算機科學家在聯邦德國召開國際會議並正式提出了：「軟體工程」這個名詞。
4、結構化程序時代（1971 年—1989 年）
這個階段標誌性的事件有：C語言的面世、Macintosh 的可視化圖形界面徹底改變了人機交互的方式、Pascal 及Modula-2 等基於結構化規則設計的語言面世。在這個時期，更多用途的軟體逐漸面世，例如文字處理、電子製表、資料庫管理軟體等。
5、大發展階段（1990 年—至今）
萬維網（World Wide Web）的出現開啟了萬物互聯的時代；面向對象的程序設計逐步代替了結構化程序設計，成為最流行的程序設計技術。這個時期，Microsoft 公司的崛起讓軟體工程進入到了大發展階段。
開發模式的大升級下依然存在的問題
完善的系統軟體、豐富的系統開發工具、商品化應用程序大量出現以及通信技術和計算機網路的飛速發展，極大的降低了軟體研發的門檻和成本。
從國內的研發生態角度看這個趨勢，最具影響力的事件則是2018年微信小程序提出的「雲開發」理念。「雲開發」讓前端工程師從前到後完成業務發開的閉環。「雲開發」將「DB優化」、「彈性擴容」、「攻擊防護」、「災備處理」等進行了封裝，讓程序員可以專註於業務實現，這是一種開發模式的大升級。
即便如此，計算機、軟體工程的門檻依然存在，對於大部分人來說是一項難以置信的專業任務。軟體工程極高的壁壘所帶來的問題包 含但不限於以下的幾項：
問題1：生產模式在沒有本質改變——高居不下的邊際成本
軟體研發的成本不僅僅是在一期交付上，更多的是後續不斷地迭代成本，需求的增刪改所帶來的研發邊際成本非常之高。
不少的企業級軟體項目在多年的迭代維護後往往面臨「舉步維艱」的地步：代碼維護的壓力越大、關鍵的研發崗位經不起人員變動、項目推動困難……
問題2：需求增長速度與生產消化速度之間的矛盾
這幾乎是一個業內共識，即需求的消化速度永遠趕不上產生的速度。需求池的維護以及排期的制定是困擾產品經理以及項目經理的大難題。
消費級互聯網日趨飽和的大背景下，產業互聯網全面崛起。信息化成為了所有企業繞不開的話題，這勢必會帶來企業級軟體需求的激增。
近年來，我國SaaS市場規模佔全球比重不斷提升，由5年前的2.93%提高到今年的7.65%，預計2020年還會有明顯提高。如何更快、更好地響應這些需求，是一個亟待解決的問題。
問題3：需求方與生產方之間難以逾越的溝通壁壘
程序思維和業務思維是兩種截然不同的思維模式。程序不懂業務、業務不懂程序，溝通效率的地下已經成為軟體型項目最大的攔路虎。
————
為了儘可能好的解決（嚴格意義上說來應該是「適應」）上述的這些問題，各種各樣的團隊提出了各個角度的解決方案（主要偏向於方法論）：
- 敏捷研發：快迭代、小版本的模式降低高邊際成本所帶來的風險；
- MVP：最小化的可行產品，在最小的範圍測試客戶群痛點，降低前期的驗證成本。
- DevOps：通過促進開發、技術運營和質保部門之間的溝通、協作與整合從而提升開發效率的概念。
- ……
方法論及理念只能部分解決問題，核心的問題依然存在。如今，我們依然需要更好的解決方案、更快的迭代及反饋。
軟體研發的公民化運動
在《人月神話》中，Brooks博士認為軟體工程所要解決的任務分為兩個：
主要任務 ： 打造構成抽象軟體實體的複雜概念結構。
短短一句話中充滿了複雜的定義，簡單來說就是將抽象需求進行具象化地整理。產品經理每天的工作就是圍繞這個「任務」展開的。在《用戶體驗要素》這本書中，作者Garrett將這個命題進行了分解，通過5大要素及1個簡潔的工作流清晰地講解將抽象需求整合成具象模型的方法。（配圖五大要素）
次要任務 ： 使用編程語言表達這些抽象實體映射成機器語言。
緊接著的次要任務則不難理解了，根本的目的則是主要任務所產出的具象化模型映射成為機器能夠理解的語言。上文中我們提到的軟體工程的歷史則是「如何更好地解決次要任務」的歷史。
而如今的無代碼產品則是在新的時代背景下對於「次要任務」的新的解答，其核心是解決了兩個任務關鍵節點之間的根本脫節。
更高模塊化的場景中，無代碼產品具備極高的可用性
主要任務在漫長的歷史上產生了極大的變化，例如toC和toB場景下的軟體從一開始的需求開始就是迥異的；相比較toC場景，toB場景的主要任務在漫長的時間裡並沒有太多本質的區別，反而某種程度上逐步提煉出了最佳實踐，模塊化的程度更高了，這也直接影響了2B領域無代碼技術的逐漸成熟。
已經存在的一些單項能力去代碼化無一例外都是圍繞企業服務場景的：表單、報表、流程、資料庫、頁面、事件……的定義能力；這些能力在各自的領域大放異彩，具備極高的可用性。
公民化運動：從「編寫」到「創建」
上世紀60年代，軟體的編寫者自身往往是使用者，幾經波折，我們幾乎迎來了「軟體的使用者是設計者自身」的時代：
如果你需要一個個人網站，webflow可以滿足你；
如果你需要一個業務資料庫，airtable可以滿足你：
如果你需要報表，PowerBI 可以滿足你：
使用zapier，你可以生成一個工作流，並且串聯多個系統。
在從前，當你有一些創意一些想法的時候，往往需要大量的準備和投入才能實現，過程中的內容一個環節都可能導致失敗。但如今，當你準備好的時候，一個個成熟的無代碼平台也都準備好隨時聽候差遣了。軟體消費者和軟體生產者之間的界限越來越模糊，某種意義上來說我們正在經歷一場變革。
無代碼平台並不是什麼新鮮的事情，甚至具備了極高的可用性，如果將這些已有的成熟單項能力進行了 集成，那麼我們可以做很多事情。而輕流則是這中間產品矩陣完備，兼具健壯性和易用性的代表之一。
輕流的無代碼框架介紹
輕流的無代碼aPaaS架構：
輕流講系統搭建抽象成四個維度的工作，分別是：
- 展現層
- 業務層
- 模型層
- 整合層
展現層、業務層、模型層的結合滿足業務系統搭建的需求，整合層則解決了企業內多系統數據孤島的問題
展現層（界面引擎）
輕流提供了豐富的頁面框架及樣式自定義能力，通過可視化的圖形配置界面，減免了大量JS/CSS/HTML的代碼。
- 多種業務組件
- 多端適配運行良好
- 訪問許可權控制（連接企業內外）
業務層（流程引擎、表單引擎、報表引擎、事件引擎）
通過業務人員最熟悉的表單界面為載體承載大量前端自定義事件。解決了大量業務邏輯問題，無代碼的流程引擎支持串聯自動化事件，我們稱之為Q-Robot，幫助業務人員解放雙手。
- 表單構建、前後端計算能力、
- 流程模型可視化搭建
- 業務所需的報表構建
- 豐富的事件拓展、支持跨系統執行
模型層（資料庫引擎）
面向業務人員的資料庫定義工具，儘可能地將操作「去代碼化」，以業務人員能夠理解的交互和可視化界面呈現給用戶。上手簡單、配置靈活。
- 可視化的資料庫建立、
- 支持業務所需的數據增刪改查功能
- 基於許可權角色分配數據許可權
- ......
整合層（連接引擎）
高度封裝的連接模塊，簡單地配置即可進行跨系統的數據連接，將ERP、CRM中的數據進行調用和同步，消滅數據孤島，為遺留系統提供現代化的可能。
- Q-Source數據源自定義
- Q-Linker跨系統數據關聯
- Q-Reminder 跨系統提醒推送
- Q-Authentication鑒權自定義
- SSO單點登錄、webhook、openAPI
面向不同受眾（用戶畫像）的無代碼平台，設計出發點也是不同的：
- 面向業務人員：表單交互模型搭建入手 （輕流的選擇）
- 面向技術人員：資料庫模型搭建入手
輕流的產品設計初衷並非是要替代程序員原本的工作，就如前面我們講到的 「對以前僅一小部分人可用的過程工具或介質進行公民化拓展，並通過此倍增人類創造的潛力 」 ，這才是輕流真正的目的。
Give people wonderful tools and theyll do wonderful things————蘋果對於上面這句話的理解
基於這樣一個願景，我們眼下最重要要解決的則是「如何讓業務人員可以儘可能快的體驗到「親手創造」業務系統的自在和快樂」這個問題。「易用性」的重要性在這個背景下被放大了。
與此同時，易用性和健壯度的對立統一則成了我們所面對最棘手的難題。我們在不斷摸索中，也開始找到一些方法，後續慢慢會跟大家分享我們的思考。
讓我們來聊聊破壞性創新
今年初去世的 克里斯坦森 畢生最偉大的著作《創新者的窘境》中提到一概念叫：破壞性創新；
這個理念深深影響了蘋果、微軟等巨頭企業；書中所描述的「以下犯上」在整個商業史上比比皆是：個人計算機對於計算機市場的顛覆、小容量編寫硬碟對大型企業級硬碟的顛覆……
甚至到如今，我們的身邊所充斥著那些我們無法忽視的趨勢：移動端計算平台的崛起、計算能力主導的影像系統、新能源汽車……每天都在為我們演示破壞性的創新如果通過「猥瑣」的發育逐漸成為主流需求而改變歷史軌跡。
近些年，在2B企業級市場，我們看到具備破壞性創新特點的模式或產品不斷湧現：雲計算、SaaS化……
我們認為無代碼平台也是這個信息化浪潮中的一員。
一些無法忽視的趨勢
「到2024年，無代碼/低代碼應用程序開發將佔應用程序開發活動的65％以上。」————Gartner預測
在剛剛過去的國慶節，大洋彼岸的北美，一個新的無代碼獨角獸悄悄地崛起——unqork宣布已完成20700萬美元的C輪融資，估值為20億美元。總融資達3.5億美元。
稍早一些的9月14日，業務資料庫自定義工具Airtable宣布以26億美元的估值募集了1.85億美元的D輪融資，這個估值比2018年底的11億美元又翻了一番還多。
而輕流 在疫情這樣一個特殊時期下，也獲得了來自源碼資本領投的數千萬A輪融資。
很多人都覺得 如今的無代碼平台「噱頭大於實際」、「更像是玩具」、「可用性還比較低」。
對於從業的我們來說，我們也不否認通過「無代碼平台」完全替代現有企業及軟體交付模式在現階段還不是很切實際。
不過在這樣一個積累即是壁壘的賽道，明天總歸是充滿光明的~
通俗的講，隨著toC的互聯網發展，消費者和員工對信息化的需求水漲船高。但是，企業對應用開發的需求越來越多，專業開發人員不足，低代碼成了唯一的解藥。
程序員不夠用了！
按照中軟協的說法：Gartner預計，2021年市場對於應用開發的需求將五倍於IT公司的產能。為填補這一產量缺口，低代碼/零代碼技術是目前唯一可行的解決方案，必然會有越來越多企業引入這一技術。Forrester指出2020年低代碼市場規模或將達到155億美元，超過75％的應用程序將在低代碼/零代碼平台中開發。隨著低代碼應用場景不斷拓寬，2020年會有更多企業或企業信息化服務提供商將採用技術門檻更低、開發效率更高的低代碼開發平台，為自己量身定做企業核心系統以滿足個性化的企業管理需求。
前些年，企業的需求大體上處在第一階段，即使用通用的行業軟體來解決大面上的問題；現在更多企業在第一階段的基礎上進入了第二階段，即期望通過定製化的系統（可以完全定製、也可以在行業軟體基礎上做客開）全面滿足各種業務場景。需求的進化，讓程序員不足的情況變得越來越嚴重。這個時候，急需一種技術，能讓更多人變身程序員，為企業做開發。誰能真的解決這一問題，誰就站在了新的風口（雖然這個風口的風力註定比toC的小很多）。
中國軟體行業協會?www.csia.org.cn
為啥不是零代碼？
目前能降低開發技術門檻的技術主要有低代碼和零代碼兩種，兩者看上去都「很有前途」。但是，為企業做一套承載核心業務的軟體（如整套ERP）和個人/部門內弄一個軟體來提升工作效率（如數據填報）的要求是完全不同的，體現在架構的擴展性、與第三方系統的集成性到部署可控性等諸多方面。這就意味著，企業級系統對開發工具的架構、擴展性和部署的靈活性提出了更高的要求。低代碼幾乎成了唯一的選擇。dzone上有一篇文章，列舉了美國主流的無代碼產品，如Appsheet等相比於Outsystems等低代碼產品在企業領域的硬傷，包含：
- 前後端分離：無代碼產品大多沒有數據表的概念，表單即表，無法應對稍微複雜一些的數據模型
- 擴展性：無代碼在編程介面等方面的缺失，讓其很難與企業現有系統做集成
- 部署方式：與某個雲服務綁定，無法實現自由部署（私有化部署）是大多數無代碼產品的硬傷
雖然在國內，低代碼和零代碼一般都會混在一起，但是在國外，為了避免對企業造成誤解，一些權威機構的行業分析師們已經開始將一些無代碼平台供應商從一些相關報告中移出，如Forrester Research公司發布的報告《2019 Q1 Forrester Wave:面嚮應用程序開發和交付專業人員的低代碼開發平台》，同時將它們轉移到那些只適用有限用例的平台報告中。
--------------
總之，面對企業的個性化需求，程序員不足已經成為瓶頸，表現為程序員越來越難招，外包開發越來越貴；而解決這一問題的唯一方案就是低代碼，豈有不火的道理？
摘錄自簡書
推薦閱讀：
