聊聊「低程式碼」的實踐之路

區塊鏈、低程式碼、元宇宙、AI智慧；

【先來說說背景】

這個概念由來已久，但是在國內興起，是最近幾年；

低程式碼即「Low-Code」；

指提供視覺化開發環境，可以用來建立和管理軟體應用；

簡單的說；

就是可以通過各種元件的拖拽，實現頁面的建立，互動流程和邏輯，以及資料層面的管理，更加高效的實現需求；

早先在資料公司時；

見識過低程式碼的應用，也參與過部分研發，比如後設資料平臺，BI分析等；

不過，當時還是以資料管理的工具來定義專案，並非是低程式碼；

從「2020年底」開始；

實際上，那個時間節點，低程式碼平臺的應用已經形成趨勢了；

現在的公司，將「低程式碼」平臺的使用「規劃」到「業務體系」中；

後來看，這是一個非常正確的決策；

在當時的討論會議上，大Boss給的理念；

非核心業務全面整合到低程式碼平臺中，將核心業務的邊緣流程，以實踐的方式遷出小部分到低程式碼平臺中；

並且給了理由，是基於「行業趨勢」和「業務週期」的整體考慮，才做出的決策；

其實，所謂的降本增效，也會遵循上述的規律；

不過遭到技術部的「稍微」反對；

主管還當場給了理由，說明為何不支援這樣的決策；

但是最終的討論結果，出自部門老大的建議；

不動核心業務，先將「邊緣業務」遷入，根據「效果」再決策後續規劃；

當然大Boss最終認同這個結論；

以實踐三年後的今天來看，人和人的「差距」確實挺大的；

組織內「Boss」層面的決策正確，「部門」層面的執行節奏，「員工」層面的後知後覺；

有感覺到明顯的認知「差距」；

【聊聊最初的疑惑】

客觀來說；

在研發領域內，大部分玩家對新事物都有一定的「排斥」情緒；

新事物意味「打破習慣」和諸多「不確定」因素；

主觀來說；

個人雖然也有排斥新事物的心理，但是很少質疑有趨勢性的事物，當低程式碼應用成為流行趨勢時，個人選擇跟隨就好；

技術部為何下意識的反對低程式碼應用？

從最近三年的實踐和採坑經驗來說，以下問題可能都會成為「否定」的因素；

【問題1】平臺選擇；

這裡重點考慮兩個維度：普遍性和業務特性；

如果只是常規的業務數位化轉型，建議優先從大的生態選擇，比如「某微」或「某釘」，相對而言會更便捷；

如果有行業客製化化的需求，則需要有針對性調研，比如財務系統，人事管理等；

【問題2】成本困擾；

思考一個問題：

簡單業務需求從整體共同作業去考慮，涉及的時間成本、人力成本、以及產品技術的維護成本；

計算成本之後，和低程式碼平臺的費用做對比；

客觀的「數位」最有說服力；

這裡依舊是降本增效的策略：更低的時間，更高的效率，更少的成本，更多的回報；

【問題3】業務適用性；

低程式碼應用剛火起來不久，並沒有發展到各行各業都有成熟合適的解決方案；

所以針對低程式碼平臺的使用；

最大的爭議點就是，沒有找到符合業務特性的平臺，但是管理層急於追求數位化和降本；

這種情況下；

如果盲目引入到業務體系中，後期難免會成為燙手的山芋；

所以充分的調研，以及對市場上各種案例的參考，從而客觀的分析公司當前的業務階段，是否有必要引入低程式碼應用；

【問題4】複雜後的維護性；

涉及到一個決策問題，低程式碼應用到底誰來維護？

業務人員還是研發角色？

從實踐經驗看；

建議是由業務方將需求對接到研發團隊，個人所在的組織中，是一個產品加一個研發，一起負責低程式碼平臺的迭代；

值得注意的是；

低程式碼應用具有一定的使用門檻，在使用的時候需要遵循普遍的開發原則和規範，以此保證持續可維護性；

【簡單聊聊原理】

在說低程式碼的實踐之前，先來分析一下基礎性的原理；

如果是普遍的共性業務；

常規就是頁面的渲染和展示，資料層面的增刪改查，計算層面的加減乘除，當然還要考慮模型整體的驅動和互動邏輯；

如果是行業特色的業務；

則需要低程式碼平臺中進行深度客製化化的功能，提供其特定的解決方案；

從技術角度進行原理的簡單分析；

在低程式碼系統中，十分考驗前後端的整體「封裝」能力；

前端，頁面中各種元件和工具的管理，互動時各種動態計算，頁面整體的資料填充；

後端，提供整體的模型驅動能力，封裝不同場景下的公共的互動介面，從而實現各個模組的流程和邏輯；

資料，比較常規的手段有兩種；

【1】進行縱向的表結構設計，資料儲存層面使用鍵值對的方式，構建搜尋查詢的邏輯比較複雜；

【2】資料採用JSON的格式，在資料體量大的情況下，要考慮查詢效率問題；

【3】資料還要提供基礎的分析和匯入匯出能力，以及API層面或者資料通道的搬運能力；

實際上低程式碼應用的現狀，還會提供各種應用和生態的整合能力；

追求功能的全面性；

可以參考「某微」或「某釘」的低程式碼平臺的整合能力；

【組織內實踐案例】

明白低程式碼的基礎原理之後，再來聊聊近「3年」的實踐；

首先要明確一個「認知」；

如果只是從研發角度「縱向」看；

業務可能就是產品矩陣中所涉及的各種事務流程，以及參與流程管理和共同作業的各個角色；

角度沒有問題，但是有點孤立；

但是，「橫向」的從組織的整體來看；

即便拋開產品層面，還存在諸多的共同作業事項，業務流程的管理；

這些普遍不會被整合到產品矩陣中；

但是同樣值得「資訊化」和「數位化」管理，從而打造「標準化」流程；

在引入低程式碼平臺之後，會形成如下的應用體系；

在工作中，如果涉及多部門間的「橫向」交集；

那麼會接觸到很多第三方應用，而非單純的研發部門搭建的產品體系；

有的應用極具行業的特色，有的應用傾向共性業務的管理，有的應用傾向私域客群的維護；

不同平臺的共通點，都是可以提供客製化化的低程式碼能力；

最為關鍵的是；

這些平臺都提供「對外」的「互動」能力，可以是第三方應用之間的互動，也可以是與內部的產品體系互動；

在這種應用體系內；

組織在實踐近一年之後，各種核心的業務流程，都全面的資訊化和數位化管理，並且從應用層面打通了不同業務的互動路徑；

最後，經過對比論證，業務流的「效率」得到極大的提升；

【實踐帶來的反思】

與低程式碼平臺聯絡最密切的一個概念，就是「數位化」；

在資料公司時；

見識到資料層面可以挖掘的價值，智慧化的分析決策流程，但是缺乏應用層面的數位化實踐；

現在的組織中；

強烈的追求業務數位化管理，並且有幸見識到了完整的實踐過程，才最終形成比較清晰的認知；

不得不承認，這是一個普通玩家，「後知後覺」的反思；

反思低程式碼應用；

各廠商基於自身所在的行業，以及技術和產品的實踐經驗，將其封裝在複雜的低程式碼平臺中；

從而提供，各種「相對簡單」的業務流模型搭建；

這樣可以支撐各種業務場景的數位化管理，並且低程式碼搭建的產品，本身具備很強的靈活可變能力，都有助於效率的提升；

在業務完成數位化之後，自然可以提升各個場景的統籌效率；

對於當下最熱門的「AI領域」來說，其依賴「數位化」的基礎，進而推進流程和決策的「智慧化」管理；

反思技術的發展；

以前總覺得，所謂的資訊化、數位化、智慧化「遙不可及」；

但是區區幾年的時間，就已經普及到各行各業；

成為當下最大的熱點；

所以，面對新興事物的時候，快速理解和衡量其價值，確實會給認知層面帶來巨大的差距；

【最後聊幾句問題】

隨著低程式碼應用的普及；

越來越多的業務人員具備「簡單」的開發能力，必然會給部分研發人員的帶來負面影響；

無疑；

加劇網際網路的「內卷」趨勢，本就卷得一塌糊塗的行業，現在更是雪上加霜；

然而趨勢的形成，不會以個人意志為轉移；

就像現在的「AI智慧」一樣，領先的公司不會顧及反對的聲音一路狂奔，落後的公司一邊喊著反對又一邊瘋狂追趕；

真正的趨勢，本著不可逆跟隨就好的心態。