隨著IDE的不斷升級,普通開發者的手工編碼是否會被完全取代?

現在不少IDE都提供了很多很智能的GUI,根據選項就可以自動編碼,以後這種趨勢會越來越強嗎?是否意味著開發者的門檻會越來越低?


程序員的工作是programming,不是coding,更不是typing,謝謝。


中學的時候參加過樂高機器人比賽(具體叫啥比賽不記得了)。這種比賽所用的機器人(樂高 NXT 機器人)使用一種叫做 NXT-G 的編程語言進行機器人編程。這個 NXT-G 長什麼樣呢?

(圖片來自網路,侵刪

只需要拖動這些方塊,配合功能性的控制選項(循環、分支)就可以完成整個機器人的程序編寫。

題目說,「現在不少IDE都提供了很多很智能的GUI,根據選項就可以自動編碼」,其終極形態也不過是像 NXT-G 一樣的圖形化編程。

這樣的編程形式門檻低不低?用這東西連一門編程語言都不要學。但是要完成一個機器人比賽項目仍然需要從邏輯到流程到細節上的分析設計構建。這幾乎已經是編程的全部了,省去了「輸入代碼」這個步驟對於編程的難度沒有任何實質性的降低。而 NXT-G 採用圖形化編程意義也僅僅是讓 NXT 機器人面向的人群(小、中學生)在接觸的時候少一點枯燥乏味而已。並且使用這種方式到底是讓開發變得複雜還是簡便了呢……我手寫代碼幾十百多行的邏輯,用這個寫滾動條展開可能長達幾米。

(所以我最後還是換成了 C 語言編碼……


寫代碼從來就不是程序員的痛點,痛點是寫出結合需求的代碼。

寫代碼從來就不是程序員的痛點,痛點是寫出結合需求的代碼。

寫代碼從來就不是程序員的痛點,痛點是寫出結合需求的代碼。

技術一直在進步,但是需求一直在變化。


1、除了一些專用領域(比如數據分析)的工具,我還沒見到過通用的IDE能夠根據選項自動編碼的。那些專用工具是預先準備了足夠多的功能組件,然後讓業務開發人員根據業務需要重新組合組合。那些成熟領域的業務開發人員的技術門檻確實可能越來越低,對業務的掌握要求反而更高。當然那些功能組件自身和專用工具自身仍然是要編碼出來。

2、在通用編程方面,現代IDE在代碼生成方面確實已經很強,按個快捷鍵就能生成try catch塊等等,但是軟體開發生產率的瓶頸從來都不在敲(輸入)代碼的速度,而在於找到你要修改的那行代碼然後正確的修改的效率,IDE提供的各種navigator的功能會成為編程高手的利器,而沒頭蒼蠅式debug的開發人員會被反襯的更加低效。


如果你的普通開發者是指把別人的代碼直接抄過來用的人,那麼是的。


謝邀。

先上結論:編程這件事,工具會不斷更新,因此固守任何一種特定工具的編程行為都必將被機器取代;然而編程行為本身的變化相當小,因此真正會編程——而非僅僅會使用某些特定編程工具——的軟體開發者不會被取代。

(還真有十個贊呢,那就多說兩句吧……)

(歡迎繼續點贊,要是點贊多的話我就繼續延伸)

===== 2016-05-14更新 =====

這個問題比乍看上去要來得更好,因為如果你追問「軟體開發者的門檻是什麼」,就會自然地引出下一個問題:什麼是軟體開發

阿蘭-圖靈在他的論文《On Computable Numbers, with an Application to the Entscheidungsproblem》中,通過一個想像的計算機器(理想圖靈機)推出了一個重要的結論:可計算的問題總數是一階無窮大,這個數量與有理數的總數相同,記為aleph(0);而世界上所有可能的問題總數是二階無窮大,這個數量與實數的總數相同,記為aleph(1),且aleph(1)=2^aleph(0)。

換句話說,這個世界上絕大多數、幾乎所有的問題都是不可計算的

所以廣義上的「軟體開發」這件事,實際上有三個組成部分。即,給定一個想要解決的問題A:

  1. 識別問題A是否可計算;
  2. 如果問題A不可計算,將其轉變或簡化為一個可計算的問題B;
  3. 以計算機(準確說,馮-諾伊曼結構實現的圖靈機)可運行的方式描述問題B。

在上述三個組成部分中,與軟體開發工具(包含但不限於IDE)相關的實際上只是第3部分。前兩個部分,尤其是第1部分,顯然等價於停機問題,因此不可計算。

用簡單直白的話來說,軟體開發這項工作的門檻不僅在於「編碼」,更在於「知道該編什麼碼」,而後者是比前者困難得多、且無法被計算機取代的。因此,更好的軟體開發工具(例如IDE)會取代只會前者(「編碼」)而不會後者(「知道該編什麼碼」)的軟體開發者,從而使得軟體開發者的門檻越來越高——或者不變,因為這種「只會編碼」的軟體開發者從來沒有正經被當作軟體開發者看待過。

延伸閱讀:

  • 《圖靈的秘密》-連圖靈的論文都沒讀過怎麼好意思說自己做軟體。

  • 《人月神話》-「沒有銀彈」中的偶發複雜度與本質複雜度,實際上講的是同一回事。


因為在現實世界裡抽象泄漏是不可避免的,所以除非強AI出現,否則絲毫不用擔心


如果搬磚被機器人所替代,那麼蓋一棟大樓是不是門檻更低了呢?顯然搬磚被取代跟項目決策,設計大樓,公關,可行性分析,招投標,造價管理,施工管理,物業管理是沒有什麼關係的(蝴蝶效應不算啊)。

PS: 反而開發商不再招聘搬運工了,進入建築領域的門檻更高了。


反而門檻會更高,因為手工被完全取代了,剩下的就是腦力勞動,腦袋跟不上還好意思說自己是開發者?


在某些做外包管理系統項目的公司里已經有這個趨勢了。不過不是因為ide。

我以前上培訓班的時候,金蝶出來的老師就說他們那裡最叼的是代碼生成器,選好選項,一直點下一步,最後就出來一個項目的大部分代碼,其餘的碼畜們往裡面填部分一定要人來寫的業務代碼就行。

但是這種事情也就出現在做管理系統的外包公司里。因為項目結構簡單,要求簡單,性能要求也低,在那裡做事的,大概也不能被稱作程序員。


有人邀請,正好也一直在面對和思考這個問題,就隨便說兩句。

這個問題提的很巧妙,其中應當注意的是這個定語「普通開發者」,這一點上我的回答基本是肯定的。

雖然從業人員大多拿著較高的薪水,但可以說軟體開發中的大多數活並不高大上,甚至十分的「臟」和「累」。看看現實中,那些也一樣臟和累的活從業人員的情況,隨著越來越多的人的參與,我們基本可以判斷這個行業的最終的一個走勢。當然,現有從業人員可能不這麼想,但在資本家和少數精英的不斷努力下,隨著技術的進步和成熟,這個工作會變的十分平凡和普通。而這一切應該會發生在智能機器代替人類活動之前。

當然,重點我們還是要從技術上考察這件事情的可行性。實際上目前軟體中的臟活累活並不是那麼簡單的,所以從業人員沒有那麼容易被取代,同時如果不是看在薪水的份子上,真正願意為別人做這些看起來「臟累」的活估計也很少。對這些「臟活累活」有需求的人而言,他們也並不希望為此付出太多,或者因為無法付出而眼睜睜得看著機會錯失,因為一個完全的虛擬的世界在頭腦中模擬一下看起來是如此的簡單。軟體的組成對應到現實中也會是一個比較複雜的世界,儘管在的階段下,從業人員整體的水平等因素已經使得其發展的速度要遠遠超過現實世界,但離可見的目標還有一定的距離。

但是任何時候,只要人類活動還存在,這些臟活累活都是必不可少的,甚至是人類活動的主要組成部分。隨著信息社會的發展,這系列的需求將會推及到每一個人的身邊,各種異想天開的主意將會遍布社會的各個角落裡。這將不斷推動技術的更新和發展來降低人們滿足這些需求所需要的成本,也就是說普通開發者變得十分便宜。在機器代替人類工作之前,唯一可以解放的就是讓這些臟活累活變得十分簡單,或者是相對的從業人數大大增加,甚至每個人只要願意就可以完成相應的工作,就和現實中已經存在和那些臟活累活一樣。

或許可以問,為什麼不是個人水平提高到和現在開發者水平一樣,甚至更高呢?這個要看人類進化的發展,我對此不報信心。相反,如果讓每個人都集中精力於代碼中的瑣碎的話,那麼絕不是什麼福音,一定是人類變笨了,技術停滯了。當然,如果人類一直發展下去,可以不斷逼近無所不能的所謂「超人」,但那會是十分遙遠的事情,甚至可能會在機器代替人類之後。

最後一句話就是,在真正的軟體開發行業里,這是一直以來的目標,而且已經取得了不少進展。從個人電腦到智能手機的普及也逐步驗證著上文中的內容,我們還需要一系列偉大的軟硬體產品來不斷推進信息時代的發展。


我到覺得像企業ERP、CRM這種東西可以考慮做成Wordpress這種直接安裝的軟體,每次都聘用廉價勞動力寫一遍有意義嗎?整天將溝通、需求這種非技術性的因素掛在嘴上,為什麼不事先想清楚?完事再吐槽程序員情商低,這種場景最適合由程序來生成,最好是漢語拼音命名配合中文注釋


IDE不會降低門檻,只能提高效率。


真正的趨勢是以後代碼都是ai自己寫的,人只需要給出輸入輸出的case的訓練樣本就好


自動生成確實能在快速開發中節省時間,同時將一些重複的勞動(搬磚)節省出來。

但是自動生成還是不能取代一切,而且有些時候,流水線造出的磚頭,未必能合適現在的房子。因此需要二次手工加工,所以過分依賴自動生成的民工(碼農),在需要手工加工時就會不知所措


推薦閱讀:

「Monokai」這個詞是什麼意思?
如何評價Tinyfool在swiftcon大會上發言跑題被罵一事?
為什麼好多編程「牛人」不喜歡用Microsoft Visual Studio?

TAG:軟體開發 | 編程 | 集成開發環境 | 編碼 |