駁「低程式碼開發取代程式設計師」論 為什麼專業開發者也需要低程式碼？
- 2021 年 11 月 12 日
- 筆記
低程式碼又火了。
近幾年，騰訊、阿里、百度等互聯網大廠紛紛入局，中國外低程式碼平台融資動輒數千萬甚至數億，以及伴隨著熱度而來的巨大爭議……無不說明「低程式碼」的火爆。
事實上，低程式碼並非新概念，它可以追溯到上世紀80年代的「第四代程式語言」。2014年，Forrester正式提出低程式碼的概念。低程式碼是一種軟體開發技術，衍生於軟體開發的高級語言，讓使用者通過可視化的方式，以更少的編碼，更快速地構建和交付應用軟體，全方位降低軟體的開發成本。與傳統軟體開發方式相比，低程式碼開發平台整合了軟體開發和部署所需的 IDE（集成開發環境）、伺服器和資料庫管理工具，覆蓋軟體開發的全生命周期，我們可以將其理解為 Visual Studio + IIS + SQL Management Studio（.NET 技 術）或 Eclipse + Tomcat + MySQL Workbench（Java 技術）的組合。
編碼更少、交付更快、成本更低，還覆蓋軟體開發全生命周期，怎麼看低程式碼都可以說是不錯的軟體開發工具。那麼，它又為什麼引發爭議，甚至被其主要用戶群體之一——程式設計師所詬病呢？「低程式碼開發會取代程式設計師」 這一觀點大行其是，它說得對嗎？
為什麼低程式碼引起專業開發者的反感？
技術浪潮引發巨大變革，也帶來了無數「取代論」，比如機器翻譯是否取代人類翻譯、機器人記者是否取代人類記者，以及低程式碼開發是否取代程式設計師。
低程式碼雖然火爆，但程式設計師對此抱有不同的心態：
輕視：低程式碼技術的諸多優勢只是炒作，該技術更適合初學者，解決不了複雜的技術問題；
恐懼：擔心被低程式碼取代；
抵觸：低程式碼開發平台能夠覆蓋所有需求嗎；大量封裝組件使得低程式碼開發平台更像一個黑盒子，可能導致難以debug、難以修改和迭代升級等技術問題；低程式碼開發平台配置有大量組件，簡單的拖拉拽動作即可完成大量開發工作，程式設計師不再需要厲害的技術能力。
那麼，上述理由真的站得住腳嗎？我們一一來看。
低程式碼的門檻真的低嗎？
低程式碼開發過程常被比作拼積木：像拼搭積木一樣，以可視化的方式，通過拖拉拽組件快速開發出數據填報、流程審批等應用程式，滿足企業里比較簡單的辦公需求。
但這並不意味著低程式碼開發平台只能做到這些。
Gartner在2020年9月發布的《企業級低程式碼開發平台的關鍵能力報告》（Critical Capabilities for Enterprise Low-Code Application Platforms）中，列舉了低程式碼的11項關鍵能力。
這裡我們著重來看其中三項關鍵能力。
-
數據建模和管理：該指標就是通常所講的「模型驅動」。相比於表單驅動，模型驅動能夠提供滿足資料庫設計範式的數據模型設計和管理能力。開發的應用複雜度越高，系統集成的要求越高，這個能力就越關鍵。
-
流程和業務邏輯：流程應用與業務邏輯開發能力和效率。這個能力有兩層，第一層是指使用該低程式碼開發平台能否開發出複雜的工作流和業務處理邏輯；第二層是開發這些功能時的便利性和易用性程度有多高。
-
介面和集成：編程介面與系統集成能力。為了避免「數據孤島」現象，企業級應用通常需要與其他系統進行集成，協同增效。此時，內置的集成能力和編程介面就變得至關重要。除非確認可預期的未來中，項目不涉及系統集成和擴展開發，開發者都應該關注這個能力。
這些關鍵能力表明低程式碼平台在建模與邏輯方面具備較強的能力，而介面和集成能力可使專業開發人員完成低程式碼無法實現的部分，通過低程式碼與專業程式碼開發的協作實現複雜應用的開發。在涉及高價值或複雜的核心業務時，專業開發人員需要理解業務需求，釐清業務邏輯。從這個層面上看，低程式碼開發的門檻並不低。事實也是如此：海比研究在《2021 年中國低程式碼/無程式碼市場研究報告》中提到，截至 2020 年底，技術人員在低程式碼使用者中的比例超 75%，佔主體地位。
低程式碼什麼都能做嗎？
程式設計師的工作圍繞開發需求展開。在選擇開發工具時，程式設計師通常考慮的首要問題是：這款工具能否覆蓋所有需求？如果需求增加或變更，該工具是否支援相關操作？這些問題同樣適用於低程式碼平台的選型。
在實際項目交付過程中，如果我們僅可以滿足99%的需求，另外1%的需求滿足不了，那麼真實用戶大概率是不會買單的。因此，在評估低程式碼產品的時候，我們一定要保證該平台可以支撐所有系統模組類型的開發，同時也要具備足夠的擴展性，確保使用純程式碼開發出的模組能夠與低程式碼模組進行無縫集成，而這離不開編程介面。
以中國主流低程式碼開發平台活字格為例。該平台提供開箱即用的開發組件，同時為系統的各個分層均提供編程擴展能力，以滿足企業級應用開發對擴展性的高要求。藉助分層編程介面，開發者可以用純程式碼的方式實現新增功能，無需受限於低程式碼開發平台的版本和現有功能。
圖示：活字格的編程擴展能力
當然，就具體應用領域而言，低程式碼開發平台也有其擅長和不擅長的地方。目前，低程式碼開發更多地被應用於2B企業應用開發，而對於用戶量特大的頭部互聯網應用、對演算法和複雜數據結構要求較高的應用，低程式碼平台則不太適合。
低程式碼開發不可控？
「低程式碼開發平台是個黑盒子，內部出問題無法排查和解決。開發過程中發現有問題怎麼辦？迭代升級難以實現怎麼辦？」很多程式設計師會有這種疑惑。
但我們需要注意的是，低程式碼開發平台本質上仍是軟體開發工具，用戶模型與軟體開發周期支援是其關鍵能力之一。也就是說，成熟的低程式碼開發平台具備軟體開發全生命周期所需的各項功能，從而大大簡化開發者的技術棧，進一步提高開發效率。
具體而言，在面對頻繁的需求變更、棘手的問題排查時，低程式碼開發平台引入了版本管理機制，從而更高效地進行程式碼審查、版本管理與協調，以及軟體的迭代升級。至於debug，日誌分析無疑是個好辦法。例如，活字格把執行過程及細節以日誌方式輸出，方便程式設計師高效debug。
對程式設計師而言，低程式碼平台是限制還是助力？
「低程式碼」意味著更少的程式碼。程式碼都不怎麼寫了，程式設計師又該怎麼成長，怎麼獲得職業成就感呢？
其實不然。
首先，開發 ≠ 寫程式碼。低程式碼平台可以減少大量重複工作，提升開發效率，把專業開發人員從簡單、重複的開發需求中解放出來，把精力投入到更有價值的事情上，比如精進技術、理清業務邏輯。
其次，低程式碼平台的組件化和拖拽式配置降低了開發門檻，新手程式設計師能夠藉助此類平台快速入門，加速升級打怪；有經驗的程式設計師也有機會參與更多項目，甚至帶團隊，積累更多經驗值，實現快速成長。
寧波聚軒就是一個例子。這家公司自2009年起就專註於智慧製造、工業4.0、系統方案集成等領域的探索研究。在接觸了低程式碼之後，項目負責人發現開發效率得到極大提升，採用傳統方式需要一個月開發量的項目，現在需要半個月甚至更短的時間就可以完成。此外，其實踐經驗表明，低程式碼開發的學習成本較低，畢業新生經過一周學習，兩周就可做項目，一個月就能熟練開發。
該公司在2021企業級低程式碼應用大賽中獲得了應用創新獎，獲獎作品是一套軸承行業數字化智造系統。這套系統主要集成了ERP、MES、WMS和設備機聯網系統，覆蓋了銷售、採購、倉庫、計劃、生產、財務等全流程功能，且已經在生產現場投入使用。在開發過程中，寧波聚軒的開發團隊利用低程式碼平台成功解決了訂製化要求高、多終端需求等難題，及時完成項目交付。
圖示：寧波聚軒軸承行業數字化智造系統的手持終端和手機移動端系統介面
結語
當迷霧散盡，低程式碼開發平台重新露出高效率開發工具的本色時，你會選擇它嗎？
