有沒有發現，每隔幾年總會有一些火熱的前沿詞彙出現在我們面前，比如：雲原生、微服務、中臺、Servless、低代碼等等。那麼你是否有想過，這些概念的背後是什麼推動的呢？結論並不難發現，從各種概念的目標上去合併同類項，它們的本質目標都是：提高研發效率！
在提高研發效率的道路上，各種方案都有着不同的側重點，有的着力於基礎設施的完善，有的着力於系統架構的優化，有的着力於生產工具的更新。拿最近最爲熱門的低代碼平臺來說，更多的是站在生產工具這一側重點之上。
不同於傳統IDE的生產工具
說到生產工具的提升，我們往往第一反應想到的是IDE上的優化，比如：IDEA、Eclipse這些開發工具上所做的文章，而低代碼平臺與這些還有着本質區別。
在傳統開發工具的產品迭代上，我們更多看到優化點是：更酷炫的界面、更友好的編碼聯想、更精準的錯誤提示、更方便的調試流程、更便捷的構建工具等面向傳統開發者的完善方向。這方面的生產工具擁有更高的靈活性，因爲我們可以根據團隊偏好和管理需要去自由的構建我們的工程風格，來完成我們的開發目標。
而低代碼平臺的實現目標與傳統開發工具產品不同，他們致力於讓用戶寫更少的代碼，以更友好的編碼方式，降低數字化系統建設的人才門檻，讓更多的人可以快速的上手並參與到企業信息化建設中去。那麼爲什麼低代碼平臺可以降低開發人員的上手門檻，可以加速企業的數字化建設呢？
我覺得主要有以下幾個方面：
可視化的編碼方式
開發者對領域模型的設計、用戶界面的實現、業務流程的規劃等核心編碼邏輯，都可以用拖拉拽的方式實現。
比如：我們以專注低代碼領域多年的奧哲旗下產品雲樞爲例。假設我們要實現一個企業常規的請假流程，是如何實現的，來體會與傳統開發之間的主要差異！
第一步：領域模型設計。傳統開發模式之下，我們要做的是根據我們所用的數據庫來完成表結構的創建，這裏就需要我們維護好相關的創建腳本。而這裏我們可以看到，我們只需要通過可視化的方式來完成領域模型的設計，同時並不需要考慮具體用的什麼數據庫，對於選擇不同數據庫之間的差異可最後依靠平臺來自動完成適配。
第二步：操作界面設計。在所有的低代碼平臺中，幾乎都提供了所見即所得的表單設計能力。其原理就是將各種常用的頁面元素實現組件化，並與領域模型實現關聯綁定之後，通過配置完成業務數據的輸入存儲與讀取展現。所以，如果業務需求在已有的現成組件都可以滿足的情況下，用戶在實現的時候，是不需要編寫代碼就可以完成界面的設計與實現。
第三步：業務流程設計。對於流程化的業務需求，常規模式之下，簡單的我們可以用狀態模式或一些輕量級的狀態機框架來編碼實現，複雜或靈活一些的，我們需要引入工作流框架來實現，需要做很多複雜的前置配置並且需要較多的學習才能上手並用好。而通過低代碼平臺中的流程設計界面可以看到，流程開發配置過程被簡化了很多。
從上面的幾個產品開發核心步驟中，我們可以發現，低代碼平臺都在儘可能去封裝各種常用編碼操作，儘可能的讓用戶可以所見即所得的去完成各階段的設計與開發步驟，儘可能的減少代碼的編寫，對於一些簡單需求，甚至實現零代碼完成的目標。
開發運維一體化
通過上面可視化的編碼，我們是可以快速的完成一個業務需求的開發了。但開發過程對於一個需求的實現，只是前期過程，那麼後續的項目打包、版本管理、產品上線又是怎麼樣的呢？
對於一個成熟的低代碼平臺來說，這些內容必須涵蓋其中！這也是與傳統開發模式存在較大差異的部門。但這裏由於低代碼平臺的定位不同，可能會有幾種不同的處理方案，常見的主要有兩類：
第一類：SaaS化的部署能力。這種低代碼平臺往往提供較爲輕量級的實現能力，比如：在線化的Excel工具。用於實現一些簡單的問卷調查、數據採集與統計等功能。這類需求不需要太複雜的界面交互、流程控制或數據處理的情況。比如：奧哲旗下的另一個產品：有格
這一類產品，由於定位於輕量級低代碼平臺，所以他的應用範圍會更偏向於一些常見的模型，所以平臺也會提高一些模版，便於用戶快速上手，基於行業固有模版去做二次定製來快速實現符合自己團隊需要的一套應用。
而整個開發過程也相較上面提到的雲樞也更爲簡單，比如：下面是用該工具完成的一個敏捷研發管理應用。
由於這類平臺所面向的應用場景較爲簡單，往往它們具有臨時性、週期短等特點，它們並不需要部署到特定的環境，自然也沒有與私有資源的對接，所以這類平臺往往直接就可以在平臺側實現對用戶應用的部署與使用。
第二類：提供DevOps與私有化資源的整合能力。相較於上面的輕量級低代碼平臺來說，這種就是比較重量級的了。在可視化的編碼方式一節中，我們所舉的雲樞]就是這樣一個兼備了運維能力整合的低代碼平臺。
它涵蓋了從產品版本的構建構建：
到基礎設施的維護：
再到產品的發佈：
涵蓋了一個需求從開發到上線的完整流程。所以，我們可以看到對於一個業務需求的時候，通過低代碼平臺的應用，整個產品研發過程，都被整合到了一個平臺之中。這與我們應用傳統生產工具有着非常大的差異，我們不需要再去自己設計代碼庫的版本管理、構建包的管理、部署資源的管理等一系列的架構管理設計。通過這類低代碼平臺提供的整體管理方案就能支持產品的開發、測試、上線全流程管理。
雖然強大，但也不是銀彈
在看了上面介紹的第二類低代碼平臺，是不是感覺這東西非常強大，那麼它會是開發效率提升的銀彈嗎？未來會像有些廠商說的：未來人人都是開發者，程序員都要失業了？
對於宣傳“未來人人都是開發者”這樣的觀點，我是不認同的。因爲我還是相信軟件開發不存在銀彈！雖然低代碼平臺看上去已經很強大，但不論是輕量級、還是重量級的低代碼平臺來看，也都是針對一些特殊客戶羣體的。並不存在一款低代碼平臺能夠適應所有的開發團隊與業務場景，所以低代碼平臺也不能被籠統稱作爲提升效率的銀彈，應該說在更符合個性化需求的前提下，來幫助開發團隊或者企業提升效率。
對於輕量級的低代碼平臺而言，因爲功能相對簡單，對於複雜多變、需要更多創新元素的互聯網C端產品來說，就不太適合使用。我認爲這一類平臺更適合應用於一些業務邏輯更爲穩定的場景，或一些臨時性的數據採集、統計類需求，就像奧哲有格中的那些模版應用，這些經過行業長期沉澱，大部分團隊都類似，最多有一些小變化的應用方向。或者一些類似問卷等臨時性的需求，就特別適合使用。選擇一些產品易用性好的平臺，甚至都不需要開發介入，一些聰明的產品和運營都能自己通過配置實現一些簡單需求。
對於重量級的低代碼平臺而言，因爲功能更爲專業，可以滿足比輕量級平臺更爲複雜的業務需求，並能適配更多不同團隊的管理模式。但這類平臺使用中涉及的概念還是非常衆多的。所以，只能說這類平臺對於開發人員來說會更容易上手。對於沒有開發思維的純業務人員來說，還是具備一定的門檻。這類平臺更適合應用於大型開發團隊對大企業內部系統的開發，對於人員配置上，相較傳統開發要求更低，但對於開發速度表現更快。
但目前這類平臺對於一些複雜場景，尤其對於一些高併發的業務場景還有提升空間。因爲在這些場景中，我們往往需要動用很多中間件、緩存、限流、熔斷等技巧來保障系統的良好運行。因此，雖然我認爲低代碼平臺是一個很好的工具，不論輕量級的還是重量級的，都能解決部分場景的開發效率問題。但如果想讓業務開發人員專注於業務功能實現，並覆蓋所有場景，那麼在性能架構方面要做出強化。
總的來說，我建議我們在選型與應用低代碼平臺時，一定要充分理解自身業務場景的特點與各低代碼平臺優勢之間的關係，必須有的放矢，才能讓低代碼平臺發揮最大的價值！切勿拿了平臺看到需求就到處推，不要因爲好工具用錯場景，被噴的一無是處！
最後，做個小調研：你們開始使用低代碼平臺了嗎？你覺得低代碼平臺給你們帶來了效率的提升嗎？加入我們的技術交流羣，聊聊你的觀點！
歡迎關注我的公衆號：程序猿DD，獲得獨家整理的免費學習資源助力你的Java學習之路！另每週贈書不停哦～