軟件行業的開發效率正在迎來質的提升。

一個明顯的趨勢是，越來越多的企業開始認識到數字化生產方式給企業帶來的創新活力和效率增長，尤其是擁有龐大科技團隊的大型企業和互聯網公司。

他們在中國企業加速駛入數字化轉型深水區的過程里，既是打頭陣的先行者，也是最核心的戰斗力。

如IDC在《2020數字化轉型2．0》報告中所說，無處不在的AI，云與邊緣的融合，解決方案的自動化等關鍵驅動力，很可能成為企業數字化轉型中的重要加速器。

而我也在最近觀察到這些驅動力在數字時代的輕盈落地，就「解決方案的自動化」這一點而言，國內已經有企業研發出「全自動軟件工程平臺」，只要輸入需求流程圖，不需要敲寫一行代碼平臺，就可以自動開發并完成測試，還有自動運維支撐等全鏈條服務。

從目前的研發深度來看，軟件開發行業將迎來巨變。

我們先不去討論一個全面的自動化，或者零人工有沒有可能，從這幾年的浪潮來看，從微軟等企業布局低代碼開始，人人都是開發者的時代已然到來，但低代碼的發展還在初期，目前架構也不夠成熟，不能滿足大型企業復雜多元，以及流程鏈條化的業務需求。

簡單而言，低代碼的模塊拖拉，還停留在前端界面設計階段，后端的全自動開發問題，始終沒有被放到臺前討論。這才是軟件開發效率能否提升的破發點。

而當全自動軟件開發成為可能時，后端大刀闊斧的改革才真正被聚光燈照見。

01

一個神奇的流程圖

盡管企業端對使用順滑、流程合理的軟件有大量需求，但行業的痛點明顯。艾瑞咨詢《中國軟件開發行業研究報告2020》指出，項目開發成本高、開發周期長、代碼質量低、團隊管理難幾乎是長期困擾需求者的問題。

行業不是沒做過努力。這幾年，以開發為切入口，涌現了一批布局低代碼業務的公司，試圖通過減少傳統應用程序的代碼編寫數量，運用圖形化界面拖拽，來讓更多非IT的業務人員，直接上手參與流程優化。

起點是在2018年。

那一年，OutSystems和Mendix兩家獨角獸，直接引爆了資本市場對低代碼平臺的關注。OutSystems隨即得到私募股權機構KKR和高盛共同投資的3．6億美金。而后，德國工業巨頭西門子也宣布進入低代碼開發平臺市場，用6億歐元買了Mendix。

OutSystems和Mendix還不是棋局上最大的玩家。

2019年，Salesforce和微軟正式進入低代碼領域，前者依靠低代碼開發模式為自身的CRM應用打造PaaS平臺，后者設計了低代碼開發組件Power Apps，并想要這個組件內嵌到Office辦公套件里，讓其自身的企業端軟件形成一個生態。

我和幾個做程序員的朋友曾經親測過微軟的Power Apps。發現他們目前能執行的是一些比較簡單的功能，比如銷售數據的滾動統計、年復合增長率、訂單生成處理。

就拿訂單處理來說，大概只能停留在訂單自動下達到倉庫這一步。如果復雜到訂單生成后，這批貨物需要從俄羅斯運送至歐洲盧森堡中轉，最終抵達美國顧客手里，這中間涉及到不同國家之間最優惠的物流路線和商品稅計算，低代碼就很難做到了。

說白了，這是企業核心業務自身的復雜性導致的。而低代碼雖然解決了一部分開發效率低的問題，但只是局限于前端展現層的拖拽操作，沒有針對后端開發進行真正的改革創新。

對企業來說，這種步伐的邁進還遠遠不夠。

而最近釋放出來的消息是，國內已經有企業在后端實現了破局。只要輸入需求流程圖，平臺就能自動實現軟件的開發、測試和運維。在剛剛結束的發布會上，一套研發多年的「飛算全自動軟件工程平臺」全球首發。

飛算云智總裁陳定瑋在發布會上介紹產品

在發布會現場PK賽上發現，使用該平臺做「運動計時」同一項目開發，一個普通的IT工程師只需要輸入流程圖，不敲一行代碼就實現了后端開發。而僅僅28分鐘之后，他就完成了3個資深IT工程師近2個小時的開發工作。

從輸入流程圖的角度來看，飛算全自動軟件工程平臺也在做可視化。但與市面上同類工具不同的是，飛算全自動軟件工程平臺，能提供后端微服務開發。

后端微服務的邏輯就要依靠平臺組件，即通用的技術功能模塊。它們能支持循環、條件判斷、函數調用，通過拖拉拽的方式以及參數配置實現等同編寫復雜代碼的業務邏輯。這就是全自動開發功能實現的基礎。

換句話說，實際上你繪制流程圖的過程就是微服務（復雜代碼業務邏輯）開發的過程。圖形化的流程圖多清楚，哪里不會畫哪里。

這樣一來，項目管理上也輕松了許多。你可以減少之前繁復過多的層級溝通，從項目經理到產品經理，部分架構師可以直接完成項目的計劃和設計，也不用RD工程師做任務分解。如此操作，溝通效率客觀上提高了不少。

自此，只需要通過一個的神奇流程圖，就可以在平臺上實現全自動開發，項目管理、自動化測試、和自動化運維的全部功能。

02

開發的全周期覆蓋

當然，可視化的流程圖，還只是飛算全自動軟件工程平臺的創新表現之一。從開發到測試，再到后期運維，平臺實際上形成了從前期到后期的高度統籌，這種全周期覆蓋的管理能力。

一個常見的誤區是，行業的開發提升大多注重功能的新增和優化，而忽視了從產品設計開發、測試到交付、運營等全生命周期的質化提升。

而全周期、全鏈條的能力之所以重要，是因為開發一套互聯網技術的微服務架構體系，本來就是一環套一環，哪個環節都不能出錯，不然就算代碼寫出來了，這套服務軟件最后也沒法用。

這主要是在于軟件工程行業多依靠「人治」，程序員個人或團隊在其中發揮的作用遠遠超過了系統、代碼等規定和流程的標準化作用機制。

舉例而言，傳統的代碼編寫工作還是采用二進制的文本邏輯。一不小心，如果少了個逗號或者逗號前面出現了空格，又或者全角符和半角符沒有統一，那整段代碼在測試時可能全崩了。每個程序員寫代碼的習慣和邏輯也不盡相同，負責測試的工程師可能要在成千上萬頁的代碼里找出這個小錯誤，耗時耗力可想而知。

但如果是在飛算全自動軟件工程平臺上，這種失誤就會很大程度上地避免。首先自動生成的后端開發會比人工代碼更加精準，遵循代碼規范，可讀性、可維護性也較高。其次，平臺的自動化測試功能通過測試用例跟蹤，可進行接口測試、性能測試等來讓這套代碼運行起來時盡可能穩定順暢。

而在自動化運維功能模塊里，平臺的自帶服務，注冊中心，分布式鏈路追蹤，服務發現，服務治理等環節，也可以保障新代碼push之后的順利運行。

自動化項目管理、自動化開發、自動化的測試和運維，這四項核心功能的實現，實際上標志著行業從「人治」到「法治」的階段躍升。

飛算云智總裁陳定瑋認為，盡管軟件行業的發展積累大量可行的實操方式和可行制度，但人的個性化導致了制度落地執行時差異很大。一旦出現一個有效的工具能將這些管理制度自動落實到位，由于人的個性化導致的一系列問題如招聘難、培養難、留人難、技術沉淀難等，就能迎刃而解 。

目前，飛算全自動軟件工程平臺在“項目管理”、“自動化開發”、“自動化測試”、“質量管理”、“自動化運維”等核心板塊，涉及150多個流程節點的問題上，都能夠形成自動化和有效開發，行業痛點的化解也因此水到渠成。

當然，標準化、自動化的開發系統也并非完全杜絕了個性化、創造力的可能。比如，關鍵崗位的招聘、留人難，行業的技術沉淀，就是之前的一個遺留問題。

飛算全自動軟件工程平臺的解決方式是，引入了眾創中心，像社區一樣讓工程師們集聚在一起。IT狂人們在眾創中心根據自身經驗提供封裝組件，大家的經驗一起在這個平臺上沉淀，不僅能夠讓使用者快速開發和使用，也能集眾人智慧，讓開發出的軟件形成更穩定的質量和安全體系。

03

行業效能的天際飛躍

我們回頭來看飛算全自動軟件工程平臺的價值，為什么從發布之后就引來了巨大關注。

國際歐亞科學院院士、國際歐亞科學院中國中心副主席張景安院士期待，這種中國原創、擁有自主知識產權的平臺的出現，可以為國民經濟、制造業、產業轉型升級、智能制造和人工智能的高質量發展作出新的貢獻。

而中國工程院院士倪光南也在視頻中指出，「如果通過實踐驗證，這個平臺對軟件行業的發展將很有意義」。

從信息技術研究和顧問公司Gartner，2019年向來自全球89個國家范圍內的3000多名首席信息官的調查來看，通常企業內的IT需求一定會大于IT人力的負荷量。當時，這些首席信息官就曾預測，在數字化浪潮里，2019年全球IT預算將增長2．9％，而亞太地區的增長，有可能達到3．5％。

隨著企業數字化轉型的不斷深化，以及消費者對數字化的需求，這個市場增長還在不斷擴大。但企業的成本的確是在逐年走高。

但飛算全自動軟件工程平臺無論是項目成本還是開發效率，代碼質量還是團隊管理和穩定性，都讓行業效能得到了飛躍天際線的提升。

我們來舉個例子。

如果有個科技公司，想要開發一套互聯網技術的微服務架構體系，包括前端系統體系、業務系統體系和大數據體系等，且需版本高頻率迭代。需要多大的人力和物力呢？

首先，IT團隊要做需求分析，系統架構設計，微服務開發、系統測試和運維保障系統。其中光是微服務開發就包括：前端界面開發、技術服務支撐系統開發、業務系統開發、人工智能分析系統開發、大數據系統開發。如果這時團隊還要兼顧對外合作項目開發，涉及項目超30個，業務量需要容納的用戶超過千萬，這個工作量就更大了。

在這種配置要求下，「傳統開發模式」和「飛算全自動軟件工程平臺」兩者人力成本的相關費用對比是很鮮明的。

如果使用后者，每年可節省75％以上的研發費用。尤其在人力成本方面，一個平臺ID人員可替代傳統開發模式下包含項目經理，系統架構師，軟件設計師，軟件工程師，測試工程師，運維工程師等六個崗位人員的全部工作，而人力成本僅占后者的30％。

這是人員配置上的項目成本優勢，開發效率的提升我們之前也提過了，至于團隊和系統穩定性，當操作者降低軟件工程對技術的依賴時，技術選型、技術綁架、技術趟坑等問題也隨之減少；而標準化、減少人工輸入的環節也提高了代碼質量。

之前我看過一本書叫《人月神話》，作者是Fred Brooks。按照他的劃分，軟件開發的復雜度大概有兩種，本質復雜度（Essential complexity ）和偶然復雜度（Accidental complexity）。前者有點兒類似于企業的這個業務需求，本身的復雜程度，和工程師用什么樣的工具寫代碼、經驗是否豐富、架構好不好都沒什么關系。而后者就是實際開發過程中引入的復雜度，就是技術細節的復雜度。

業務的復雜度是企業決定的，給開發者和企業方提供服務的平臺本身是改變不了的，能動的，就是技術細節復雜度的降低。這就好比，烹飪一份食材特殊、流程復雜、技術高超的美食，平臺方要把菜挑選好了，都洗好切好，火候也掌握好，每一道工序的時間都明確寫好，廚師自己照著做就可以。

平臺承擔的事情越多，在平臺上開發軟件的工程師就越輕松，這和做一個快樂的廚師，沒什么不同。當然，也不是說這個工程師誰都可以做，每個人承擔的角色不同，發揮的作用機制自然也不一樣。

目前，我國軟件和信息技術服務業規模以上企業在2019年就超過了4萬家，累計完成軟件業務收入71768億元，同比增長15．9％。在中國企業從信息化時代全面轉向數字化的階段里，軟件開發作為企業數字化轉型的重要環節，很有可能成為中堅力量。

一個美好的想象是，我希望未來企業家也不用再高喊996的口號，碼農們也不用徹夜敲代碼，當機器代替人類創造出更多價值時，基于科技和人文之上的，就是人類不斷發掘需求痛點，并解決問題的創造思維和無窮想象了。

責任編輯：xj