嚴肅編碼人員的10條低代碼規(guī)則

在全球大流行的艱苦壓力測試之后，企業(yè)現(xiàn)在必須應對戰(zhàn)爭和疲軟的宏觀經(jīng)濟環(huán)境的壓力，同時轉型為現(xiàn)代、可組合和有競爭力的企業(yè)。處于這一轉型核心的技術高管正在追求大膽而務實的戰(zhàn)略，包括快速構建和擴展新的軟件驅動型業(yè)務功能。對他們來說，圣杯似乎是通過低代碼/無代碼（LCNC）方法使軟件應用程序開發(fā)本身民主化，以快速和大規(guī)模地交付給業(yè)務。

專業(yè)開發(fā)人員和企業(yè)架構師參與管理 LCNC 開發(fā)，因為企業(yè)開始考慮政策、流程和人員，以負責任地擴展這一運動。但專業(yè)編碼人員本身還不是LCNC平臺的積極采用者 - 他們的范圍從感興趣的觀察者（充其量）到那些討厭LCNC平臺的人（出于其正當理由）。

根據(jù)行業(yè)估計，專業(yè)編碼人員大約 35-40% 的時間花在設置、創(chuàng)建護欄、導入和與數(shù)據(jù)源集成、從頭開始編寫代碼、使代碼安全、測試和重新測試應用程序、管理源代碼控制和版本控制、添加國際化、使其可訪問、優(yōu)化性能以及維護或升級應用程序。另外30%的時間花在非技術或運營活動上。這樣一來，他們只有不到一半的生產時間用于思考、創(chuàng)新和制作復雜且引人注目的應用和體驗。

顯然，專業(yè)編碼人員會感到痛苦。那么，低代碼平臺應該提供什么來吸引專業(yè)程序員采用它們，更好的是，接受它們呢？讓我們深入研究。

規(guī)則1：保持開放。提供熟悉度和可見性

如果一個低代碼平臺使用基于開放標準的流行技術堆棧（React、Angular 和 Bootstrap for UI;后端彈簧;碼頭工人容器）？如果開發(fā)人員可以實際看到并讀取正在生成的真實（不是模型生成或元數(shù)據(jù)驅動的）代碼，該怎么辦？如果這段代碼是按照他們編碼的方式編寫的呢？

專業(yè)程序員習慣于在開放且被廣泛接受的語言或框架中查看、閱讀和理解真實代碼。所以，就給他們吧。

規(guī)則 2：自定義所有內容

開發(fā)人員需要能夠向其應用程序添加細粒度邏輯;也就是說，在代碼編輯器中編寫自定義服務或創(chuàng)建自定義 API，以及拖放畫布。

低代碼平臺應該為開發(fā)人員提供高度配置每個開箱即用小部件的能力，以允許創(chuàng)建視覺上迷人的體驗。

想象一下，如果開發(fā)人員可以超越標準的 UI 小部件庫并創(chuàng)建自己的自定義組件（注入 API 的 UI 的構建塊）并添加到他們的私有庫中。有時，開發(fā)人員可能還需要將預構建的組件（React 或 Angular 或 GraphQL 組件導出為標準 Web 組件）導入到他們的低代碼開發(fā)平臺中并重用它們。

最后，開發(fā)人員可能希望創(chuàng)建自己的應用程序主題（字體、布局、顏色和樣式的組合），以便在一個或多個應用程序或產品中創(chuàng)建差異化但一致的品牌用戶體驗。

規(guī)則 3：輕松與數(shù)據(jù)源集成?？焖僭O置。

必須支持與 API（REST、SOAP 或 WebSocket）、數(shù)據(jù)庫（如 MySQL、Maria DB、PostgreSQL、Oracle DB、SQL Server、IBM DB2、Amazon Redshift、SAP Hana、HSQL 和 Mongo DB）等數(shù)據(jù)源的集成和提取，這些數(shù)據(jù)源必須得到支持，并且毫不費力。

CRUD 操作通常由開發(fā)人員硬編碼，占用大量時間。如果低代碼平臺可以在導入數(shù)據(jù)源后自動生成所有 CRUD API，則可以大大減少開發(fā)時間。同樣，復制數(shù)據(jù)庫架構的數(shù)據(jù)庫的可編輯抽象可以幫助開發(fā)人員從平臺本身內部操作數(shù)據(jù)。

導入后，開發(fā)人員應該能夠通過傳遞變量輕松快速地將其 UI 綁定到后端。然后，來自 REST 調用的數(shù)據(jù)應該可以輕松地顯示為頁面上的實體，而無需任何解決方法或冗長的導入和模型定義。同樣，使用 Swagger 導入，描述應該能夠在多個端點或遞歸模型中重用同一模型。

規(guī)則 4：應用必須安全、可縮放且性能高

對于用戶身份驗證，開發(fā)人員可能需要與數(shù)據(jù)庫、LDAP、Active Directory、SAML 和其他身份驗證提供程序集成。應通過支持 SAML 聯(lián)合身份驗證和中央身份驗證服務器 （CAS） 輕松啟用 SSO。對于授權，低代碼平臺需要支持跨頁面擴展的粗粒度和細粒度權限、頁面上的單個小部件，甚至是應用程序公開的單個 API。

開發(fā)人員尋求針對OWASP漏洞（XSS，CSRF，暴力攻擊，SQL注入）的保護，并在應用程序托管期間支持TLS 1.2+等加密標準。理想情況下，低代碼平臺需要由Veracode等安全領導者認證，他們執(zhí)行嚴格的靜態(tài)和動態(tài)測試（iAST，SAST，DAST和SCA）。

通過無會話架構、分布式緩存、通過容器的水平擴展以及特定于 UI 框架的性能功能（例如，Angular 13 具有延遲加載、Brotli 壓縮、樹搖動、常春藤），使用低代碼平臺的開發(fā)人員可以構建高性能應用程序，最大限度地減少聊天和 UI 到后端的往返。例如，它不是在會話中存儲狀態(tài)，而是可以通過分布式緩存（如 Redis）提供支持，以允許應用水平縮放。

規(guī)則 5：隨時隨地部署

開發(fā)人員不能受限于特定于供應商的應用部署基礎結構。他們需要自由和靈活地在任何地方托管他們的應用程序 - 在任何公共云、私有云或混合云上，在 K8s 集群上，或在裸機/本地基礎設施上。提供 UI 與后端分離的開發(fā)模型的低代碼平臺可以允許使用標準存檔或 Docker 映像單獨打包和部署 UI 和后端工件（UI 到 CDN;例如，后端到標準 Java 服務器，如 Tomcat）。

規(guī)則6：復雜而長期存在的應用程序和大規(guī)模平臺

開發(fā)人員手動編寫當今使用的一些最復雜的應用程序和系統(tǒng)。他們需要低代碼平臺來加強工作，并提供同樣復雜的應用程序，這些應用程序在維護和增強方面可以長期可持續(xù)。

例如，低代碼平臺需要與第三方BPM工具（Camunda，jBPM，F(xiàn)lowable，Activity）集成，幫助開發(fā)人員編排詳細的工作流/任務，并且需要支持與BPM工具的運行時引擎的完整雙向數(shù)據(jù)交換。在低代碼平臺中，開發(fā)人員將期望輕松操作復雜數(shù)據(jù)（選擇一定數(shù)量的數(shù)組并使用邏輯將它們組合成一組新的數(shù)組），并輕松表示復雜的圖形，而無需自定義樣式/CSS或糾結數(shù)據(jù)格式。

開發(fā)人員可能需要使用父子關系有條件地檢索數(shù)據(jù)，能夠本地化和國際化應用程序，處理部署中自定義應用程序的復雜核心代碼合并和升級，處理推送到已導入的 Swagger 文件的 Swagger 更改而無需重新連接所有變量，編寫和支持與可視化開發(fā)交錯的復雜業(yè)務邏輯，在運行時支持多個應用程序主題， 支持應用作為深層鏈接，設置點擊目標以衡量/啟動意圖或網(wǎng)址等。

規(guī)則 7：無供應商鎖定、限制或細則

對于重視獨立和自由的開發(fā)者來說，鎖定是嚴格的禁忌。這從訪問生成的代碼開始。在這個領域表現(xiàn)良好的低代碼平臺很容易使開發(fā)人員不僅能夠查看和讀取生成的代碼，而且還可以將平臺外部的源代碼導出到他們選擇的IDE。

開發(fā)人員也不喜歡低代碼平臺，這些平臺迫使他們使用運行時環(huán)境來部署應用程序，從而在應用程序的整個生命周期中有效地將開發(fā)人員及其雇主鎖定在平臺中。最后，從許可的角度來看，將開發(fā)人員限制為有限數(shù)量的應用程序、應用程序對象或最終用戶的低代碼平臺有效地將開發(fā)人員限制在商業(yè)模式上，這種模式隨著使用和更多應用程序的使用而迅速變得昂貴。

規(guī)則 8：現(xiàn)代（云原生）環(huán)境、實踐和標準

使用云原生低代碼平臺的開發(fā)人員在協(xié)作、易于訪問、可用性、靈活性、安全性、頻繁且輕松的升級、水平擴展以及用于應用開發(fā)和部署的模型的整體單位經(jīng)濟性方面受益匪淺。

開發(fā)人員友好的低代碼平臺使用現(xiàn)代設計模式（例如，Java maven 項目）生成代碼，使開發(fā)人員能夠跨應用程序堆棧的所有層查看、擴展和自定義代碼。它們使每個用戶都能將工作區(qū)作為容器實例運行。構建應用時，會在低代碼平臺的源代碼管理/Git 中為其自動創(chuàng)建一個存儲庫（并與 Prometheus/EFK 集成以獲取日志和指標）。

最后，開發(fā)人員欣賞采用現(xiàn)代標準的低代碼平臺，例如Android Material Design規(guī)范，用于視覺設計和使用開箱即用的小部件和主題跨多個設備構建交互。他們重視創(chuàng)建功能性、可分發(fā)、可重用、API 集成和可獨立測試的體驗組件的能力。提供十二因素標準的低代碼平臺向開發(fā)人員保證他們的應用程序值得信賴。

規(guī)則 9：很好地使用設計、構建、測試和發(fā)布流程和工具集

使用低代碼平臺的開發(fā)人員希望他們的應用程序連接到其他手動編碼的應用程序、集成或嵌入到其他手動編碼的應用程序中。除了 iFrame 支持之外，支持通過微前端方法嵌入的低代碼平臺（如單 SPA）還為開發(fā)人員提供了復雜的功能，以創(chuàng)建涵蓋高代碼和低代碼開發(fā)應用的無縫端到端體驗。

專業(yè)的應用程序開發(fā)團隊傾向于使用Figma，Sketch或UXPin等設計工具;QA 工具，如硒、量角器或 Karma，用于測試 Web 應用程序;用于測試移動應用程序的Appium;以及性能測試工具和應用程序分析器，如 AppDynamics 或 New Relic。DevOps 團隊擁有大量用于構建、測試、集成和部署過程的工具。部署后，開發(fā)人員希望通過Google Analytics或Adobe Analytics監(jiān)控應用程序性能事件和頁面跟蹤。深受開發(fā)人員喜愛的低代碼平臺必須很好地發(fā)揮作用，并與這些工具集無縫集成，并設計、構建、測試、發(fā)布和監(jiān)控流程。

最后，雖然低代碼平臺可以提供自己的VCS（如Gitlab），但它們需要提供與GitHub或Bitbucket等外部存儲庫的輕松集成。開發(fā)人員應該能夠拉取、查看和推送更改，并合并源代碼管理系統(tǒng)之間的沖突。他們將喜歡低代碼平臺，這些平臺支持從代碼級提交到組件級和應用程序級版本控制（包括主要或次要版本格式）的應用程序版本控制，允許應用程序的多個版本在不同的部署環(huán)境（如測試、暫存或預生產）中共存。

規(guī)則 10：面向未來的我、我的應用和我的雇主

使用低代碼平臺的 UI 開發(fā)人員或后端開發(fā)人員應該能夠開發(fā)完整的應用程序，例如 SQL、JS/Java 和零 DevOps 的基本知識，并轉變?yōu)槿珬ｉ_發(fā)人員。以Java世界為例，開發(fā)人員不需要高級JS框架，HTML5，CSS，Bootstrap，Spring，ORM，REST，高級SQL，本機設備編程，移動集成，構建和運行Docker腳本或與CI / CD管道的手動集成的知識。

對于使用低代碼平臺構建的應用程序的技術堆棧升級，開發(fā)人員應該能夠在具有最新技術堆棧的低代碼平臺的目標版本中打開應用程序（例如，Angular 14 for UI）。應用程序升級應該是自動的，并且過渡是無縫的。

開發(fā)人員和首席技術官/首席信息官都在不斷擔心為未來創(chuàng)造技術債務。企業(yè)友好的低代碼平臺建立在基于開放標準的現(xiàn)代技術堆棧之上，將技術升級的負擔轉移到平臺，提供可使用常用技能集在平臺外部擴展的源代碼，并與現(xiàn)代企業(yè)的工具集、實踐和標準很好地配合使用。

審核編輯：郭婷