低代碼又火了。
近幾年，騰訊、阿里、百度等互聯網大廠紛紛入局，國內外低代碼平臺融資動輒數千萬甚至數億，以及伴隨著熱度而來的巨大爭議……無不說明“低代碼”的火爆。
事實上，低代碼并非新概念，它可以追溯到上世紀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。
對程序員而言，低代碼平臺是限制還是助力？
“低代碼”意味著更少的代碼。代碼都不怎么寫了，程序員又該怎么成長，怎么獲得職業成就感呢？
其實不然。
首先，開發 ≠ 寫代碼。低代碼平臺可以減少大量重復工作，提升開發效率，把專業開發人員從簡單、重復的開發需求中解放出來，把精力投入到更有價值的事情上，比如精進技術、理清業務邏輯。
其次，低代碼平臺的組件化和拖拽式配置降低了開發門檻，新手程序員能夠借助此類平臺快速入門，加速升級打怪；有經驗的程序員也有機會參與更多項目，甚至帶團隊，積累更多經驗值，實現快速成長。
結語
當迷霧散盡，低代碼開發平臺重新露出高效率開發工具的本色時，你會選擇它嗎？
原文鏈接：https://segmentfault.com/a/1190000040842990?utm_source=tuicool&utm_medium=referral
