程式設計師採用低程式碼開發需要考慮的五件事 – thenewstack

banq發表於2022-02-21

低程式碼工具的使用從商業普通使用者發展到專業程式設計師等更廣泛地採用,一些低程式碼開發工具(如來自 Salesforce.com 和 Zoho 的工具)起源於為普通商業使用者提供的工具;其他(Outsystems 和 Oracle)作為程式設計師的低程式碼開發工具。雖然它們可能看起來相似,但開發體驗的差異在它們的採用中起著重要作用。
雖然低程式碼的潛在生產力提升是真實的並且贏得了很多關注,但基於他們多年來程式碼開發的最佳實踐,專業程式設計師對他們的開發平臺的期望高於業務使用者。我們自己的開發團隊已經經歷過這種情況,因為他們採用了 Oracle 低程式碼平臺來構建 Oracle 的 SaaS 應用程式集。根據我們的經驗,我們希望分享一些技巧,以幫助您的開發團隊為企業級應用程式採用低程式碼。在確定專業開發人員是否會順利採用低程式碼工具時,請考慮這五個標準。
  

1. 低程式碼開發工具應該能直接訪問程式碼
專業開發人員喜歡編碼。檢視程式碼有助於他們瞭解正在發生的事情並以熟悉的方式除錯問題。然而,許多低程式碼工具就像一個黑匣子:你使用視覺化開發工具,平臺就會發揮它的魔力。使應用程式工作的程式碼是隱藏的。如果應用程式出現問題或平臺不支援開發人員需要的功能,這種方法可能會導致問題。
使用提供直接訪問程式碼的工具,專業開發人員會感到更加輕鬆。他們可以深入程式碼檢視以瞭解究竟發生了什麼,甚至可以增強平臺的開箱即用功能。
檢查您使用的平臺是否使頁面佈局和視覺化業務邏輯流的程式碼可訪問和可修改。它是否讓開發人員直接編碼?它是否使用 JavaScript 和 HTML 等標準語言來進行這些修改?開發人員能否同時增強 UI 和業務邏輯層的功能?
  

2. 低程式碼開發工具應該支援團隊開發和 CI/CD
尋找整合和支援功能的低程式碼工具,以支援開發人員越來越喜歡的基於敏捷方法的開發。其中包括用於協作團隊開發的基於 git 的版本管理、自動化應用程式測試的能力、程式碼審計和建立 CI/CD 管道以更快地交付應用程式更改。例如,檢查開發人員是否可以直接為以宣告方式開發的業務邏輯生成自動化測試,以及它們如何適應測試驅動開發等實踐。
  

3. 低程式碼開發工具應該支援模組化
在構建企業級應用程式時,低程式碼工具應支援多個開發人員同時在同一個應用程式上工作——在許多情況下,在同一個頁面上——同時工作。
您的工具應該減少一位開發人員的更改可能與另一位開發人員的更改發生衝突的情況。這就是模組化發揮作用的地方。將一個大頁面分解為可以獨立開發的區域,然後組合成一個完整的解決方案有助於消除衝突。優先考慮微服務而不是單體架構
如果減少此類衝突對您很重要,請尋找兩個開發人員可以將功能新增到同一個 UI 頁面的工具,同時每個開發人員在單獨的檔案中定義他/她的邏輯。一些工具提供頁面片段,這些片段提供頁面的可重用“部分”,可以獨立開發然後組合成單個頁面。
  

4. 低程式碼開發工具應該支援行業標準
大多數開發人員更喜歡市場廣泛採用的技術,這樣他們花在學習新工具和框架上的時間也會為他們的下一份工作服務。這也有助於他們在開發過程中,因為當他們遇到問題時更容易找到幫助。
因此,開發人員更喜歡使用流行語言和標準的低程式碼平臺,而不是專有技術。如果您是 IT 經理,堅持使用非專有平臺可以更輕鬆地找到和招募合格的開發人員。尋找使用 JavaScript/HTML/REST 等標準完成開發的平臺。
這樣,遇到不知道該怎麼做的開發人員就可以在流行的 JavaScript 論壇中搜尋答案。當他們需要訪問外部系統時,他們只需要一個標準的 REST API。這也將讓他們使用他們最喜歡的伺服器端語言為他們的應用程式開發後端,並輕鬆地從該工具訪問它。
 

5. 低程式碼開發工具支援可擴充套件性
一個好的低程式碼平臺將包含大量功能,但您總是會遇到一些開箱即用的東西,例如獨特的 UI 元件或需要實現的複雜邏輯。依賴行業標準的平臺將使擴充套件它們變得更加容易。理想情況下,您將能夠選擇現有的元件和庫,並輕鬆地將它們插入平臺,在那裡可以從低程式碼工具的宣告性介面呼叫它們來建立 UI 和業務邏輯。

相關文章