Ho trovato un elenco di letture piuttosto esteso su tutti gli argomenti di apprendimento automatico relativi alla codifica .
Come puoi vedere, le persone hanno cercato di applicare l'apprendimento automatico alla codifica, ma sempre in campi molto ristretti, non solo una macchina in grado di gestire tutti i tipi di codifica o debug.
Il resto di questa risposta si concentra sulla tua macchina di "debugging" relativamente ampia e sul perché questo non è stato ancora veramente tentato (per quanto mostra la mia ricerca sull'argomento).
Ho redatto una lunga parte della risposta. Riassumendo (è importante per la parte successiva): seguendo l'attuale metodologia di apprendimento automatico, tutto ciò che un essere umano può imparare, anche una macchina può farlo. Siamo limitati solo dal regno fisico (velocità della CPU, dimensioni di una macchina, ...), non da una presunta limitata applicabilità dell'algoritmo di apprendimento stesso.
quale ricerca è stata fatta finora nell'applicare l'apprendimento automatico allo sviluppo del codice? Che ne dici di debug?
Il problema qui non è che è impossibile, ma piuttosto che è un argomento incredibilmente complesso.
Gli umani non si sono nemmeno avvicinati alla definizione di uno standard di codifica universale con cui tutti concordano. Anche i principi più ampiamente condivisi come SOLID sono ancora fonte di discussione quanto profondamente deve essere implementato. Per tutti gli scopi pratici, è impossibile aderire perfettamente a SOLID a meno che non si abbia alcun vincolo finanziario (o temporale); che semplicemente non è possibile nel settore privato in cui si verifica la maggior parte dello sviluppo. SOLID è una linea guida, non un limite rigido.
In assenza di una misura oggettiva di giusto e sbagliato, come potremo dare un feedback positivo / negativo a una macchina per farlo apprendere?
Nella migliore delle ipotesi, possiamo avere molte persone che danno la propria opinione alla macchina ("questo è un codice buono / cattivo"), e il risultato della macchina sarà quindi un "giudizio medio". Ma non è necessariamente lo stesso di a soluzione corretta . Può essere, ma non è garantito che lo sia.
In secondo luogo, per il debug in particolare, è importante riconoscere che specifici sviluppatori sono inclini a introdurre un tipo specifico di bug / errore. La natura dell'errore può in alcuni casi essere influenzata dallo sviluppatore che l'ha introdotto.
Ad esempio, poiché sono spesso coinvolto nella correzione di errori di codice di altri sul lavoro, ho una sorta di aspettativa sul tipo di errore che ogni sviluppatore è incline a fare. Dato un certo problema, so che dev A probabilmente dimenticherà di aggiornare il file di configurazione, mentre dev B scrive spesso cattive query LINQ. Sulla base dello sviluppatore, potrei prima guardare al file di configurazione o al LINQ.
Allo stesso modo, ho lavorato come consulente in diverse aziende e posso vedere chiaramente che tipi di bug possono essere distorti verso determinati tipi di aziende. Non è una regola dura e veloce che posso sottolineare definitivamente, ma c'è una tendenza definita.
Una macchina può imparare questo? Può rendersi conto che dev A ha maggiori probabilità di incasinare la configurazione e dev B ha maggiori probabilità di incasinare una query LINQ? Certo che può. Come ho detto prima, tutto ciò che un essere umano può imparare, anche una macchina.
Tuttavia, come fai a sapere che hai insegnato alla macchina l'intera gamma di possibilità? Come puoi mai fornire un set di dati piccolo (cioè non globale) e sapere per certo che rappresenta l'intero spettro di bug? Oppure, creeresti invece debugger specifici per aiutare specifici sviluppatori / aziende, piuttosto che creare un debugger universalmente utilizzabile?
Chiedere un debugger appreso in macchina è come chiedere un Sherlock Holmes appreso in macchina. Non è dimostrabile impossibile crearne uno, ma spesso il ragionamento fondamentale per essere un debugger / Sherlock dipende da valutazioni soggettive che variano da soggetto a soggetto e toccano una varietà incredibilmente ampia di conoscenze / possibili difetti.
La mancanza di risultati corretti / errati rapidamente dimostrabili rende difficile insegnare facilmente a una macchina e verificare che stia facendo buoni progressi.