從2014年Forrester明確提出低代碼的概念以來，經過八年的發展，低代碼領域基本已經有了成熟的發展，而具體到國內市場，低代碼開發自2018年之后就逐漸受到越來越多的關注。尤其2020年疫情之后，已然成為了IT行業一時爆火的風口，同時，對低代碼的爭議也越來越多。

主流的聲音認為，低代碼理論上存在的開發門檻低、易用性等特點，能夠滿足企業在數字化轉型中大量需求，這也是低代碼迅速成為to B風口的一個關鍵因素。但持相反論調的人則聲稱，低代碼是“新瓶裝舊酒”，他們質疑低代碼是偽需求，同時認為低代碼平臺暗藏巨大的變革成本。

本期我們有幸采訪了低代碼方向的專家寧偉老師，一起探討低代碼是什么、低代碼可以解決什么問題、如何組建低代碼開發團隊等問題，理解低代碼的前世今生。

問題1：您好，寧老師！很榮幸有機會采訪到您，先簡單介紹一下您自己！

我叫寧偉，2005年畢業于西安交通大學，隨后加入西安葡萄城。在職業生涯的第一個十年中，我的角色是企業軟件開發人員。我們團隊開發的是在日本私立學校管理系統賽道市占率第一名的LeySer System，這個系統初版發布于1983年，即將迎來40歲生日。我參與了LeySer System軟件8.0到9.0版本的開發，大多數時間專注于開發框架的迭代與維護，也做過服務端通訊、緩存、權限認證等非業務功能和一部分DevOps自動化工具的開發。在LeySer開發團隊的十年中，我親身經歷了產品從局域網到SaaS，再到云加端的部署模式和架構轉型。之后的五年中，我先后以項目經理和產品經理的角色在葡萄城的開發部門中工作。2016年之后，公司在中國的業務中心開始轉向低代碼，在這個背景下，我加入了低代碼產品線，目前主要負責行業研究、生態建設等工作。此外，我以中國信通院低代碼無代碼推進中心技術專家的身份，正在參與中國首部低代碼行業標準的制定，在高校和技術社區講過一些課程，參與出版了一本技術書籍。

問題2：您在18年轉入低代碼領域，是什么契機促使您選擇低代碼這一方向呢？

轉入低代碼行業有兩方面的原因：第一是看好這項技術的發展前景。我始終認為軟件開發工具是一個專業性很強的技術領域，這個領域的進步可以撬動整個軟件行業的發展。這是我從企業軟件線內部轉崗到開發工具線的主要原因。

其次是我所在的平臺，也就是葡萄城的“基因”。葡萄城在1980年開始進入企業軟件開發領域，在自有軟件的開發，也就是我剛才提到的LeySer的時候發現其中很多代碼是可以復用的。于是我們的前輩在1990年將其中的一些類庫抽象出來，做成組件單獨銷售，從此開啟了開發工具產品線，目前類Excel協同辦公開發領域中的SpreadJS、.NET平臺報表控件ActiveReports是其中的代表。基于服務開發團隊的經驗和我們對軟件開發工具的理解，公司在2012年啟動了覆蓋軟件開發全生命周期的可視化開發解決方案的研發，并將其作為公司未來一段時間的主要發展方向。當初還沒有低代碼的說法，直到2014年，低代碼的概念提出后，我們認為即將發布的新產品與這個概念高度匹配，就定下了的“活字格低代碼開發平臺”的名稱。可以說，葡萄城在6年前就確定了在低代碼領域發力的方向。這讓我的轉型之路更加順暢一些。

問題3：您認為低代碼是什么？低代碼可以解決什么問題？

低代碼的概念很寬泛，指的是通過圖形化等手段降低軟件開發編碼量的技術，狹義的低代碼則是將其應用場景限定為完整的應用開發，即使用更少的代碼開發包含有界面、數據模型、業務邏輯、流程和數據服務的完整應用的技術。

回歸本質，低代碼技術的作用是降低軟件開發的技術復雜度。對于很多朋友來說，這個概念可能有些陌生，我來展開講一下。40多年前，有一本講軟件工程的著作，《人月神話》，可以稱得上是我在軟件工程領域的第一個領路人。書中花了很大篇幅在講軟件開發需要解決的復雜度。我們可以將軟件開發的復雜度拆解為業務復雜度和技術復雜度兩種。前者是由業務需求本身決定的，是本質復雜度，不會因為技術的變更而發生變化；后者則是偶然復雜度，可以隨著技術的進步而逐步降低，也有可能因為環境的變化而有所反彈。只要從事軟件開發，業務復雜度都是必須要處理的，沒有任何技術可以幫到你；而技術復雜度卻可以通過引入更高效的開發技術來幫你分擔一些技術復雜度問題，中和甚至超越運行環境帶來的負面作用，從而提升整體開發效率。

在我從事軟件開發行業的十幾年里，軟件的環境變化速度是要高過軟件開發技術的。面向瀏覽器的B/S架構、網絡傳輸受限的移動互聯網、計算能力受限的PDA移動終端，這些技術在提升用戶體驗的同時，也顯著拉高了技術復雜度。最直觀的感受就是2005年，我入行時，以Visual Basic、Visual Studio為代表的可視化開發技術已經普及，幫我們屏蔽了Windows窗體繪制、消息循環等技術復雜度問題，所見即所得的界面開發效率非常高。但是進入2010的Web開發階段后，這種“代碼生成器”思路的可視化開發工具因為數據傳輸量大、解析和運行效率低等問題，無法滿足應用開發所需。我們又不得不回到像Pascal、C的純編碼的時代，重復寫代碼、運行起來看效果、再改代碼的循環。這就是開發技術在與運行環境的拉鋸戰中落敗的表現。進入2020年代，瀏覽器的計算性能和網絡帶寬的緊張程度有所緩解，另一方面，可視化開發技術和與之配套的元數據驅動架構的成熟。兩者的共同作用，孵化出了低代碼。

從目前的實踐上看，低代碼技術在業務復雜度高、系統集成要求多、交付周期要求嚴、預算投入有限，但數據量不大、并發數量不高、界面交互精細化不高的企業軟件領域已經展現出很強的競爭力，比如企業生產相關領域的設備維保、庫存管理；供應鏈領域的物流跟蹤、經銷商采購；客戶服務領域的會員積分、在線工單；財務領域的憑證池、預算查詢等“重業務場景”。這些場景存在的共同點有以下幾個：

1、價值高，IT投入能帶來穩定的收益預期，一把手有足夠的壓力和動力來推進這些領域的信息化；

2、差異化，不同行業、不同企業、不同管理文化甚至一個企業所處的不同階段，這些核心業務都不大一樣，很難通過成品軟件來實現；

3、柔性化，不確定性是這個時代的特點，導致了企業業務難以長期穩定，需要不斷試錯才能找到成長的空間，這就對軟件交付的速度提出了更高的要求，“項目還沒交付，需求已經變化了”的情況是很難被接受的；

這三點讓低代碼開發相較于編碼開發的優勢能得到最充分的展現。事實上，在葡萄城和中國軟件網聯合舉辦的2022企業級低代碼應用大賽中，獲得多位來自中國信通院、CSDN、36氪、西安電子科技大學的專家最多認可的作品大體上都是符合上述三點。

另一方面，對于一些IT投入比較高的企業，也可以用低代碼來解決數據填報、跨系統審批等OA相關的“輕業務場景”，這些場景在成長型企業中通常被IT所忽略。引入低代碼，解決“從無到有”，提升信息化的廣度也是大功一件。

當然，低代碼的局限性也不容易忽視，低代碼開發通過組件化封裝來提升開發效率，必然會犧牲一定的性能和定制化。雖然這兩點在企業軟件中并不是核心競爭力，但在其他領域就不一樣了。所以，我們不推薦將低代碼應用在數據量、并發數和界面交互精細度“卷到天際”的互聯網服務的開發中。

問題4：《低代碼開發實戰》由葡萄城技術團隊編寫，您也是圖書的作者之一。如何組建低代碼開發團隊？低代碼如何與編碼開發相結合？以及如何學習低代碼？

市面上的低代碼產品主要分為兩大類，面向業務開發者的低代碼和面向專業開發者的低代碼。剛才我們提到的低代碼中指的是后者，指的是提供給主要做信息化建設的技術人員的低代碼平臺，如企業內部的IT部門、業務線中負責信息化建設的人員和外部的信息化服務商等。我們公司的活字格產品選擇的就是賦能開發者的路線，也被提出低代碼概念的Forrester在報告中列為該賽道的典型產品。對于這個方向，我的經驗也更豐富一些。

剛才我們講到了企業軟件開發的業務復雜度和技術復雜度。低代碼開發團隊需要面對的就是這兩種復雜度。即便有了低代碼，團隊依然需要獨立解決業務復雜度，通俗的講就是將業務需求翻譯成適合計算機執行的方法。低代碼平臺廠商則通過平臺的內置能力、技術方案和社區資源，承接項目中大部分的技術復雜度。對于復雜一些的項目，依然會有一些技術問題需要開發者借助平臺的開放接口和系統集成機制來實現。這種情況決定了成功的低代碼開發團隊與傳統編碼開發不同。從我們的經驗上看，成功的低代碼開發團隊大多采用“高低搭配”的模式，初級低代碼開發人員占比顯著高于高級低代碼開發人員。

1、高級低代碼開發人員：專注于解決技術復雜度問題，主要職責除了指導和審查初級低代碼開發人員的工作外，還需要解決架構設計、數據庫設計、性能優化、系統集成等技術復雜度問題。招聘時可參照傳統編碼開發的后端程序員，重點關注其架構設計、解決方案設計和數據庫開發能力。

2、初級低代碼開發人員：負責解決業務復雜度問題，主要職責是在高級低代碼開發人員的指導下，完成頁面設計、基礎的業務邏輯設計等工作。實際招聘時，可優先考慮非重點大學的計算機相關專業畢業生；或接受來自運維、實施等團隊的轉崗人員。

低代碼與編碼開發并不是非此即彼的關系，兩者的有機結合才是正解。從我們的經驗上看，大型企業級系統中通常可以選擇兩種低代碼與編碼開發的解決方案：前后端分離和子系統集成。

1、前后端分離：參照編碼開發中的前后端分離方案，使用低代碼平臺，可視化開發后端WebAPI，提供給使用編碼開發的前端頁面（包括網頁、桌面端、APP、小程序等）調用；反之亦然。這種模式主要用在為對現有系統進行重構時的過渡方案，如先沿用現有的前端頁面，使用低代碼開發全新的后端，并基于新的后端延展新的功能模塊，最后再替換掉之前的前端頁面。

2、子系統集成：將系統中的某些模塊采用低代碼開發，另外一些模塊采用編碼開發。兩者通過共享數據庫或WebAPI實現數據交互。這種做法更為常見，通常用于為現有系統擴充新的功能模塊，如為ERP添加供應鏈自助填報等，或者用于解決一些較為復雜的批量數據處理、私有協議的軟硬件集成等場景。值得一提的是，需要將低代碼開發的模塊與私有或特殊協議的軟硬件集成時，可以使用被集成系統的SDK和文檔推薦的技術棧開發一個“橋接程序”，將其能力封裝為WebAPI后提供給低代碼使用。

要想具備以初級低代碼開發人員的身份參與到低代碼開發團隊的能力，低代碼學習的重點可以放在低代碼平臺本身的功能學習上。成熟的低代碼平臺廠商大多提供了完整的學習路徑，包含技能清單、培訓資源和認證考試等。在對軟件開發有基本了解的前提下，沿用廠商的學習路徑通常是最優解。以我們的活字格低代碼開發平臺為例，這一目標對應了學習路徑中的“進階教程”。從經驗上看，學習時間大約需要80小時。

對于高級低代碼開發人員來說，除了上述學習外，還需要使用現有的軟件工程和架構設計培訓資源，掌握相應的技能。這點因為和編碼開發沒有區別，就不再展開了。

問題5：您怎么看待媒體和大V對低代碼的爭議？如何看待無代碼將從低代碼中分離的觀點呢？

作為一項2014年提出的面向企業服務的技術概念，低代碼的發展速度不能說不快。但8年的時間對于一項企業軟件技術來說，依然處在成長和探索的階段。在探索的過程中，擁有不同基因的廠商選擇的方向存在很大的差異性。這導致很長一段時間中，在低代碼的名下雜糅了不同的產品和方案。再加之互聯網投資的推動，市場端能夠聽到、看到的低代碼就更加百花齊放了。面對一個差異化非常大的市場，不同的人注定會有不同的感受。比如程序員看到由互聯網表單工具轉型而來、面向業務人員用于解決簡單業務場景的產品；或沒有IT背景的業務用戶看到由軟件開發控件轉型而來、面向技術人員用于解決復雜業務場景或系統集成的產品。怎么可能不飽受爭議呢？

值得高興的是，低代碼市場從去年開始走向分化。在去年年底，我先后接受了Forrester和中國軟件行業協會的采訪，在溝通中我和兩方的專家老師都能明確的感覺到，國內面向業務開發者的低代碼產品為了彰顯自己的學習門檻更低，正在或即將更名為“無代碼”。這種趨勢發展下去，必然形成業務人員使用無代碼，讓一些簡單的、臨時性的場景，可以不再需要技術人員為其定制開發；另一方面，技術人員則使用低代碼產品，專注于搞定更復雜的、需要長期運行和迭代優化的高價值場景。這樣，兩類用戶各取所需，兩類產品也能專注研發。我相信低代碼技術會更快走向成熟。

問題6：您在低代碼行業有近5年經驗和行業成就，您對低代碼行業從業者是否有一些好的意見和建議？

雖然受到大環境的影響，低代碼的投融資活動在降溫，但我認為低代碼依然處在上升階段。基于十余年的軟件開發經驗和低代碼行業五年的探索，我有以下幾點想法，稱不上建議，權做參考。

1、如果您在低代碼平臺廠商從事產品研發相關工作，建議保持開放的心態，積極引入新的技術和方案，利用他山之石快速擴充自身的產品能力；

2、如果您已經是低代碼平臺的用戶，即低代碼開發者，請密切關注來自廠商的培訓資源。低代碼產品的迭代速度很快，緊跟廠商的“最佳實踐”才能做到事半功倍；

3、如果您在傳統開發團隊中從事編碼開發，但希望通過轉型為全棧開發者，獨立承接項目，可以提前學習支持前后端分離的低代碼開發平臺，按照“一專多能”的方式，用低代碼快速補全短板，承接更高價值的項目；

4、如果您在企業或信息化服務商中負責技術選型和決策，建議提前了解低代碼的特點和應用邊界，將面向技術人員的低代碼平臺作為選項之一，找到合適的項目，大幅提升團隊的產出效率。即便不將低代碼作為首選，至少可以把低代碼作為“最后一線”方案，在編碼開發的成本和交期無法滿足的時候，集中精銳力量，拿起低代碼的武器，再戰一程；

5、如果您是關注企業信息化領域的媒體或投資人，建議全面了解低代碼領域，理清低代碼與無代碼的異同后再下結論。否則，低代碼的兩面性很容易給你帶來誤解，以至于錯過了很好的機遇；