使用零代碼平台構建應用，應該怎樣轉變思路？

最近兩年，越來越多的各類零代碼產品在市場上出現，與此同時，企業的數字化轉型的速度也越來越快，零代碼產品已然成為了幫助企業數字化轉型的利器。

技術也在不斷地演進，其核心目的就是讓開發人員能夠更專注於業務邏輯：

1、上古時代我們通過傳輸字節碼和電子信號在物理層來完成通信，需要自己處理各種丟包、重試等網絡問題，最後就出現了 TCP 協議來解決這些問題；

2、在分佈式時代，解決了「三高」問題，同時也需要我們來處理熔斷、負載均衡、服務發現、認證和授權、鏈路追蹤等問題，這時很多微服務的中間件就出現了，比如：API 網關有 Ocelot、Zuul；鏈路跟蹤有 Zipkin、Jaeger、SkyWalking；服務發現有 consul、Eureka ；甚至出現了像 Spring Cloud 這種全家桶式的框架，這些工具幫我們處理了通信細節，使開發人員使用較少的代碼就能開發出健壯的分佈式系統；

3、上面提到的各種中間件幫我們解決了很多問題，但對各種中間件框架的學習、排錯也是一件令人頭疼的事情，為了解決這些問題， Service Mesh 就誕生了；

4、再往後就出現了 Serverless 技術（ FaaS 和 BaaS ），其目的仍然是降本增效，關注業務，關於 Serverless 的詳細介紹可以看看 《 帶你瞭解 Serverless 無服務器架構 》。

零代碼平台在現在的技術背景下，恰逢其時，就是為專注業務而生。但在我們使用零代碼平台時，還是需要有些思路的轉變，特別是如果你有技術背景更是如此，為什麼這麼説呢？

1、客户往往會根據自己的經驗將業務背景轉化為最終的實現，並告訴你該怎麼做，如果是定製開發，很可能就會按照客户的思路去實現來，但使用零代碼平台，發現實施時比較彆扭的時候，就會去更深層次挖掘客户背後的真實想法，這樣實現的功能更能符合預期；

2、技術人員會根據自己之前個性化開發的經驗來使用平台，會有思維上的侷限性。

下面來講兩個案例來看看怎樣進行思路的轉變。

案例一

某客户的一個報銷流程功能有很多不同的分類，比如日常費用報銷、差旅報銷等，兩種不同類型的表單上的字段顯示差異較大，但數據源使用的是同一個。

定製開發的思路

1、將費用報銷和差旅報銷的所有字段都放到一張表中；

2、表單上添加一個報銷類型的下拉框，當切換不同類型的時，控制相應控件的顯示和隱藏；

3、保存數據時收集界面可見的控件的值即可。

如果按照這個思路在零代碼平台中去實現會遇到麻煩：

1、當切換不同類型的時，控制相應控件的顯示和隱藏，這時需要對每個控件去編寫隱藏規則，當涉及的控件比較多時，很繁瑣；

2、如果有些複雜的控制邏輯隱藏規則不能支持，還需要編寫表單腳本進行處理，增加實施成本和難度。

零代碼平台實現思路

1、正如上面所説，去控制每個控件的隱藏規則的成本比較高，所以需要思考在平台中有什麼成本比較低的實現方式；

2、在平台中利用引用功能，可以快速創建一個相同功能，原功能和引用功能共用一個數據源；

3、原功能表單配置成日常費用報銷，引用功能表單配置成差旅報銷

4、在原功能上添加自定義按鈕打開引用功能的表單，差異點就是之前需要打開表單後進行類型的切換，現在是在打開表單前通過不同的按鈕進行選擇。

案例二

某集團公司客户説我們需要一個論壇、可以發帖子供很多人討論。

定製開發的思路

1、根據客户的要求定製開發一個論壇；

2、部署一個開源的論壇系統，但還要考慮跟現有系統的各種集成，比如單點、數據統計、提醒等；

在我們的零代碼平台中暫時還沒有論壇模塊，那能跟客户説我們不支持嗎？肯定是不行的。所以這時就需要挖掘客户到底想要什麼？經溝通後發現，客户的目的就是想要有一個針對某個話題供討論的地方，形式不一定是論壇，只是一想到根據主題討論很容易就想到了論壇。

零代碼平台實現思路

1、創建一個帶流程的功能模塊；

2、流程控制永不結束，在兩個節點直接來回流轉，可以任意選擇審批人（需要參與討論的人）；

3、接收人可以填寫審批意見（主題的回覆）後提交，而且流程天然有消息提醒，提交後，相關人員會收到郵件或企業微信消息提醒。

當把示例做好跟客户演示後，客户對實現效果很認同，覺得滿足了他們的需求。

零代碼平台可以理解為一種面向業務的語言，最終幫助客户來實現業務價值，也能夠當成是一個聊天溝通的工具，和客户統一語言。在最終落地實現的時候，一定要了解到客户背後最真實的想法，然後結合零代碼平台的功能，給出最佳實踐。

想了解更多的零代碼平台的落地方案，可以掃下方二維碼進羣溝通討論，我們的直播信息也會第一時間發佈在羣裏。