低程式碼又火了。
近幾年，騰訊、阿里、百度等網際網路大廠紛紛入局，國內外低程式碼平臺融資動輒數千萬甚至數億，以及伴隨著熱度而來的巨大爭議……無不說明“低程式碼”的火爆。
事實上，低程式碼並非新概念，它可以追溯到上世紀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項關鍵能力。
圖源：https://www.gartner.com/en/do...
這裡我們著重來看其中三項關鍵能力。
- 資料建模和管理：該指標就是通常所講的“模型驅動”。相比於表單驅動，模型驅動能夠提供滿足資料庫設計正規化的資料模型設計和管理能力。開發的應用複雜度越高，系統整合的要求越高，這個能力就越關鍵。
- 流程和業務邏輯：流程應用與業務邏輯開發能力和效率。這個能力有兩層，第一層是指使用該低程式碼開發平臺能否開發出複雜的工作流和業務處理邏輯；第二層是開發這些功能時的便利性和易用性程度有多高。
- 介面和整合：程式設計介面與系統整合能力。為了避免“資料孤島”現象，企業級應用通常需要與其他系統進行整合，協同增效。此時，內建的整合能力和程式設計介面就變得至關重要。除非確認可預期的未來中，專案不涉及系統整合和擴充套件開發，開發者都應該關注這個能力。
這些關鍵能力表明低程式碼平臺在建模與邏輯方面具備較強的能力，而介面和整合能力可使專業開發人員完成低程式碼無法實現的部分，通過低程式碼與專業程式碼開發的協作實現複雜應用的開發。在涉及高價值或複雜的核心業務時，專業開發人員需要理解業務需求，釐清業務邏輯。從這個層面上看，低程式碼開發的門檻並不低。事實也是如此：海比研究在《2021 年中國低程式碼/無程式碼市場研究報告》中提到，截至 2020 年底，技術人員在低程式碼使用者中的比例超 75%，佔主體地位。
低程式碼什麼都能做嗎？
程式設計師的工作圍繞開發需求展開。在選擇開發工具時，程式設計師通常考慮的首要問題是：這款工具能否覆蓋所有需求？如果需求增加或變更，該工具是否支援相關操作？這些問題同樣適用於低程式碼平臺的選型。
在實際專案交付過程中，如果我們僅可以滿足99%的需求，另外1%的需求滿足不了，那麼真實使用者大概率是不會買單的。因此，在評估低程式碼產品的時候，我們一定要保證該平臺可以支撐所有系統模組型別的開發，同時也要具備足夠的擴充套件性，確保使用純程式碼開發出的模組能夠與低程式碼模組進行無縫整合，而這離不開程式設計介面。
以國內主流低程式碼開發平臺活字格為例。該平臺提供開箱即用的開發元件，同時為系統的各個分層均提供程式設計擴充套件能力，以滿足企業級應用開發對擴充套件性的高要求。藉助分層程式設計介面，開發者可以用純程式碼的方式實現新增功能，無需受限於低程式碼開發平臺的版本和現有功能。
圖示：活字格的程式設計擴充套件能力
當然，就具體應用領域而言，低程式碼開發平臺也有其擅長和不擅長的地方。目前，低程式碼開發更多地被應用於2B企業應用開發，而對於使用者量特大的頭部網際網路應用、對演算法和複雜資料結構要求較高的應用，低程式碼平臺則不太適合。
低程式碼開發不可控？
“低程式碼開發平臺是個黑盒子，內部出問題無法排查和解決。開發過程中發現有問題怎麼辦？迭代升級難以實現怎麼辦？”很多程式設計師會有這種疑惑。
但我們需要注意的是，低程式碼開發平臺本質上仍是軟體開發工具，使用者模型與軟體開發週期支援是其關鍵能力之一。也就是說，成熟的低程式碼開發平臺具備軟體開發全生命週期所需的各項功能，從而大大簡化開發者的技術棧，進一步提高開發效率。
具體而言，在面對頻繁的需求變更、棘手的問題排查時，低程式碼開發平臺引入了版本管理機制，從而更高效地進行程式碼審查、版本管理與協調，以及軟體的迭代升級。至於debug，日誌分析無疑是個好辦法。例如，活字格把執行過程及細節以日誌方式輸出，方便程式設計師高效debug。
對程式設計師而言，低程式碼平臺是限制還是助力？
“低程式碼”意味著更少的程式碼。程式碼都不怎麼寫了，程式設計師又該怎麼成長，怎麼獲得職業成就感呢？
其實不然。
首先，開發 ≠ 寫程式碼。低程式碼平臺可以減少大量重複工作，提升開發效率，把專業開發人員從簡單、重複的開發需求中解放出來，把精力投入到更有價值的事情上，比如精進技術、理清業務邏輯。
其次，低程式碼平臺的元件化和拖拽式配置降低了開發門檻，新手程式設計師能夠藉助此類平臺快速入門，加速升級打怪；有經驗的程式設計師也有機會參與更多專案，甚至帶團隊，積累更多經驗值，實現快速成長。
寧波聚軒就是一個例子。這家公司自2009年起就專注於智慧製造、工業4.0、系統方案整合等領域的探索研究。在接觸了低程式碼之後，專案負責人發現開發效率得到極大提升，採用傳統方式需要一個月開發量的專案，現在需要半個月甚至更短的時間就可以完成。此外，其實踐經驗表明，低程式碼開發的學習成本較低，畢業新生經過一週學習，兩週就可做專案，一個月就能熟練開發。
該公司在2021企業級低程式碼應用大賽中獲得了應用創新獎，獲獎作品是一套軸承行業數字化智造系統。這套系統主要整合了ERP、MES、WMS和裝置機聯網系統，覆蓋了銷售、採購、倉庫、計劃、生產、財務等全流程功能，且已經在生產現場投入使用。在開發過程中，寧波聚軒的開發團隊利用低程式碼平臺成功解決了定製化要求高、多終端需求等難題，及時完成專案交付。
圖示：寧波聚軒軸承行業數字化智造系統的手持終端和手機移動端系統介面
結語
當迷霧散盡，低程式碼開發平臺重新露出高效率開發工具的本色時，你會選擇它嗎？