最近看到一篇文章，討論一篇國外研究自動修復Bug的系統
這系統是透過機器學習的方式，去識別專案有多少能處理的問題，然後進行自動修復
國外原文是:Recognizing correct code-Automatic bug-repair system fixes 10 times as many errors as its predecessors.
(http://news.mit.edu/2016/faster-automatic-bug-repair-code-errors-0129)
我看到的那討論的文章最後說「碼農失業的日子不遠了嗎」
我並不認同此言論，首先我先灌輸幾個基本觀念
1.Bug的定義是很模糊的
同樣一個系統的行為，可能Ａ認為那是Bug，但可能Ｂ就是想要系統有那樣的行為。
2.Bug的處理範圍有大有小
有的Bug處理上很簡單，搞不好加幾行程式甚至加個驚嘆號就解決了
有的甚至需要改整個程式架構甚至資料庫結構，難度差異很大
3.問題的處理可能超越程式範圍
有些問題可能是來自於資料庫設定或網路設定等環境設定
甚至可能是第三方元件的程式bug
這超越了正常自動修復bug的系統能處理的範圍
這些觀念是我還沒看原文前就有的想法，而我後來看了原文之後，我的觀念和原文並沒有衝突
我對系統運作流程的理解是:
1.學習正確的程式碼
2.識別專案中有多少bug是能處理的
3.對能處理的bug進行修正
我對原文描述內容的理解是:
1.這系統只能處理它的能力能處理的問題，而它的處理能力是會有限的，而不是所有bug都能夠處理
原文提到的測試情況，69個系統問題只有19個能解決
2.處理範圍僅限於程式碼
因為這是要經過正確程式碼的訓練才行的，也就是不包含各種環境的情況
3.處理時間不短
就文章內容來看，如果允許花費12個小時去修一個bug，19個bug可以處理18個(我想這是指最多12個小時處理1個Bug，我想應該不至於很快解決的問題硬拖個12小時吧)
如果允許時間縮短，能處理的bug數量就比較少
如果是人處理的話，真的需要那麼久嗎?
我對這系統在使用上的評論是:
這對程式設計師而言是很有用的，你「有可能」因此節省時間去做更多事情(如果這自動修正系統沒產生更多問題的話XD)
目前visual studio都會對程式問題提供一些選擇方案讓開發者能選擇了，難道要說這是要取代程式設計師嗎???還是該說這其實是在讓開發者開發更方便?(我是傾向於讓開發者開發更方便的想法)
程式設計師根本不該怕說這方面的研究做得太好讓自己失業
一個程式的修正可能有好幾種解法，今天A方法能處理遇到的問題，B方法不能。明天遇到類似的問題，卻可能要用B方法才適合解決
一旦處理方式錯誤，程式設計師可能需要更多時間去做處理
也沒人知道這系統是否會產生其他的潛在bug(但這些問題也只是假設)
留言列表
