低程式碼破解了軟體開發“不可能三角”?我做了個測評...

ITPUB社群發表於2022-12-27

作者| Mr.K   編輯| Emma
來源| 技術領導力(ID:jishulingdaoli)

老讀者知道,K哥寫了10幾年程式碼,後來轉做技術管理,現在是上市公司的技術高管。在我們軟體行業有一條鐵律:長週期、大規模的軟體研發過程當中,想要維持良好的運作,需要解決:成本、效能、質量。而且在通常情況下,這三個要素組成了“不可能三角”,即:不能同時做到低成本、高效能、高質量。


低程式碼平臺的出現,卻打破了這條“千古不破”的鐵律。




01

低程式碼為什麼能夠破解“不可能三角”?


K哥算是國內較早一批關注和研究低程式碼的自媒體,可以說見證了整個低程式碼行業從萌芽到成長,再到成熟的過程。根據K哥的觀察,低程式碼發展到現在已經具備了破解軟體“不可能三角”的可能性。


下面K哥分別從成本、效能、質量三方面,來分析低程式碼為什麼能夠破解軟體研發“不可能三角”:


第一,成本,對於軟體研發來說,成本包括人力成本、溝通成本、試錯成本、硬體成本等等。業務人員經過低程式碼培訓,也能具備搭建業務系統的能力,在一定程度上減輕了企業在專業開發人員缺口上的壓力;低程式碼讓業務系統的搭建變得簡單,由3到5人的小團隊配合就能完成,降低了員工之間的溝通成本;低程式碼透過拖拉拽,就能快速生成業務系統,使得試錯成本變得很低,支援了企業敏捷創新的訴求。


第二,效能,是每一位技術管理者特別關注的指標,包括協作效率、工具效率、決策效率等等。低程式碼透過標準化的介面,解決異構系統之間資料互聯互通的問題,提升了協作效率;高度視覺化、模組化、整合化的開發介面,使得軟體研發效率得到提升,從而提高了技術決策的效率。


第三,質量,包括需求質量、程式碼質量、測試質量等等。研發質量的提升非常依賴工具鏈的完備性。根據Gartner技術成熟度曲線,低程式碼已經逐步發展成熟。


低程式碼破解了軟體開發“不可能三角”?我做了個測評...


因此我們可以得出結論:低程式碼平臺已經具備了開發企業級軟體的能力,對於軟體開發過程中的介面除錯、編譯、測試、部署等環節都能夠很好地支援,質量資料監控體系貫穿研發全生命週期,從而提升了研發整體質量。


還記得特斯拉研發團隊25個人4個月開發了第一版ERP的故事嗎?他們採用的就是低程式碼平臺,直接把“不可能三角”砸得稀巴爛,如果用傳統研發模式,這麼小的投入這麼短的時間,恐怕只能完成其中的幾個小模組。




02

優秀的低程式碼平臺,應該具備哪些特性?


近幾年,國內的低程式碼廠商百花齊放,同時也給企業CIO們選型上造成了困擾,下面聊聊,如何識別一個優秀的低程式碼平臺?以及優秀的低程式碼平臺都有哪些特性?


K哥想先透過一個具體業務場景,手把手帶大家來看看低程式碼平臺的實際表現如何?以構建一個“訂單管理系統”為例:


首先,對訂單業務進行資料模型設計,建立各資料表之間的關聯關係。


低程式碼破解了軟體開發“不可能三角”?我做了個測評...


接著,做頁面設計,基於模板倉庫在介面上拖拉拽,完成頁面搭建。


低程式碼破解了軟體開發“不可能三角”?我做了個測評...


然後,進行邏輯設計、流程設計,這部分是系統搭建的核心,需要提前對業務邏輯進行梳理。


低程式碼破解了軟體開發“不可能三角”?我做了個測評...


最後,匯出原始碼,成功部署到私有云環境當中。


低程式碼破解了軟體開發“不可能三角”?我做了個測評...


這就是整個“訂單管理系統”搭建的核心步驟。K哥跟助理2個人花了8小時,成功搭建出了該系統所需要的11個子模組與35個介面。同樣的功能如果用傳統軟體開發模式,按以往開發經驗測算需要5個人日左右,也就是說用了低程式碼,降低開發成本一半以上,開發效率提升50%以上。


在以上例子當中,K哥使用的是網易數帆輕舟低程式碼平臺,下面對整個使用過程做個整體梳理,主要關注端到端軟體研發的6個關鍵節點,也可以為大家在未來選型中提供個參考:


低程式碼破解了軟體開發“不可能三角”?我做了個測評...


在使用低程式碼搭建“訂單管理系統”的過程中,K哥透過拖拉拽,就基本能夠還原出畫素級別的視覺設計稿,這對於前端開發的工作有很大幫助。


在實現訂單處理邏輯的時候,需要用到標準化元件、邏輯元件、流程元件、資料元件等等,在熟悉了低程式碼平臺種類繁多的元件之後,K哥成功實現了所有業務邏輯。


在搭建“使用者登入”和“許可權模組”,我使用自己的LCAP模組,低程式碼平臺相容了很多型別的認證登入系統,方便接入企業的賬戶體系,對接起來非常方便。


在完成“訂單管理系統”搭建之後,K哥使用了平臺提供的原始碼匯出功能,嘗試釋出在幾個主流的雲平臺,以及我自己的私有環境,經過簡單的部署和除錯,系統就正常跑起來了。


K哥還使用第三方程式碼安全掃描工具,對生成的程式碼做了掃描,並未發現有漏洞或安全隱患。


以輕舟低程式碼為代表的低程式碼平臺,在6個維度上看,表現都達到了企業級軟體開發的標準和要求。




03

低程式碼這麼牛,

在企業當中有哪些典型應用場景?


對許多企業CIO來說:不能解決企業實際問題的低程式碼,是無用的低程式碼。下面我們可以嘗試結合企業當中最常見的四組場景,來看看如何選出合適自身的低程式碼。


第一,創新業務

數字化賦予了企業敏捷創新的能力,隨之而來的是大量的業務系統開發需求,而且都要求短期內交付,商業價值也不明確,業務本身的不確定性很強。應對這類需求,低程式碼平臺就有了用武之地。如果創新業務在釘釘生態,可以採用宜搭;如果在微信生態,可以用微搭,如果要求脫離平臺依賴,在獨立的生產環境下執行,則可以採用輕舟低程式碼。


例如:國內某地方銀行引入輕舟低程式碼平臺進行業務系統開發,由於銀行的應用場景比較特殊,對軟體私有化部署、程式碼完全可控、應用安全性等方面有嚴格要求,該地方銀行透過輕舟低程式碼所見即所得的開發方式,快速進行業務創新,開發出幾十個營銷和客戶關懷方面的應用,有效提升客戶服務的滿意度。


第二,元件/服務沉澱及複用

一家公司的IT成熟度,取決於很多因素,模組複用是其中很重要的衡量指標,所以對於業務元件/服務的沉澱及複用是很重要的非業務需求,屬於技術基建類工作。對於這類開發需求,就需要採用具有模型驅動、功能相對成熟的低程式碼平臺,比如像是國外的Mendix、OutSystems,或是我們的國產之光輕舟低程式碼等。


某軟體服務商,透過輕舟低程式碼平臺為甲方客戶快速而且高質量地交付專案,達到了降本增效的目的。而且,在一家客戶中完成專案開發,還可以快速複製到同型別專案當中,推進更多數字化專案的落地。


第三,核心系統擴充套件

企業數字化建設,很重要的一個工作就是構建數字化核心系統,低程式碼適合對核心系統功能做一些擴充套件,根據不同業務場景,選擇不同的解決方案,舉例來說,如果業務場景上偏向表單處理類,那麼適合採用宜搭、氚雲等等。


第四,業務流程自動化

大多數企業首要解決的問題就是業務流程自動化,這也是數字化建設的重要抓手,一是把線下的流程往線上搬,二是把手動的流程自動化,三是把PC端的流程移動化。


以國內某大型證券企業為例,透過採用輕舟低程式碼,加速了業務線上、資料線上的程式,從前大量未被滿足的業務需求、零散需求得到了及時解決。




結束語


小結一下,K哥以搭建一個“訂單管理系統”為例,透過使用輕舟低程式碼平臺完成了整個系統的搭建,並對使用過程進行了測評,最後得出結論:在不依賴專業開發人員的前提下,能夠滿足企業個性化需求、能夠脫離平臺靈活部署、整合化一體化程式碼引擎等特點,有效破解了軟體研發“不可能三角”問題。


不同型別企業在選擇低程式碼平臺的過程中,可根據自身業務特點選擇匹配場景的平臺:


業務場景平臺選型建議
1創新業務場景跟具體平臺繫結的可選擇釘釘搭、微搭
需要獨立制、與平臺脫離依賴的可選擇輕舟低程式碼
2元件/服務複用場景採用成熟度較高的模型驅動的低程式碼平臺,如Mendix、OutSystems、輕舟低程式碼
3核心系統擴充套件場景建議根據邏輯複雜程度選擇不同解決方案。
4業務流程自動化場景業務清晰的採用表單驅動的簡道雲、明道雲
流程相對複雜的場景:採用如輕舟低程式碼在內的模型驅動的低程式碼平臺

最後,K哥想說低程式碼不是銀彈,不能解決企業數字化中的所有問題,企業應該因地制宜,選擇適合自己業務場景的低程式碼平臺,借鑑上述選型思路和應用案例,讓低程式碼真正成為企業數字化轉型的加速器。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024420/viewspace-2929643/,如需轉載,請註明出處,否則將追究法律責任。

相關文章