02 帶貨主播績效考核標準(股權激勵對激勵對象的考核是什么的考核)

者就是除此之外在實際開發過程中引入的復雜度。通常來說，本質復雜度與業務要解決的特定問題域強相關，因此這里我把它稱為更好理解的“業務復雜度”；這部分復雜度不是任何開發方法或工具能解決的，包括低代碼。而偶然復雜度一般與開發階段的技術細節強相關，因此我也相應把它稱為“技術復雜度”；而這一部分復雜度，恰好就是低代碼所擅長且適合解決的。

為開發者盡可能屏蔽底層技術細節、減少不必要的技術復雜度，并支撐其更好地應對業務復雜度（滿足靈活通用的業務場景需求），這是身為一個低代碼開發平臺所應該盡到的核心職責。

請點擊輸入圖片描述

在盡到上述職責的同時，低代碼開發平臺作為一個面向開發者的產品，還需要致力于為開發者提供簡單直觀的極致開發體驗。這背后除了巨大的工作量，還得能在“強大”和“易用”這兩個很難兩全其美的矛盾點之間，努力找到一個符合自己產品定位與目標客戶需求的平衡點 —— 這也許是設計一個通用低代碼開發平臺所面臨的最大挑戰。

三、低代碼相關概念對比

純代碼（Pro-Code / Custom-Code）

“純代碼”可能算是我杜撰的一個詞，更常見的說法是專業代碼（Pro-Code）或定制代碼（Custom-Code）；但意思都一樣，就是指傳統的以代碼為中心（Code-Centric）的開發模式。之所以我選擇用“純代碼”，是因為如果用“專業代碼”會顯得似乎低代碼就不專業了一樣，而用“定制代碼”又容易讓人誤解成低代碼無法支持定制的自定義代碼。

當然，更準確的稱謂我認為是“高代碼”（與低代碼恰好對應，只是名字太難聽，被我嫌棄了...），因為即便是使用傳統的代碼IDE，有些開發工作也支持（甚至更適合）以非代碼方式完成，比如：iOS端開發時使用的SwiftUI界面設計器、服務端開發數據庫應用時使用的PowerDesigner建模工具。不過這部分可視化工作在傳統開發模式下只是起輔助作用，最后通常也是生成開發者可直接修改的代碼；開發者仍然是以代碼為中心來開展主要工作。

低代碼與純代碼之間的關系，其實跟視頻和文章之間很像：

低代碼就像是現代的“視頻”，大部分內容都由直觀易理解、表達能力強的圖片組成，因此更容易被大眾所接受。但與此同時，視頻也不是死板得只能有圖片，完全可以添加少量文字（如字幕、標注）來彌補圖片表達不夠精確的問題。BTW，關于“圖”和“文字”之間的辯證關系，可以進一步參考《架構制圖：工具與方法論》[1]這篇文章中的相關描述。

純代碼則更像是傳統的“文章”，雖然很久以來都一直是信息傳播的唯一媒介，但自從視頻技術誕生以及相應軟硬件基礎設施的普及以來，便逐漸開始被搶走了風頭。如今，視頻已成為大部分人獲取信息的主要渠道（從電視電影到B站抖音），而經常讀書讀文章的人卻越來越少。但不可否認的是，文章依然有它存在的意義和受眾（不然我也不會費這勁敲這么多字了），即使“市場份額”一直在被擠壓，但永遠會有它立足的空間。

請點擊輸入圖片描述

如果按上面這種類比關系推導，低代碼未來也會遵循與視頻類似的發展軌跡，超越純代碼成為主流開發模式。Gartner的預測也表達了相同的觀點：到2024年，所有應用程序開發活動當中的65%將通過低代碼的方式完成，同時75%的大型企業將使用至少四種低代碼開發工具進行應用開發。

但同樣地，就像是視頻永遠無法取代文章一樣，低代碼也永遠無法徹底取代純代碼開發方式。未來低代碼和純代碼方式將以互補的形態長期共存，各自在其所適合的業務場景中發光發熱。在后面的“低代碼業務場景”章節，會詳細列出哪些場景在現階段更適合用低代碼模式開發。

零代碼（Zero-Code / No-Code）

從分類的完備性角度來看，有“純代碼”自然也應該有完全相反的“零代碼”（也稱為“無代碼”）。零代碼就是完全不需要寫代碼的應用開發平臺，但這并不代表零代碼就比低代碼更高級和先進，它只是做了一個更極端的選擇而已：徹底擁抱簡單的圖形可視化，完全消滅復雜的文本代碼。選擇背后的原因是，零代碼開發平臺期望能盡可能降低應用開發門檻，讓人人都能成為開發者（注意：開發 ≠ 寫代碼），包括完全不懂代碼的業務分析師、用戶運營，甚至是產品經理（不懂裝懂可不算懂）。

即便是專業開發者，在技術分工越來越精細的趨勢下（前端/后端/算法/SRE/數據分析..），也很難招到一個能獨立開發和維護整套復雜應用的全棧工程師。但零代碼可以改變這一切：無論是Java和JavaScript傻傻分不清楚的技術小白，還是精通深度學習但沒時間學習Web開發的算法大牛，都可以通過零代碼實現自己的技術夢或全棧夢。“改變世界的idea已有，就差一個程序員了”，這句玩笑話或許真的可以成真；哦不，甚至都用不著程序員，有idea的人自己就能上。

請點擊輸入圖片描述

當然，所有選擇都要付出代價，零代碼也不例外。完全拋棄代碼的代價，就是平臺能力與靈活性受限：

• 一方面，可視化編輯器的表達能力遠不及圖靈完備的通用編程語言，不引入代碼根本沒法實現靈活的定制與擴展（當然，理論上也可以做成Scrach/Blockly那樣的圖形編程語言，但那樣不過是換一種形式在手寫代碼而已）。

• 另一方面，由于目標受眾是非專業開發人員，平臺能支持的操作會更趨于“傻瓜化”（e.g. 頁面只支持大塊業務組件的簡單堆疊，不支持細粒度原子組件和靈活的CSS布局定義），同時也只會透出相對“親民化”的模型和概念（e.g. 使用“表格”表示數據，而不是用“數據庫”），無法支撐強大專業的底層開發原語和編程理念。

請點擊輸入圖片描述

雖然零代碼與狹義上的低代碼有著上述明顯差異，但從廣義上來說，零代碼可以當作低代碼的一個子集。Gartner在其相關調研報告中，就是將“No Code”劃在了范圍更廣的低代碼應用平臺“LCAP”（Low-Code Application Platform）中。而當前市面上很多通用的低代碼開發平臺，也都兼具一定程度的零代碼能力；比如低代碼領域領頭羊Mendix，既提供了簡單易用的零代碼Web IDE - Mendix Studio，也包括一個功能更強大的低代碼桌面IDE - Mendix Studio Pro。

HpaPaaS（高生產力應用PaaS）

上文提到，“Low-Code”一詞是拜Forrester所賜。作為同樣是國際知名調研機構（a.k.a 造詞小能手）的Gartner，顯然不會輕易在這場可能決定低代碼領域江湖地位的新概念作詞大賽中認輸，于是也于2017年發明了“HpaPaaS”（High-proctivity application Platform as a Service）這個聽上去更高大上的縮寫詞。

按照Gartner的定義，HpaPaaS是一種支持聲明式、模型驅動設計和一鍵部署的平臺，提供了云上的快速應用開發（RAD）、部署和運行特性；這顯然與低代碼的定義如出一轍。但事實證明，名字起得太專業并不見得是好事，“HpaPaas”最終還是敗給了起源更早、更接地氣也更順口的“Low-Code”：從2019年開始，Gartner在其相關調研報告中也開始全面采用“Low-Code”一詞（如LCAP），親手為“HpaPaaS”打上了 @deprecated 印記。

請點擊輸入圖片描述

圖源：What’s the difference between SaaS / IaaS / PaaS / aPaaS / HpaPaaS?

值得補充的是，“HpaPaaS“這個詞也并非橫空出世，而是傳承自更早之前Gartner提出的“aPaaS”，它倆之間的關系是：HpaPaaS只是aPaaS的一個子類；除了HpaPaaS這種通過低代碼實現的高生產力應用開發平臺以外，aPaaS還包括面向純代碼的傳統應用開發平臺（High-買粉絲ntrol aPaaS，即可控度更高的純代碼開發方式）。

不值得但就想八卦一下的是，“aPaaS”這個詞也非憑空捏造，而是與云計算的興起淵源頗深。相信各位云道中人都已猜到，aPaaS與IaaS/PaaS/SaaS這些云計算遠古概念是一脈相承的：aPaaS介于PaaS和SaaS之間，相比PaaS提供的服務更偏應用，但又不像SaaS一樣提供現成的軟件服務（更詳細的說明可參考配圖來源文章）。

四、為什么需要低代碼

低代碼是什么可能并沒那么重要，畢竟在這個信息爆炸的世界，永遠不缺少新奇而又短命的事物。大部分所謂的新技術都只是曇花一現：出現了，被看到了；大部分人“哦”了一聲，已閱但表示不感興趣；小部分人驚嘆于它的奇思妙想，激動地點了個贊后，回過頭來該用什么還是什么。真正決定新技術是否能轉化為新生產力的，永遠不是技術本身有多么優秀和華麗，而是它是否真的被需要，即：為什么需要低代碼？如果用不同的主語填充上面這個問句（冷知識：這叫做“延遲主語初始化”），可以更全面地看待這個問題：

為什么「市場」需要低代碼？

在這個大爺大媽都滿嘴“互聯網+”和“數字化轉型”的時代，企業越來越需要通過應用（App）來改善企業內部的信息流轉、強化與客戶之間的觸點連接。然而，誕生還不太久的IT信息時代，也正面臨著與我國社會主義初級階段類似的供需關系矛盾：落后的軟件開發生產力跟不上人民日益增長的業務需求。

請點擊輸入圖片描述

Gartner預測，到2021年應用開發需求的市場增長將至少超過企業IT交付能力的5倍。面對如此巨大的IT缺口，如果沒有一種革命性的“新生產力”體系，很難想象僅憑現有傳統技術體系的發展延續就能徹底解決問題。而低代碼技術正是帶著這樣的使命而降臨，期望通過以下幾個方面徹底革新應用開發生產力，拯救差一點就要邁入水深火熱的IT世界：

提效降本 & 質量保障

雖然軟件行業一直在高速發展，新的語言、框架和工具層出不窮，但作為從業者我們不得不承認：軟件開發仍處于手工作坊階段，效率低、人力成本高、質量不可控。項目延期交付已成為行業常態，而瓶頸幾乎總是開發人員（對機器能解決的問題都不是問題）；優秀的開發人才永遠是稀缺資源，還賊貴；軟件質量缺陷始終無法收斂，線上故障頻發資損不斷。

相比而言，傳統制造業經過幾百年工業革命的發展，大部分早已擺脫了對“人”的強依賴：從原料輸入到制品輸出，中間是各種精密儀器和自動化流水線的穩定支撐，真正實現生產的標準化和規模化。雖然信息化號稱是人類的第三次工業革命，但以軟件行業目前的狀況，遠遠還沒到達成熟的“工業化”階段。

所以，親愛的程序員朋友，當你與前端聯調了一上午接口，又與產品撕逼了一下午需求，再與自己的bug抗爭了一整晚，好不容易遁入夢鄉又被一連串報警短信吵醒時，是否有抬頭對著星空憧憬過：“I have a dream... that one day，軟件開發也能像工業制品一樣，批量流水化生產，穩定高效沒煩惱。” 事到如今，不管你有沒有意識到，這個憧憬正在慢慢變成現實。

請點擊輸入圖片描述

是的，低代碼正在將應用軟件開發過程工業化：每個低代碼開發平臺都是一個技術密集型的應用工廠，所有項目相關人員都在同一條產線內緊密協作。開發主力不再是熟知

很赞哦!（21799）