[[429445]]

本文轉載自微信公眾號「不止dotNET」，作者oec2003 。轉載本文請聯系不止dotNET公眾號。

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

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

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、接收人可以填寫審批意見(主題的回復)后提交，而且流程天然有消息提醒，提交后，相關人員會收到郵件或企業微信消息提醒。

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

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