譯者 | 牛昊天

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

主要要點

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

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

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

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

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

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

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

場景＃1：應對開發(fā)人員短缺

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

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

場景＃2：支持業(yè)務快速增長

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

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

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

場景＃3：構建新的核心業(yè)務軟件

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

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

場景＃4：增強業(yè)務部門能力

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

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

平衡的重要性

當?shù)痛a首次出現(xiàn)時，圍繞該技術的大部分敘述將其定位為傳統(tǒng)開發(fā)的替代方案——它將減少甚至消除組織對熟練開發(fā)人員的依賴。

事實證明，這種描述完全站不住腳，無論是它對低代碼設定的不切實際的期望，還是它如何將低代碼和傳統(tǒng)開發(fā)流程定位為敵人或?qū)α⒚妗?/p>

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

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

在保留核心 IT 和開發(fā)團隊提供的所有控制、治理和戰(zhàn)略輸入的同時，增強業(yè)務部門能力并加速交付。兩全其美是可能的，但前提是你取得了適當?shù)钠胶狻?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

低代碼的定義

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

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