關于低代碼的幾個誤區

關于低代碼的幾個誤區

誤區一：低代碼技術是近幾年才出現的技術。

實際上低代碼技術從上個世紀80年代就開始出現了。當時的低代碼技術是以CASE（即計算機軟件工程）面貌出現的，CASE技術的理念是：集成一套實現方法和相關工具，實現系統分析、設計、代碼生成、系統維護的IT系統全生命周期的方法，關注業務流程、業務對象、業務規則的描述和管理，80%以上的代碼自動生成。那個時候典型的CASE產品包括：Oracle CASEDesigner、GeneXus等。

隨后低代碼技術便經歷了CASE->RAD（快速應用開發平臺）->LowCode（低代碼技術）->MXDP（多體驗低代碼開發平臺）的演變過程。目前國際上最受關注的低代碼技術是MXDP技術，這是一種開發工具，主要用于幫助開發者以更高的效率、更快的速度，開發出跨平臺的軟件系統。現實中，MXDP不僅是前端的開發工具，為了提升開發效率，通常還會提供后端到前端（BFF）集成套件，一站式完成系統開發工作。與傳統的LowCode技術相比，MXDP更專注于為前端提供跨平臺特性，同時在前后端自由定制方面提出了更高的要求。典型的MXDP產品有：Outsystems、Mendix、SAP、GeneXus等。

誤區二：低代碼平臺是前端框架的拓展。

從前一個話題的討論我們知道：低代碼技術關注的是整個軟件應用的快速自動生成，而前端開發僅僅是軟件的一個有機組成部分。合格的低代碼平臺不僅僅能夠解決前端應用的快速開發，更需要解決應用中的復雜業務模型的定義、前后端集成、與第三方系統的集成、系統整體運行效率、應用跨平臺運行等問題。

誤區三：低代碼平臺只能開發簡單應用。

我們知道低代碼技術的理念是通過系統分析、可視化設計、代碼自動生成技術來實現各種不同軟件應用的快速開發，這里的軟件應用從來不限于簡單應用。為此無數IT精英不斷奮斗了幾十年，并將繼續為此奮斗下去。著名的多體驗低代平臺GeneXus從事低代碼技術的研發已經超過了30年。也許正是由于她的簡單拖拽和配置就能夠迅速生成各種簡單的應用并使得國民參與編程成為可能，才造成了低代碼平臺只能開發簡單應用的錯覺。從另外一個角度說，那些只能開發簡單應用的“低代碼平臺”不能算作真正的低代碼平臺，建議客戶在選型時擦亮眼睛。

誤區四：低代碼平臺沒有BUGS。

誠然由于機器自動生成代碼機制在一定程度上避免了一直困擾傳統開發人員所犯得低級錯誤引起的BUGS，使得軟件質量得到了較大的提升。但是，我們知道低代碼平臺本身也是由軟件開發人員采用傳統開發技術編寫的，因此平臺本身的代碼質量無法避免認為錯誤帶來的BUGS，平臺需要大量的驗證和完善以使平臺逐步成熟。另外，在使用平臺進行可視化建模過程中也會存在操作不規范，違反或超出平臺約定和控制邊界的情況。這就需要平臺具有一定的智能性，包括提醒、自動修復、優化等功能，這樣才能夠保證所生成的應用在業務處理邏輯和系統運行效率等方面達到設計目標。

合格的低代碼平臺應該能夠在保障平臺本身代碼質量及生成應用的代碼質量兩個層面進行予以最大重視和保證。并且能夠提供各種手段來幫助平臺使用者控制軟件質量。例如：只能分析提醒引擎、模型分析報告、模型及代碼級運行調試-（Debuger）、網絡運行安全分析工具等。例如：GeneXus除了提供上述輔助工具外，還提供了支持DevOps的CI/CD自動化流程、知識矩陣、自動化測試集成等工具。Mendix在平臺上提供了能夠支持敏捷團隊開發的項目管理功能。

誤區五：全民編程。

低代碼技術的火熱也將一個新術語引入了大眾的視野：“國民編程/全民編程”，網絡上有關“國民編程/全民編程”話題的討論非常熱鬧。這種火熱也難免給廣大“吃瓜群眾”帶入一種誤區：有了低代碼平臺普通人都能夠參與軟件的開發，今后專業的軟件開發人員了。利用低代碼平臺，普通人員可以參與軟件的開發這一事實的確存在，尤其是那些簡單的審批流程應用、數據收集類應用等非常適合相關領域的業務人員直接參與開發。由于業務人員對于需求的理解最直接，他們的直接參與消除了費時的將業務語言向IT語言轉換的步驟，應用上線的周期大大縮短。

除了上述簡單應用外，企業還存在大量的復雜核心應用，這些應用的流程環節更長、業務規則更復雜、需要更多的跨部門的協同。針對這些應用的開發需要頂層設計、對全局業務的理解和把控和系統化與專業化的實現方法。我們知道業務人員由于其所處的崗位限制，他們對自己所直接關聯的局部業務領域（也稱流程片段）非常熟悉，但他們對于全局的了解是有很大的缺陷。因此這類應用的開發并不適合業務人員的直接參與開發，他們的最佳角色應該是“產品經理”。

誤區六：軟件公司不需要使用低代碼平臺。

由于擔心受低代碼平臺技術的限制而無法滿足客戶的定制化開發要求，同時也受到技術人員對于低代碼技術的偏見帶來的抵制，軟件公司對于低代碼技術往往采取忽視的態度。

但在IT技術飛速發展的今天，各種新技術、新理念層出不窮。軟件公司要想跟上IT技術發展的步伐就必須維持一個擁有各種專業人才的龐大團隊，這會給企業帶來巨大的管理負擔和運營成本。特別是那些應用類軟件開發商來說，能夠低成本、高質量、快速交付是公司所追求的首要目標。這些公司希望不必花大量的投入在新技術研發上面，但是同時又希望能夠低成本、快速利用各種新技術。這樣才能夠使的公司在日益激烈的競爭環境中占得先機。因此，軟件公司（尤其是應用類軟件公司）對于低代碼平臺也是有很多需求的。軟件公司在選擇低代碼平臺時，建議選擇那些綜合實力強、面向專業開發人員、采用代碼生成技術的平臺。特別是那些能夠持續提供FutureProof保障的平臺商，因為這將是軟件公司在未來激烈市場競爭中低成本獲取技術優勢的保障。而基于云架構的低代碼平臺可能不是軟件公司的選擇。

誤區七：低代碼平臺會降低專業開發人員的作用。

低代碼平臺利用自動化編程技術實現了很多傳統程序員的重復、繁瑣的手工編碼工作，這不免使得許多專業開發人員認為低代碼技術會降低其作用，甚至擔心低代碼技術會取代程序員的地位。

實際上這種擔心是沒有必要的。我們知道任何一個軟件都是先從業務語言轉換成IT語言，然后又通過架構設計、系統詳細設計變成指導程序員進行開發的語言，最終通過程序員的勞動變成真正的軟件這樣一個過程。其中前兩個環節是軟件是否滿足客戶業務需求的關鍵環節，如果需求理解錯誤或系統設計不當，即使代碼水平再高也不是客戶所期望的。因此一個好的開發人員除了應該關注IT技術本身外，更應該關注對于業務的理解和對系統整體架構的把握，這樣他才能夠走得更遠，有更好的發展前景。

反觀低代碼平臺都是基于可視化模型驅動的開發方法，這種可視化的技術特別適合于與最終客戶的業務專家進行業務溝通和設計。掌握好低代碼技術對于開發人員來說是另一種能力的提升，并且是更高層次的提升。

誤區八：低代碼平臺只能運行在“云端”。

隨著互聯網頭部企業加入低代碼市場的競爭使得低代碼市場處于白熱化狀態，互聯網公司基于其云架構特點在產品宣傳中不遺余力地鼓吹基于云架構低代碼平臺的好處，似乎低代碼平臺只能在云端運行。誠然“云端”有很多優勢，例如：入門快、啟動投資小、免運維等。這使得那些審批流應用、信息收集、信息維護等軟件生命周期短的簡單應用非常適合運行在“云端”。

但是企業中還存在大量的業務流程長、業務規則復雜、運行環境復雜、軟件生命周期長的復雜核心應用，這些應用很難在一個技術架構共享的公有云環境中很好的運行。首先，承載企業價值鏈的核心應用必須能夠有效地支撐企業核心業務的有機運營。體現企業靈魂和競爭力的不是企業所擁有的設備或廠房，而是其端到端的流程體系。云平臺很難同時滿足所有企業客戶構建個性化流程體系的要求；其次，核心應用承載企業的核心敏感業務數據同時在運行時需要與其它相關業務系統進行頻繁的實時交互。很難相關企業愿意將這些核心應用放到公有云上運行；再者，在IT技術飛速發展的今天，新技術不斷涌現，任何技術落后的軟件都會失去競爭力。云平臺商很難在保證平臺上所有應用的運行不受影響的同時無縫地引入所必須的新技術；最后是平臺商的存活期，任何企業客戶都不愿看到由于平臺商的消失而使得其核心業務無法正常運營。因此，這時企業需要能夠生產源代碼、并提供私有化部署能力的低代碼平臺來開發與運維其核心應用。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。