低代碼又火了。
近幾年，騰訊、阿裡、百度等網際網路大廠紛紛入局，國内外低代碼平台融資動辄數千萬甚至數億，以及伴随着熱度而來的巨大争議……無不說明“低代碼”的火爆。
事實上，低代碼并非新概念，它可以追溯到上世紀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和裝置機聯網系統，覆寫了銷售、采購、倉庫、計劃、生産、财務等全流程功能，且已經在生産現場投入使用。在開發過程中，甯波聚軒的開發團隊利用低代碼平台成功解決了定制化要求高、多終端需求等難題，及時完成項目傳遞。
圖示：甯波聚軒軸承行業數字化智造系統的手持終端和手機移動端系統界面
當迷霧散盡，低代碼開發平台重新露出高效率開發工具的本色時，你會選擇它嗎？
本文是由葡萄城技術開發團隊釋出，轉載請注明出處：葡萄城官網