在我年輕的時候，我的一個好朋友的叔叔被一輛派對巴士撞死了。在他的葬禮上，人們在悲傷之余不禁在想：他怎么不在看見那輛巴士或聽見聲音的時候躲開呢？同樣，當我聽說程序員因為低代碼軟件而丟掉工作的時候，我的腦子里也蹦出了類似的疑問。顯然，他們也應該躲開低代碼軟件這輛派對巴士??！

我朋友的叔叔躲不開，因為他身處夾點，無處可躲。這篇文章將介紹程序員會遇到的低代碼夾點以及如何躲開它們。

場景設定

我們繼續(xù)用派對巴士這個比喻，并假設你是一家大中型企業(yè)的軟件開發(fā)人員。你和你的團隊負責構建、部署和維護公司使用的各種應用程序。有些應用程序是你們自己開發(fā)的，有些是現(xiàn)成的，需要定制或集成。

突然間，你發(fā)現(xiàn)有很多用戶在開發(fā)自己的低代碼應用程序。你應該擔心這個嗎？我覺得大可不必。

大型企業(yè)里的夾點并不多

從 2010 年開始，隨著流程自動化工具 Blue Prism 和 UIPath 的崛起，你或許已經(jīng)看到自動化給金融和人力資源領域的工作人員帶來的戲劇性影響。這是因為這些領域存在很多夾點。當應付賬款業(yè)務被自動化，從事該業(yè)務的工作人員很難再轉(zhuǎn)到其他崗位，因為整個相關的工作崗位都消息了。

但軟件工程與應付賬款不同。你的工作量是由軟件能夠給企業(yè)帶來多少價值決定的。你可以看一下自己目前的工作內(nèi)容。如果你所在的團隊與其他大部分 IT 團隊一樣，那么應該會有很多開發(fā)新應用程序的需求以及給已有應用程序添加新功能的需求。如果說自動化可以讓這些需求減少，那等同于說速度更快的汽車可以把你載到火星上。如果低代碼軟件承擔了你的部分工作，你還有其他項目可以做。如果處理得當，你甚至可以把一些棘手的項目丟給低代碼。

自動化的引入可能會深化而不是減少軟件工程師的工作?！猂alph Aboujaoude Diaz， HFS Research

其次，軟件工程的某些方面比較難以自動化，所以低代碼派對巴士很難開過這個地形。

例如，非開發(fā)人員可以使用低代碼工具做出數(shù)據(jù)表，但如何讓這些數(shù)據(jù)表跟他們要解決的業(yè)務問題映射起來，這些工具并不會提供太多幫助。

低代碼工具也讓非開發(fā)人員構建和部署應用程序變得更容易，但這些工具并不會確保相關人員會參與項目的各個部分，以遵循風險和合規(guī)規(guī)約。

隨著低代碼在你的企業(yè)當中傳播開來，作為軟件工程師，你花在寫代碼上的時間變少了，花在工作其他方面的時間變多了，而不是失業(yè)。

對于大部分軟件工程師來說，隨著低代碼軟件在企業(yè)內(nèi)部的鋪開，他們將有更多的機會為公司創(chuàng)造更多的價值，不需要做那些無聊的重復性工作。——Jan Oberhauser，n8n CEO

撇開比喻，我們說的是哪種類型的項目？

低代碼軟件可以被用在很多種不同的項目中，從流程自動化到幫助用戶提升效率的應用程序。在你閱讀這篇文章的同時，想象以下的某個場景：

1. 一款房地產(chǎn)經(jīng)紀人用來向客戶發(fā)送合同日期提醒的應用程序；
2. 一款讀取醫(yī)療記錄并識別沒有得到優(yōu)先治療的病人的后臺應用程序；
3. 一款通過抽取保單相關字段來構建機器學習模型的應用程序。

“解剖”一個軟件項目

有很多書教我們?nèi)绾螛嫿ㄆ髽I(yè)級軟件項目（可以閱讀 Blair Reeves 的《構建企業(yè)級軟件》）。為了契合本文的主題，我們把一個軟件項目分為四個階段：

1. 計劃和整體設計；
2. 構建；
3. 部署；
4. 維護。

為了幫助大家更好地理解低代碼軟件是如何影響大家的工作的，我們來看一下低代碼在上述的每一個階段都具備哪些能力。

1. 計劃和整體設計階段

在這四個階段當中，這是低代碼最后一個可以取代的階段。計劃和整體設計階段涉及很多事情，從讓相關人員參與其中，確保有足夠的預算和資源來構建和維護應用程序，到檢查是否在構建對的應用程序。例如，假設你在一家房產(chǎn)公司工作，這家公司的客戶抱怨要很長時間才能拿到合同文本。解決這個問題有很多種方法，但使用哪種方法取決于對造成這種延遲的原因的了解程度以及掌握了哪些降低延遲的方法。短期來看，低代碼工具還無法做出這種分析。

2. 構建階段

這是低代碼軟件可以發(fā)揮核心作用的階段。在進行整體設計之后，你的團隊或業(yè)務用戶就可以用低代碼軟件很快地做出應用程序。在這個階段，低代碼軟件的關鍵優(yōu)勢是它們可以幫助你的用戶決定什么才是他們真正需要的。他們不用畫草稿和溝通需求細節(jié)，而是不斷迭代解決方案，直到獲得他們想要的東西。

低代碼的一個關鍵點是它抽離了基礎設施的復雜性，就連非專業(yè)人員也可以構建和部署非常復雜的應用程序。——Rick Lamers， Orchest CEO

這個階段仍然還有一些地方需要團隊的參與——那些低代碼解決方案無法處理的棘手問題。例如，如何抽取房產(chǎn)客戶聯(lián)系人的相關數(shù)據(jù)？如何在沒有標準訪問接口的情況下訪問某些政府的數(shù)據(jù)集？如何構建可以基于風險對索賠進行分類的機器學習模型？如果說你們不具備這方面的專業(yè)知識，一些新興的公司，如 Managed Functions，可以處理這些問題。

3. 部署階段

低代碼在這個階段最為狂野。各種低代碼平臺都提供了不同的部署方式。

• RPA（機器人流程自動化）公司提供了統(tǒng)一控制中心，負責處理應用程序的部署和維護任務。這解決了部署和維護問題，但代價是你的團隊需要使用各種不同的工具來部署和維護低代碼應用程序。
• 微軟構建了兩種類型的低代碼應用程序。一種是帶有圖形界面，給業(yè)務用戶用，一種是基于代碼的，給開發(fā)人員用。開發(fā)人員可以使用現(xiàn)成的工作流來部署應用程序。
• AWS 和谷歌還沒有確定該如何解決這個問題。
• 還有成百上千的低代碼應用程序提供了各種不同的解決辦法。

結果是，你的團隊需要制定指南，告訴人們要如何處理這些事情以及由誰來處理。我之前的系列文章中已經(jīng)提到過這些。有了指南之后，低代碼平臺有助于大家遵循指南——但這是 IT 的責任，而不是業(yè)務人員的。

4. 維護階段

這個是最為蹊蹺的一個階段。軟件的維護涉及問題修復和功能增強。大部分企業(yè)沒有設立專門的業(yè)務團隊來處理這個問題，但他們需要參與，因為是他們自己構建了這些應用程序，他們是唯一知道這些應用程序來龍去脈的人。

隨著時間的推移，低代碼可以更好地處理這個階段的問題，但仍然需要軟件工程師和業(yè)務人員的共同參與。

要避免的夾點

如果你是大中型企業(yè)的軟件工程師，并且與業(yè)務人員溝通順暢，那么久不需要有太多的擔心。你總是能找到為公司創(chuàng)造價值的方法。

但是，低代碼仍然會給兩個領域的軟件工程師造成較大的影響，如果你在這兩個領域中，就需要注意一下發(fā)展趨勢：

1. 小型公司（或者大公司的小型技術團隊）；
2. 應用程序開發(fā)公司。

對于小型公司來說，使用低代碼軟件比自己開發(fā)應用程序更說得過去。對于小型公司的 CEO 來說，他或她需要決定的是要雇一個 React 程序員來開發(fā)一個新的定制化應用程序（然后期望這個程序員不要離職、退休或死掉）還是使用低代碼軟件來開發(fā)一個。很顯然，會選擇后一個選項。在這些公司工作的軟件工程師會丟掉他們的飯碗，或者轉(zhuǎn)去為公司開發(fā)低代碼應用程序。

應用程序開發(fā)公司的大量崗位將會消失。在這些公司，初級和中級開發(fā)人員很少有機會能夠像公司直招的工程師那樣發(fā)揮他們的溝通技能。如果你是一個負責寫代碼和構建 ETL 管道的初級或中級工程師，看一下你的周圍，如果你的周圍有很多同事做著同樣的事情，那么是時候考慮一下該如何增強你的溝通和面對客戶的技能了。

結論

技術變革在緩慢地發(fā)生，然后薄積厚發(fā)。我們似乎正處在低代碼革命的轉(zhuǎn)折點。在接下來的幾年，我們將看到軟件工程師的工作發(fā)生戲劇性的變化。如果你避開了這些夾點，對于你來說就是好日子。

作者簡介

Doug Hudgeon 是Managed Functions的首席執(zhí)行官。這是一家集成公司，專門幫助低代碼和 RPA 團隊更快地交付項目，通過提供定制組件來處理他們在項目中可能遇到的棘手問題。這些組件可以作為無服務器函數(shù)部署到云端(AWS、Azure 或 GCP)。他也是曼寧《商業(yè)機器學習》一書的合著者，這本書向用戶展示了如何使用 AWS SageMaker 解決現(xiàn)實世界的商業(yè)問題。你可以在推特上找到他。

原文鏈接：

[How to Not Lose Your Job to Low-Code Software](