這幾年是低代碼興起和快速發(fā)展的幾年，市面上的低代碼層出不窮，群里幾個大佬也在做低代碼平臺。很多低代碼還處于技術域的討論，除了導致低代碼平臺企業(yè)之間的內卷，對整個低代碼平臺市場的發(fā)展未必是好事。
低代碼開發(fā)平臺
那什么是低代碼呢？實際上回歸到平臺本質，客戶的訴求才是最主要的。最近通過從客戶進行的多次交流來看，客戶關心的問題無非這幾塊？
一是，平臺的價值
以某客戶甲舉例，已經購買了某大廠的低代碼平臺了，發(fā)現(xiàn)效果并不理想。從宏觀的維度來看，并沒有提高研發(fā)效率，起到當初平臺供應商的承諾。微觀上來看，花錢引進的低代碼難用，配置繁瑣，大量復雜的場景還需要高代碼開發(fā)，從研發(fā)人員的角度來看，低代碼平臺簡直是個雞肋，雖然在某些地方確實能起到些作用，但是從整個項目來看，在其它方面反而增加了學習成本，維護成本，升級成本。整體而言，研發(fā)人員并不喜歡用，甚至還抵觸。
客戶乙的訴求是這樣的，客戶乙已經有很多應用再線上運行，新的應用可以采用低代碼開發(fā)，已經建設的應用如何辦，面臨著原有系統(tǒng)如何改造升級？以及改造升級的成本代價多高？
客戶丙呢情況還好，整個公司的項目重新升級再造，計劃采購整套的基礎設施平臺除了低代碼平臺還有別的平臺，這些平臺間如何對接？對接方案和成本又是如何？
客戶丁呢面臨著同樣的困惑，同時還面臨著將來整個公司的技術棧升級演進以及隨著基礎設施的升級，低代碼平臺如何快速升級并且兼容基礎設施的技術升級。當然，客戶的訴求遠遠不止這些，只不過筆者在調研的過程中，感覺這幾個問題，比較典型而已。各位廠商大牛，你們的低代碼平臺具備這樣的能力，是否很好解決了這些問題了呢？
作為一名低代碼平臺的產品經理，我一方面要對市面上低代碼平臺的進行研究，一方面設計的平臺要滿足客戶的訴求，以客戶為中心才是產品成功的關鍵。目前正在研發(fā)的產品也盡力的解決上訴客戶的問題。那什么是我眼中的低代碼呢？目前產品又如何解決這些客戶訴求呢？我認為低代碼平臺應該具備如下核心能力。
首先，低代碼平臺必須得是模型驅動的，模型決定著頁面元素，決定著后端服務接口的定義，數(shù)據的訪問當時，數(shù)據的訪問權限等等，布局決定著頁面元素的擺放，模型 布局＝頁面。
二是，研發(fā)資產的沉淀，研發(fā)資產的定義、沉淀與管理，才能更好的實現(xiàn)研發(fā)資產的復用，達到降本增效的目的。
三是，模型開發(fā)與dsl語言，整個應用應該構建在模型之上，通過腳手架或者底層引擎，實現(xiàn)應用開發(fā)的夸語言性，方便應用的技術棧升級，模型應該具有多版本功能，方便后續(xù)通過金絲雀發(fā)布，實現(xiàn)應用的滾動升級。
四是，平臺的可擴展性與組件模型的定義，組件模型的定義與組件的快速構建，方便實現(xiàn)組件級別的定制化開發(fā)，以滿足原有應用系統(tǒng)的低成本遷移。
低代碼平臺的核心能力，一句話來說，就是如何實現(xiàn)把滿足用戶個性化需求的應用開發(fā)轉化為模型開發(fā)和頁面布局的開發(fā)，把平臺產品的定制化開發(fā)轉化為平臺的組件開發(fā)。從而實現(xiàn)研發(fā)任務的批量開發(fā)模式，借助于devops底層基礎設施的能力，實現(xiàn)一鍵構建，一鍵部署。真正達到從傳統(tǒng)的面向功能的軟件開發(fā)模式轉變?yōu)槊嫦蚩蛻舻目焖匍_發(fā)。
同時，上面這句低代碼平臺的總結，也為低代碼平臺市場從業(yè)者最為迷茫的一個事，低代碼如何運營。
版權聲明：本文內容由互聯(lián)網用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至 舉報，一經查實，本站將立刻刪除。