譯者 | 牛昊天

Thoughtworks 第 28 期技術雷達中提出，市場中低代碼平臺能力在近些年取得巨大進步，但依然主要集中在解決中低復雜度場景問題，當面對復雜的業務場景時，仍然存在一定的平臺限制。所以建議企業考慮采用低代碼技術前，仔細深入評估自己的需求和低代碼技術之間的平衡——有界限地使用低代碼平臺。

主要要點

• 低代碼采用率正在增長，但它只適用于某些特定場景，并非所有場景。
• 低代碼被認為是傳統開發流程和實踐的替代方案。但決策者需要了解其限制，并圍繞應用程序開發建立適當的防護措施。
• 在決定是否選擇低代碼之前，先提出正確的問題，以確定它是否適合特定的應用程序需求。

低代碼工具和平臺，可以使不同團隊創建有價值的軟件系統，而無需編寫和維護大量的自定義代碼庫，這為低代碼工具贏得了幾乎相等數量的支持者和批評者。

然而，一些預測顯示，到2025年，使用低代碼工具和平臺創建的新應用程序比例可能高達70％。而持續存在的開發人員短缺，正在推動企業探索加快軟件交付和減輕工作負擔的新方法，因此越來越多的組織開始探索低代碼能為他們做什么。

低代碼工具和平臺的能力在近些年取得了顯著的發展，但質疑仍然存在——這是有一定道理的。盡管低代碼工具有潛力增強新一代所謂的“公民開發人員”的能力，并通過低代碼實現簡單功能的搭建，進而減輕開發團隊的壓力，但事實是它們仍然并不適用于每種開發場景。

確定低代碼是否適合你，并最終獲得它可能為你的業務帶來的價值的第一步，是了解它最適合什么樣的場景。

何時（以及何時不）使用低代碼

有很多因素會促使組織采用低代碼方式開發。以下是最常見的四種情況，以及低代碼在每種情況下的適用性：

場景＃1：應對開發人員短缺

由于全球范圍內對開發人才的需求仍然遠超過供給，所以能夠讓用戶構建強大軟件的工具前景非常引人注目。但如果只是因為組織中缺乏成熟的開發和編碼技能，而選擇采用低代碼技術，可能會帶來不必要的麻煩。

如果沒有熟練的開發人員和IT專家來監督業務團隊使用低代碼創建的內容，你將得到“沒有策略支持的軟件”：業務部門也許會不斷地定制不同的應用，來解決數字化需求，但它們之間幾乎無法關聯或聚合。這將是一種無法擴展的場景，并且與平臺化思維等領先實踐完全不一致。IT 領導層需要制定相應策略，并采取適當的措施，允許在適當的情況下開發低代碼應用或解決方案，使業務用戶能夠在不產生大型復雜問題（技術債務、無法擴展的系統等）的情況下解決重要問題。

場景＃2：支持業務快速增長

對于早期階段的擴張，低代碼可以幫助快速創建新功能和服務，而無需大幅投入開發資源，這反過來也能保證他們的軟件不會成為組織快速發展的瓶頸。

然而，這些組織需要認識到，他們使用低代碼平臺創建的某些解決方案最終可能必須被替換掉。否則，他們可能會發現其基礎設施的核心部分是建立在欠靈活的基礎上的。而這對于許多使用低代碼構建的應用程序來說的確是一個挑戰。

為了從低代碼中獲得最大價值，成長中的企業應該使用它來快速創建他們需要的功能，但要做好規劃和準備，在未來某個階段它們不再被需要時，用更強大的功能取而代之。

場景＃3：構建新的核心業務軟件

軟件對你的業務越重要，低代碼就越不可能成為構建和維護它的首要選擇。這并不是因為低代碼缺乏構建關鍵應用程序的能力或復雜性，而是因為這類應用需要能夠輕松擴展、增長和轉型，而并不是所有低代碼平臺和工具都具備這樣的能力。

即使你的應用最初設計很適合低代碼，但如果它對你的業務極端重要，那么未來設計很有可能需要發展。你可能需要添加更復雜的功能，將其與其他應用程序集成或將其遷移到新的企業平臺。如果業務部門和 IT 部門之間的合作沒有進行適當的規劃，這些事情就會變得更加困難。 

場景＃4：增強業務部門能力

如果你的目標是賦予業務部門更大的技術自主權，并使他們成為公民開發人員，那么采用低代碼工具是一個很好的方法。大部分低代碼工具和平臺是易于用戶上手，團隊可以快速開始管理和增強功能以滿足自己的需求。

需要注意的是，即使他們手中擁有最直觀的工具，IT 部門也應該參與低代碼工具的選擇、規劃和擴展。并非所有低代碼工具都是一樣的，選擇具有足夠可擴展性、可伸縮性并且可以集成到更廣泛的 IT 生態系統中的工具非常重要。 

平衡的重要性

當低代碼首次出現時，圍繞該技術的大部分敘述將其定位為傳統開發的替代方案——它將減少甚至消除組織對熟練開發人員的依賴。

事實證明，這種描述完全站不住腳，無論是它對低代碼設定的不切實際的期望，還是它如何將低代碼和傳統開發流程定位為敵人或對立面。

問題不應該是“低代碼還是傳統代碼？”而應該是“低代碼在哪里可以最好地支持和補充我們的專家開發人員？”

通過在正確的場景中啟用和鼓勵低代碼（通常是增強小型業務團隊使用的軟件功能），你可以加速交付、縮短周期時間并快速s滿足業務需求，而無需完全廢除當前的開發實踐。 

在保留核心 IT 和開發團隊提供的所有控制、治理和戰略輸入的同時，增強業務部門能力并加速交付。兩全其美是可能的，但前提是你取得了適當的平衡。

在選擇低代碼平臺之前，領導者需要回答五個問題

在你開始選擇低代碼平臺或工具集之前，確定低代碼是否非常適合你當前的業務和需求非常重要。

你需要進行一些深入的評估，但回答以下這些問題會是一個很好的起點：

(11) 有多少人會使用你正在構建的軟件？

更多的用戶意味著更多的需求要適應，他有可能成為組織的核心業務軟件，并擴展到低代碼安全區域以外的位置（需要評估考慮結合傳統開發）。

(2) 你想構建的是核心軟件還是支持（邊緣）軟件？

你的軟件越接近核心業務，那么盡可能地保持其靈活、可擴展和系統間關聯性就越重要——你需要重新評估是否全部應用低代碼技術來構建和維護它。

(3) 隨著采用率的不斷提高，你現在構建的軟件是否會變得至關重要？

如果你已經知道需要構建或現代化的軟件系統對業務極其重要，這恐怕不會是低代碼的使用場景，除非你愿意接受低代碼平臺的限制。

(4) 你的團隊準備好成為公民開發者了嗎？

為了讓低代碼發揮其全部的潛在價值，你的團隊需要有足夠的熱情采用它，并開始創建自己的應用。他們還需要有一定的軟件應用熟練度，以及正確的心態，才能創建真正有價值的應用。

(5) 你真正想解決什么問題？

例如，如果你希望清除大量積壓的工作，那么可能有比采用低代碼更好的方法來實現這一目標。你可能試圖解決流程效率低下的問題，而不是解決潛在的挑戰。當然，你還是可以定義出通過低代碼解決方案才能滿足的特定需求。 

低代碼并非萬能的，但它能教給我們很多東西

低代碼并不是代碼的替代品。如果一個組織放棄他的開發團隊，并使用低代碼平臺完全將開發控制權交給業務團隊，那么他們在實現目標方面將非常受限。

但對于特定的場景，低代碼仍然是一項非常強大的技術。它提供了快速填補能力差距的手段，為部分用戶組的邊緣軟件構建帶來新的可能，并使業務團隊能夠在需要時 DIY 實現自己需要的應用。

通過將低代碼與傳統代碼和開發實踐相結合，組織可以在不犧牲核心軟件所需的靈活性和可擴展性的情況下，賦予公民開發人員部分權力。這才是真正應用低代碼的甜頭 - 應用在特定場景并解決非常具體業務部門需求；由IT專家監督，并與傳統開發實踐和資源結合應用 - 而不是取代它們。

低代碼的定義

有很多平臺稱自己為“低代碼” - 但這意味著什么呢？根據我們的經驗，低代碼通常用于描述允許用戶使用可視化拖拉拽等方式創建業務邏輯和界面的平臺。

通常，它們比無代碼平臺更可配置和可定制，盡管兩者之間有相當大的重疊。低代碼工具通常也允許一些（少量）“真正”的代碼 - 通常是所謂的腳本語言，如JavaScript - 來執行常規可視化拖拉拽工具無法完成的任務，例如更復雜的業務邏輯。