所謂低代碼開發平臺，是指無需編碼或者僅需少量編碼即可快速生成應用程序的開發平臺。這里的應用在目前的語境下一般是指企業應用，如OA、ERP、CRM、HRM、SCM等。此類平臺的特點在于，允許終端用戶使用易于理解的可視化工具建模即可開發自己的應用，而不是傳統的編寫代碼的方式。對于企業而言，低代碼平臺作為一種新型的開發工具，不僅可以降低IT團隊培訓、技術部署的初始成本，還可以簡化開發過程，縮短開發周期，提高開發效率，節省開發成本。而國內隨著最近一系列的針對低代碼平臺的投資事件，此類平臺也逐漸引起了更多的關注。
其實低代碼平臺并不是一項新的技術，相關的技術理念和產品實踐的歷史可以回溯到十幾年前。但是從那時候就遺留了一個一直困擾低代碼平臺開發者的問題就是：低代碼平臺神奇的二次開發工具的用戶到底是誰？
為什么這會成為一個問題呢？我們知道即便到現在，多數企業應用都免不了有一定的二次開發，以適應企業特有的管理模式和偏好。低代碼平臺出現初衷就在于，開發這些平臺的程序員們期望這種單件定制的二次開發可以規避；如果不能完全避免，至少相關的工作量能減少，或者把這個工作從自己的身上拿開。于是乎，就設想了這么一個不需要編碼或者僅需少數編碼即可實現定制化的技術理念。但是任何理念都是要落地，如果假設這個二次開發者是用戶企業的人，那是是業務主管還是信息部人員？前者顯然對業務模型更加熟悉，也是多數需求變更的始作俑者，似乎是最好的選擇。但是業務主管們一般缺乏編程的基本知識，所以程序員們一開始試圖把二次開發工具以一種非程序員即可理解的方式來展現和交互。這個想法其實很早就碰壁了：主管們知道業務，不等于其具有業務的建模能力。主管們覺得自己是個業務經理不應該過多碰觸一個工具系統的開發，哪怕只是一些配置。業務模型自身的復雜性和一些常人未必理解的軟件建模習慣，導致配置界面其實無論如何也難以成為一種無需說明書的自解釋的工具。所以，這個一開始的設想被實踐證明是帶有相當的一廂情愿的成分。
要回答好這個問題，還是要回到初心。我們期望二次開發難度降低、速度加快，這些其實并不意味著要甩給日常使用者。留給原本負責二次開發和部署的研發人員其實更合適。誰呢？這其中包含兩類：一類是來自用戶企業的信息化人員，一類是平臺供應商的交付人員。這兩類人的共性在于，具有對業務模型的基本理解和初步開發能力。有的低代碼平臺公司甚至為此類人員設立了一個專門的崗位：客戶成功經理。而在用戶企業中，這個除了信息部的人員，偶爾也會是業務部門的某個干預嘗試的員工，而這個員工一般并不是業務主管本人。
所以說，低代碼平臺的二次開發工具的用戶仍然是開發者，目的是提高交付速度和質量。只不過，此時的開發者主要是承擔交付階段工作的開發者。因為低代碼平臺的能力使得交付階段開發者和河西階段開發者之間可以進行分離而由不同的人來承擔而已，即交付階段開發者不在依賴于代碼編寫，從而有了“人人都可以是開發者”的說法，但是我們必須要明白“二次開發者仍然是開發者”這一點，否則在開發一個低代碼平臺的時候就會出現以這樣的偏差：花費不必要的資源去把復雜的模型簡化為非開發者能理解的操作，而這么做或者因為問題本身的復雜性而失敗的概率非常大，或者即便做得不錯也不會被用戶采納（因為普通用戶就不認為自己該有這份工作：我花錢給你本來就是期望你給我一個開箱即用的系統，結果你開完箱還要我看說明書鼓搗那么多？），更或者，實際上即便做了出來且用戶和喜歡使用，是不是也會因此喪失了從二次開發中獲得更多商業利益的機會呢？只能說，慎之！在企業應用中，過度的產品化有時候并不見得是一件好事。
有一句話叫做：太陽底下沒有新鮮事。其實類似的場景早就出現在其他領域，比如工業控制領域的組態軟件。是的，沒錯，這其實完全可以看做是控制系統的低代碼開發平臺，而且已經有30多年的歷史了！組態軟件讓一般的控制工程師，你可以理解為控制系統的交付工程師，不用一行代碼就能實現一個復雜的生產線的管理和調度，但是，自控工程師沒做一個畫面的幾件工資，我記得前幾年是每個畫面500到1000元。這些工程師在使用組態軟件之前，也是需要應該的培訓的。沒錯，是培訓！能自學WinCC的已經被很多同行當做“技術大牛”了。當然如果不用組態軟件而采用C 來編程實現，這個效率至少差2~3個數量級了。所以，您還認為低代碼平臺就應該是完全的非技術性人員使用么？
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。