低程式碼、快速的應用程式開發和數字轉換的挑戰問題 -Bozho

banq發表於2020-05-30

最近，許多低碼/無碼解決方案在企業中得到了發展，從而使非技術人員可以選擇建立簡單的應用程式。分析人士預測，低碼行業將以每年20％以上的速度增長。但是什麼是低碼，為什麼它如此流行，它又有什麼問題呢？
低程式碼是我們在過去幾十年間偶爾看到的東西–拖放式UI設計器，使您可以建立簡單的應用程式而無需編碼技能。產品已經成熟，並且幾乎都提供了類似的功能-在拖放式實體關係圖中設計實體關係的能力，透過所見即所得設計UI的能力，透過類似於BPMN的符號設計簡單流程，透過以下方式呼叫外部服務的能力匯入Web服務定義，以便從預烘焙的實體定義中進行選擇，以及在外部資料庫和電子表格中獲取和儲存資料。
該領域中有許多工具– MS PowerApps，OutSystems，Appian，Mendix，Google最近收購的AppSheets，Ninox，WaveMaker等。而且它們的方法和功能集可能略有不同，但總的要點是能夠輕鬆建立應用程式（基於Web，基於移動裝置，混合），以解決這些使用者遇到的一些即時難題。一個成熟的IT專案及其相關的開發成本實在是過大了。
這聽起來很棒–您不必依靠非IT公司中過於忙碌且反應不頻繁的IT部門，您只需自己構建一些東西就可以最佳化您的緊迫問題並數字化您的書面流程。我們必須承認，專業開發人員不可能無處不在，無法解決資訊科技可以解決的所有問題。這樣的工具使數字化轉型民主化，允許非技術人員建立軟體。
或至少這是理論。實際上，這在許多方面都具有挑戰性：
  • 需要一些技術知識 -能夠繪製實體關係圖很酷，但是首先您需要知道什麼是資料模型。能夠匯入Web服務並能夠呼叫它是很好的，但是您必須知道Web服務是什麼。整合使用者目錄意味著您知道什麼是LDAP / AD。我不確定非技術人員能否真正利用這些功能。即使開啟一個新對話方塊，某些工具仍然需要簡單的程式碼，並且您必須從某個地方複製貼上該程式碼。
  • 與本地系統整合 –構建有用的東西幾乎總是需要與現有系統整合。假設一切都在“雲”中是很好的，但是從第三方SaaS的角度來看，即使雲也可以視為內部部署。我見過的許多工具都透過提供IP，使用者名稱和密碼來與資料庫整合-幾乎從來沒有，這是一個壞主意。連線到機構基礎結構中某物的能力（即使該基礎結構在Azure上並且您正在使用MS PowerApps）也意味著許可權，網路規則配置，帳戶，批准。而且您必須知道要求什麼才能得到它。
  • 供應商鎖定 –大多數低程式碼工具使用專有格式進行元描述（例如，有些甚至將其後設資料的二進位制表示形式儲存在本地sqlite資料庫中）。一些提供程式允許您透過安裝他們的伺服器端應用程式在自己的雲上執行該應用程式，但是一些純粹是SaaS。使用一種工具構建應用程式後，就無法真正切換到另一種工具。WaveMaker和Skyve是很好的例外，它們會生成實際的Java程式碼，您可以隨時下載它們。鎖定不好嗎？好吧，是的–如果碰巧您需要尚不可用的功能或尚不存在的整合功能，那麼您將陷入困境。
  • 影子IT –假定組織中的所有IT均由IT部門進行管理和觀察。在監視，安全性，合規性，資料保護，生命週期管理，技術支援等方面。使用低程式碼，這些應用程式可以存在，而IT部門甚至不知道它們，並且帶來許多風險（我將在下面討論）
  • 可持續性 –如果一家低程式碼公司倒閉，或者被決定淘汰某個產品或一系列功能的人收購，該怎麼辦？當建立低程式碼應用程式的員工離開並且沒有人知道如何使用所選工具進行“程式設計”以支援該應用程式時，會發生什麼？低程式碼應用程式本身成為舊版時會發生什麼？由於供應商鎖定並且缺乏任何標準化，因此在可持續性方面承擔著很大的風險。當然，您將以某種方式解決當前的問題，但是您可能會在此基礎上建立更多的問題。
  • 安全性 –一方面，使用PaaS / SaaS可能被視為內建安全性。另一方面，非技術人員無法評估給定平臺的安全性。安全性不能完全“內建” –您必須確保需要身份驗證，在列入白名單的辦公地點之外看不見應用程式，未經授權的人員不能匯出資料，並且必須保護自己XSS，CSRF，SQLi等。即使平臺提供了這些選項，非技術人員也不知道他們必須首先照顧它們。
  • 合規性 –許多行業受到監管，並且有橫向法規，例如資料保護法規（GDPR，CCPA）。資料洩露經常發生是因為資料是從其原始的受良好保護的儲存中取出的，並儲存在資料保護人員不知道的地方（例如低程式碼應用程式）。加密，匿名化，資料最小化，保留期–大多數低程式碼解決方案都不支援這些功能，不熟悉這些細節的員工不太可能花更多的精力來相容該應用程式。
  • 無法控制的錯誤–當您的軟體中存在錯誤時，可以對其進行修復。如果它在庫中，則可以對其進行修補。如果在第三方平臺的一組工具中，您將無能為力。在測試幾種低程式碼解決方案的過程中，我偶然發現了許多錯誤和不一致之處。


從RAD到RPA
有趣的是，低程式碼是更廣泛技術堆疊的一部分。它們以“快速應用程式開發”（RAD）工具和框架開始，以“無程式碼”（也就是功能較少的無程式碼替代品）結束。像Spring Roo這樣的程式碼生成工具是OpenXava這樣的RAD框架。某些低程式碼工具實際上可以看作是RAD工具：開發人員團隊可以很容易地使用上述WaveMaker來快速交付較簡單的專案，而無需犧牲過多的控制權。
然後是RPA，即“機器人流程自動化”，我將直截了當簡化為“螢幕抓取的低程式碼”，您可以使涉及舊系統的某些流程自動化，而這些流程只能透過按下“機器人”來提取資訊並執行操作螢幕上的按鈕。
RPA稍微不在快速的應用程式開發範圍之內，但是它帶來了一個重要的點：RPA開發人員。他們的技術水平不高，不具備開發人員資格的人員，但仍可以使用RPA工具實現流程自動化。低程式碼和RAD的某些風格也是如此：假定您不必一定要開發某些技術，但是實際上可以（並且有）專門的專家可以使用這些工具來構建東西。他們不是真正的開發人員，

我希望每個人都能夠在高階RAD工具的幫助下至少編寫簡單的程式碼。而且我們可能會在幾十年內一直這樣。

相關文章