【51CTO.com原創稿件】從2020年開始，低代碼成為了業界熱點，無論是資本市場還是企業用戶都紛紛追捧。在低代碼洪流下，支持和反對聲并存，有人認為低代碼可以像Office一樣達到全民普及，也有人認為低代碼是新瓶裝舊酒炒作概念。在爭議不休下，如何正確地看清、認清低代碼?如何清晰地辨別并選擇適合自己企業的低代碼開發工具和平臺

為此，51CTO特別梳理了關于低代碼的十大問題，并邀請騰訊云、網易數帆、用友、微軟等不同低代碼平臺服務提供商的專家共同探討，視圖解答業界關于低代碼的相關疑問。

以下內容是來自微軟(中國)有限公司全渠道事業部，創新技術總經理崔宏禹的解答!

問題一：低代碼真的是新瓶裝舊酒么?

任何技術的興起、流行或者消失，不僅取決于技術本身，更取決于現實的需求。低代碼技術之所以在這個時候重新發揚光大，有兩個方面的原因。一方面，相關技術發展到一定程度，使原來不可能的事情成為可能，比如人工智能已經在一些專業領域達到或超過人類水平，決定性因素是市場對更高生產力工具的追求;另外一個方面，生產力工具在不同時代有不同的特征。在數字化時代，通過軟件手段開發出的各種生產力應用成為人類提高工作和生活效率的主要手段。這種時代的變化要求各行各業的從業人員具備基本的應用開發能力，這是低代碼帶來的主要改變，即可以讓非專業的開發人員通過低代碼技術來實現其業務上的述求和能力的構建。當然，低代碼技術的目的并不是把這些人培養成專業程序員，而是借助這種能力來提高自己的工作效率。所以，低代碼能力是一種未來我們必須掌握的‘辦公能力’,是能夠發揮所有業務參與者能力的“新瓶新酒”。

問題二：低代碼開發就像是拼搭樂高積木?

我們經常會用這樣的比喻，幫助大家對低代碼開發有更直觀的印象。從一定程度上來講，拼搭樂高積木的過程和低代碼開發的過程很類似，都是通過簡單的模塊化構建的方法，逐步搭建復雜的作品或方案。當然，它既遵循一定的規律或規則，又鼓勵大家在既定的模板之上發揮各自天馬行空的創意和想法。因此用拼搭積木來形容低代碼開發的過程，還是比較恰當的。不過，如搭樂高積木需要一張圖紙和模板一樣，在開始之前，一定是有一些基礎的服務能力的，例如，必須具備通用的數據服務能力，和其他應用系統的接口能力等。這些能力一定是由專業的開發人員預先定義好的。

問題三：低代碼適合開發哪些應用?

低代碼適合開發的應用本質上沒有限制。我們希望未來的應用都是可以通過低代碼平臺來開發實現的。但就目前我們看到的客戶和伙伴的應用場景來講，內部IT、財務、人力資源等部門都是低代碼應用需求的聚集地。一方面，這些部門本身有厚重的系統支持，但希望能夠快速實現定制化需求和迭代新場景，這正好是低代碼最擅長的事情;另一方面，很多部門的員工有想法，但苦于沒有IT背景和基礎的編程技能，只能寄希望于低代碼平臺，來實現他們的需求。這都加速了低代碼應用在這些領域的開花結果。這類低代碼應用我們統稱為“內部運營效率應用”。

同時，我們可以看到，低代碼在下面一些場景也是非常受歡迎的：

1、 需要快速迭代的創新型應用

2、 客戶對需求的變更要求較高，從而由客戶參與的應用項目;

傳統系統或遺留系統的升級改造。

問題四：低代碼不適合開發哪些應用?

目前低代碼平臺的模板，生態，和可拓展性有還在發展階段，更多旨在解決最后一公里的問題。如果想要從頭開發復雜厚重的業務系統，還存在一定的困難。如基于CRM系統開發移動端應用，實現定制化的需求，對于低代碼平臺并不難。但從頭開發一個完整的CRM系統，還是充滿挑戰的。

同時，有大量的底層開發能力要求的應用，尤其是和設備、接口、驅動交互相關的項目，低代碼因其本身的場景和具備的能力，也是不太適合。

問題五：低代碼和零代碼的區別?

低代碼和零代碼沒有本質區別，都是不斷提高生產力的工具，是一種APaaS(Application Platform as a Service，應用程序平臺即服務)。APaaS平臺最大的優點是提供了快速開發的環境，個人或企業無需購買和維護服務器、中間件、網絡等一系列技術基礎設施。APaaS平臺準備好了這一切，個人或者企業可以在幾個小時內就能完成應用的開發、測試、部署，并能夠隨時調整或更新。就現階段而言，零代碼平臺對老板、產品經理、銷售、運營等人員更友好;而低代碼可能更適合懂點代碼的人員使用。但是，低代碼與零代碼平臺有逐漸融合的趨勢，低代碼平臺一直在不斷降低使用者門檻，兩者未來會越來越相似。

問題六：低代碼開發能否讓程序員失業?

這看起來是非程序員而不是程序員最關心的一個話題或者想法。本身作為曾經的程序員，在剛接觸低代碼這個概念時并沒有太擔心低代碼會取代什么，但也確實聽到了很多的聲音在討論這個事情。我個人的一點感悟是，其實低代碼的出現，解放了程序員的時間，反倒讓程序員能夠將更多的時間專注在解決復雜業務問題，編寫高質量的代碼，優化平臺架構，提升產品質量等一系列專業的事情中。每一行業都有其特殊性，每一個職位都有其專業的地方，低代碼中的低字，并不是說從此以后，就不用寫代碼了，而是說未來，解決業務問題的成本變得更低。低代碼出現后，其實打通了業務人員與IT人員以及專業程序員之間的一個屏障，業務人員可以利用低代碼工具將自己的想法變成現實，拖拖拽拽地就實現了，但每一個拖拽的組件，都是程序員通過專業知識打造出來的。所以我個人覺得，低代碼平臺會讓程序員所做的事情，更有價值，更體現專業性。

問題七：低代碼能否走向“公民化”?

其實 “公民化” 這個詞，或者說 “Citizen Developer”，我一直覺得特別抽象，其實更應該說是 “Digital Innovator”。最近五年，數字化、移動化、智能化的發展，要遠比過去十年、二十年要來的快，當下很多的平臺、產品、消費習慣、業務模式，放在五年前，十年前都覺得不太現實，就像現在出門我最擔心的是手機沒電，而不是沒帶錢包。低代碼在這個時候出現，如果能夠得到善用，確實能夠群策群力，解決以前需要3個月、6個月，要找專業供應商才能解決的問題。就比如以前要從手機上查系統里的產品型號，整理成BOM發給客戶，又要開發移動APP，還得考慮iOS還是Android，還要寫接口、匹配不同的設備型號、分辨率等，很麻煩，所以很多時候想想也就算了，就手工搞吧，也不是搞不定，訂單也不多。就是這類看似不難，當前也能對付，投入成本高的需求，在企業中有很多，不斷得對付著，終究一天會發現，企業如果生意機會暴增，但卻沒有能力處理這類需求。低代碼的出現，就提供了一個很好的平臺，不是說一定讓每個人都去開發，而是說當業務專家有個想法，就可以立馬上手實現的，于個人、于公司，都是好事。

問題八：低代碼安全嗎?

低代碼作為一個開發平臺，和其他的開發平臺一樣，并不因為其引入“公民開發”的概念而降低了安全性。一方面，低代碼平臺一般在企業安全的 DMZ 或安全的云平臺中建立，并且必須毫不費力地通過網絡安全許可來實現對代碼和數據的訪問，可以共享整個企業的安全策略，因此，平臺層面的安全是有保障的;另一方面，低代碼平臺一般是自動生成的代碼以及開發人員編寫的自定義代碼實施最佳的編程實踐(編碼約定，設計模式和數據加密)，簡化與現有 CI/CD 流程和工具的集成，因此，也是能保證低代碼平臺的安全。

問題九：如何選擇低代碼平臺?

數字化轉型已經成為企業間的共識，但是轉型之路上充滿了挑戰，比如不斷涌現的創新型業務需求、信息孤島、切換成本、IT和技術人才缺口等等。在眾多的數字化轉型的實施方案中，低代碼平臺因其‘全民開發’理念成為首選。在現階段，企業可以從快速落地的業務場景出發進行思考，適合低代碼的典型應用場景可以分為以下類型：創新型應用、客戶參與型應用、內部運行效率型應用、遺漏系統的遷移或者升級。以客戶參與型應用為例，主要是應用系統建設過程中，要針對客戶業務多樣化需求進行開發的應用，或者客戶根據自己的業務需求，基于某一個平臺自行開發并提供給其它客戶使用的應用;其主要包括的3個場景分類為：基于Web的門戶網站，移動為先的供應商應用，新的SaaS應用。

問題十：低代碼是開源的好?還是商用的好?

在開源與商用的對比上，其實代碼還是低代碼面臨著同樣的問題。很多開源軟件都會有商用版本，目的是企業在出現問題時的一個保障。軟件圍繞著商用軟件，開源盛行，商用再起不斷地循環，誰也不能站出來給一個明確的答案是誰好誰不好。分享一點自己的感悟：首先，開源的功勞肯定是被認可和肯定的，開源的軟件要么是民間的智慧聚在一起解決一個軟件領域的實際問題，比如OpenStack，要么技術巨頭捐贈出來造福人類，比如 Kubernetes。開源的宗旨一直是希望讓大眾能夠享有技術紅利，避免重復造輪子，提升技術上的創新，減少大企業的壟斷。但開源也同樣面臨著一些問題，每一個問題的解決都是義務的，開發項目中的開發人員被成為 Contributor，是因為他們沒有因為寫這個代碼拿到一分錢，所以很多需求的實現，Bug的修改都是需要時間的。所以，如果企業有技術資源和技術能力，利用開源軟件時能夠自己去優化，去解決遇到的問題，改代碼，那開源軟件確實實用;但也有很多企業，其核心競爭力是產品，而不是基礎設施中用到的軟件，可能商業軟件會更適合一些。

 了解更多低代碼開發的詳細內容，請查看《低代碼開發江湖混戰，企業該如何正確選擇》選題。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】