天天看點

到 2030 年,軟體開發人員可能會被淘汰

編者按:軟體正在蠶食世界。軟體正在滲透到虛拟和現實世界的一切——甚至包括軟體世界本身。是的,越來越多的軟體工作正在被自動化,自動化測試、自動化程式設計。着不僅讓人擔心,軟體到頭來會不會蠶食掉軟體開發者的崗位呢?從某種意義上來說,是的。但從另一種意義來說,不是。且看看Rhea Moutafis的分析。原文發表在Medium上,标題是Software developers might be obsolete by 2030。
到 2030 年,軟體開發人員可能會被淘汰

軟體開發是狗屁工作嗎?我不這麼認為。

劃重點:

随着越來越多的流程被自動化,軟體開發的很多工作大概會變成狗屁工作

軟體自動化的三個層面:1)輔助軟體開發 2)封閉系統的自動化 3)內建系統的自動化

人類的确有很多機器不擅長的特質,但是軟體開發不是光靠這些

計算機很擅長流形的處理和規模化

“從長遠來看,唯一重要的是對計算的利用”

軟體開發人員這個職業在很長一段時間内依然令人興奮

開發者要向管理的方向轉移,從極客變成領袖

将來所有的企業都會變成軟體企業,需要把軟體放在優先的位置

1930年,約翰·梅德·凱恩斯(John Maynard Keynes)曾做出預測,到那個世紀末,我們每周将隻需要工作15小時。但是時間一直拖到了2013年,結果證明這位偉大的經濟學家顯然搞錯了。

歡迎來到狗屁工作(Bullshit Jobs)時代,這個詞是人類學家大衛·格雷伯(David Graeber)(編者注:《狗屁工作》的作者)的發明。自1930年代以來,全新的産業如同雨後春筍般地出現,但那些行業未必能為我們的生活增添太多的價值。Graeber大概會把軟體開發裡面大多數的工作稱為狗屁工作。

我不同意格雷伯的想法,尤其是在軟體方面。但是他确實提出了一個有趣的觀點:随着越來越多的流程被自動化,大多數工作到了一定時候也許都會被淘汰。根據一項估計,利用目前技術可以讓45%的工作自動化。而随着時間的流逝,情況也許會是這樣的。

在發展日新月異的軟體開發行業,你可以親眼目睹這種情況:一旦軟體測試成為熱門話題後,自動化工具便開始興起。而這隻是衆多領域的其中一員——我是指軟體當中那些狗屁工作,那些重複性的耗時的工作都會被自動化掉。

不過,這會引出一個問題,那就是開發人員開發自動化工具是不是自掘墳墓,把自己給淘汰掉了。如果越來越多的機器可以自己編寫代碼的話,那還需要人類幹什麼?

從設計邏輯到設計思想

軟體開發人員本質上是建設者。他們開發邏輯連結,算法,程式,項目等。關鍵是:他們開發具有邏輯性的東西。

不過,随着人工智能的興起,我們看到了範式正在轉移。開發人員不再設計邏輯連結。相反,他們正在根據這些邏輯連結的啟發去訓練模型。

許多開發人員已經從建構邏輯轉變為開發思想。換句話說,越來越多的軟體開發人員正在從事資料科學家的活動。

自動化的三個層面

如果你曾經用過IDE的話,你應該知道輔助軟體開發已經發展到什麼程度。一旦用慣了自動補充完成或語義代碼搜尋之類的功能,你就再也離不開這些。

這是軟體開發自動化進軍的第一個領域。當機器知道了你想實作的目标時,它們就可以幫助你完成相關過程。

第二個領域是封閉系統。不妨想想社交媒體app是什麼樣的:裡面包含了衆多彼此連結在一起的不同頁面。但是,由于在設計上它不能直接跟其他的服務通信,是以屬于封閉系統。

盡管用于開發此類app的技術變得越來越易于使用,但我們還不能說實作了真正的自動化。到目前為止,如果想要建立動态頁面,使用變量,應用安全規則或內建資料庫,你還是需要編碼。

第三個,也是最後一個領域是內建系統。比方說,銀行API就是這樣的系統,因為它是為了跟其他的服務通信而開發的。不過,目前想實作自動化的ATM內建、通信、對世界模組化、深度安全性以及進行複雜的故障排除幾乎是不可能的。

随着時間的推移,這三個領域都取得了不同程度的發展。如今,前兩個領域已實作了自動化,不過第三個領域還沒有實作自動化。

到 2030 年,軟體開發人員可能會被淘汰

自動化的三個領域。軟體開發這條路坎坷不平,未來何時到來真的無從知曉。

計算機眼裡的世界

在被問到将來自己會不會被機器人所取代時,人類的打勞工通常不會這麼認為。這一點同樣适用于軟體開發等許多其他領域。

他們的理由很明确:創造力,同理心,協作,或者批判性思維,這些特質不是計算機的擅長。

但是對于把工作完成來說,這些東西通常不是關鍵。哪怕是最複雜的項目,也會包含有很多可以自動化的一小部分。就像DeepMind科學家理查德·S·薩頓(Richard S. Sutton)所說那樣:

“研究人員尋求利用自身掌握的本領域的人類知識,但是從長遠來看,唯一重要的是對計算的利用。”

不要誤會我的意思。人的素質還是非常出色的。但是,就正常任務而言,我們一直高估了這些問題的重要性。比方說,很長一段時間以來,甚至連研究人員都認為機器永遠也沒法識别出照片上面的那些貓。

現如今,一台機器可以一次性地對數十億張照片進行分類,并且準确性比人類還要高。雖然機器也許欣賞不了小貓的可愛,但它在處理未定義狀态方面非常出色。這是的,就是機器眼中小貓照片的狀态:未定義的狀态。

向新流形和規模化邁進

除了處理未定義狀态以外,還有兩件事情計算機執行要比人類更高效:首先是規模化的處理。其次是對新穎流形的處理。

我們都體會過計算機規模處理的效果如何。比方說,如果你要求計算機執行 print(” I am so stupid”) 200次,它會毫無怨言地把你的抱怨列印200次,而且不到一秒鐘就能把這件事兒幹完。如果你讓人去辦,你需要等幾個小時才能完成……

流形基本上代指的是分享一組特定屬性的空間子集(局部具有歐幾裡得空間性質的空間),是一種用數學表示的複雜形式。比方說,如果你拿出一張紙,那它就是在三維空間裡面的二維流形。如果把紙張弄皺,或者把它折疊到平面上,它仍然是流形。

事實證明,計算機确實很擅長處理人類難以可視化的流形,比方說,因為它們可以延伸到20維,或具有大量複雜的彎折和邊。由于很多的日常問題(比方說人類的語言或計算機代碼)都可以用數學流形表示,是以未來有很大的潛力可以部署真正有效的産品。

到 2030 年,軟體開發人員可能會被淘汰

新穎流形與可伸縮性的圖示。自動化的區域位于左下角。

關于計算機可伸縮性以及對新穎流形的探索我們目前所處的位置。我們目前正在研究區域一和區域二,但區域三幾乎還沒有觸及。

現狀目前的進展

似乎開發人員已經在運用了很多的自動化。不過這隻是因為我們正好處于軟體自動化的風口浪尖而已。到目前為止,對內建系統進行自動化幾乎是不可能的。但是其他領域已經在自動化。

一方面,代碼評審和調試可能很快就會變成過去的遺迹。瑞士公司DeepCode正在開發一種用于自動識别錯誤的工具。Google的DeepMind已經可以針對原有代碼推薦更優雅的解決方案。Facebook的Aroma可以自行自動完成小型的程式。

此外,機器推斷代碼相似性系統(Machine Inferred Code Similarity System,簡稱MISIM)據說可以像Alexa或Siri能了解人類語言那樣去了解計算機代碼。有一點令人興奮,那就是這樣的系統可以讓開發人員把常見且耗時的任務自動化掉,比方說把代碼推送到雲端或者實施合規性流程。

令人興奮的曙光

到目前為止,所有這些自動化在用到小型項目上的時候都可以很好地工作,但在面對較複雜的項目時卻基本不管用。比方說,錯誤識别軟體仍然會傳回很多的誤報,而且如果項目有一個非常新穎的目标的話,自動完成功能就不起作用了。

由于MISIM出現的時間還不長,是以對這種自動化下定論還為時尚早。不過,需要牢記的是,這隻是開始,而且這些工具有望在将來變得越來越強大。

即将推出的應用

這些新型的自動化會有一批早期應用。其中可能包括對人類活動的跟蹤。當然,這并不意味着那就是間諜軟體。相反,類似安排勞工的工作時間或者給學生定制課程之類的事情可以通過這種方式來予以優化。

這本身就是一個巨大的經濟機會,因為學生可以更快地學習到重要的東西,而勞工可以在他們正好更有效率的時間幹活。

如果MISIM的表現就像它的承諾一樣好的話,那也可以用來重寫遺留代碼。比方說,很多銀行和政府軟體都是用COBOL編寫的,這種股東語言學校今天幾乎已經不教了。把這些代碼轉換成更新的語言也會讓維護變得更加容易。

軟體開發人員這個職業在很長一段時間内依然令人興奮。

開發人員和公司如何才能立于不敗之地

所有這些新應用的确令人興奮。但在它們的頭上,一把達摩克利斯之劍正在鑄就:如果競争對手在你趕上前就利用了這些自動化技術的話,該怎麼辦?如果它們導緻開發人員變得完全過時了,又該怎麼辦?

要對持續傳遞和自動化測試進行投資

這無疑是自動化世界裡面的兩個熱詞。但是不管怎樣,這兩個東西仍然很重要。

如果你不對軟體進行測試就釋出出去的話,可能會損害使用者體驗,或者在将來遇到安全問題。經驗表明,自動化測試能夠涵蓋測試人員甚至都沒有想到但是卻可能非常關鍵的用例。

也有越來越多的團隊加入到持續傳遞的實踐,這是有充分的理由的。當你捆綁了很多的功能,而卻要每三個月才釋出一次更新的話,在接下來的幾個月的時間往往就得用來修複在此過程中出現的所有問題。這種做法不僅阻礙了軟體的快速開發,而且還損害了使用者體驗。

測試有大量的自動化軟體,而持續傳遞有版本控制(以及衆多的其他架構)。在大多數情況下,購買這些自動化解決方案似乎要比自己開發更好些。畢竟,你的開發人員招進來是要開發新項目的,不是把無聊的任務自動化掉。

如果你是經理,要把買這些東西當作是一筆投資。這樣以來,你就可以為開發人員提供最好的支援,因為你可以讓他們發揮自己真正擅長的東西。

向左移:讓開發者參與到每一個項目的早期階段

項目一般是高層或者接近研發團隊的某個地方建立,然後再層層傳遞到開發團隊的,到了這個時候開發團隊采取負責把這個項目的想法變成現實。

但是,由于并不是每一位項目經理都是經驗豐富的軟體工程師,是以項目一部分可能是由開發團隊實施,而有的要麼是成本太高,要麼就是幾乎不可能由自己實作的。

在過去,這種做法有它的合理性。但是,鑒于軟體開發大量單調乏味的部分被自動化,開發人員将有機會變得越來越有創造性。

這是一個讓開發者抽身出去的極好機會,那就是讓他們參與到項目的計劃階段。這不僅是因為他們知道哪些可以實作,哪些不能。而且憑借他們的創造力,他們可能會以你想象不到的方式為項目增加價值。

把軟體放在首位

現在距裡微軟的薩蒂亞·納德拉(Satya Nadella)宣布“每一家企業都會變成軟體企業”已經過去了五年。結果證明,他是對的。

開發人員不僅應該向管理的方向左傾。軟體的優先地位也應該提升。

如果說目前的這場疫情能讓你學到些什麼的話,那就是現在很多的生活以及價值創造都發生在網上。

軟體為王。但自相沖突的是,自動化的程度越高,這一點就越明顯。

自動化讓軟體極客變成領袖。

總結:極客正在變成領袖

我上學那時候,喜歡計算機的人王婉被認為是不善交際的孩子,是書呆子,怪胎,跟大家不一樣的生物,是缺乏人類情感和激情的,像僵屍一樣的動物。其實真希望我這是在誇大其詞。

不過,時間越久,就會有越多的人看到開發人員的另一面。寫代碼的不再被看作是書呆子,而是可以做出很酷的東西的聰明人。

自動化程度越高,軟體的獲得的權力就越大。從這個意義上來說,你對開發者由于自動化而失去工作的擔心是沒有根據的。

當然,在十年之内——甚至在幾個月内——你也許就要做你現在甚至無法想象的事情了。但這并不意味着你的工作将會消失。不會的,相反,它會更新。

你真正需要克服的恐懼并不是你可能會失業。你需要擺脫的是對未知的恐懼。

開發者們,你不會被淘汰。你隻是再也不會是書呆子了。相反,你會成為上司者。

推薦閱讀:

不是你需要中台,而是一名合格的架構師(附各大廠中台建設PPT)

阿裡徹底去中台了,你真以為中台不行了?

網易架構師朱劍鋒:網易中台的博弈與演進

網易嚴選資料中台建設之道

小米中台架構分享,小米市值2690億是因為這群可愛的人

【中台實踐】華為大資料中台架構分享.pdf

繼續閱讀