Ho trovato un ampio elenco di letture su tutti gli argomenti di apprendimento automatico legati alla codifica .
Come puoi vedere, le persone hanno cercato di applicare l'apprendimento automatico alla codifica, ma sempre in campi molto stretti, non solo una macchina in grado di gestire tutti i tipi di codifica o di debugging.
Il resto di questa risposta si concentra sulla vostra macchina di "debugging" relativamente ampia e sul perché questo non sia stato ancora tentato (per quanto riguarda le mie ricerche sull'argomento).
Ho redatto una parte lunga della risposta. Riassumendo (è importante per la parte successiva): seguendo l'attuale metodologia di apprendimento automatico, tutto ciò che un essere umano può imparare, una macchina può anche. Siamo limitati solo dal regno fisico (velocità della CPU, dimensioni di una macchina, ...), non una supposta applicabilità limitata dell'algoritmo di apprendimento stesso.
what research has been done so far in applying machine learning to code development? How about debugging?
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 sono d'accordo. Anche i principi più condivisi come SOLID sono ancora una fonte di discussione per quanto riguarda quanto profondamente deve essere implementato. Per tutti gli scopi pratici, è impossibile aderire perfettamente a SOLID a meno che non si disponga di alcun vincolo finanziario (o temporale) di sorta; che semplicemente non è possibile nel settore privato in cui si verifica la maggior parte dello sviluppo. SOLID è una linea guida, non un limite difficile.
In assenza di una misura oggettiva di giusto e sbagliato, in che modo saremo in grado di fornire un feedback positivo / negativo a una macchina per farla apprendere?
Nella migliore delle ipotesi, possiamo avere molte persone che danno la loro opinione alla macchina ("questo è un codice buono / cattivo"), e il risultato della macchina sarà quindi un "parere medio". Ma non è necessariamente la stessa di una soluzione corretta . Può essere, ma non è garantito.
In secondo luogo, per il debug in particolare, è importante riconoscere che gli sviluppatori specifici sono inclini a introdurre un tipo specifico di errore / bug. La natura dell'errore può in alcuni casi essere influenzata dallo sviluppatore che l'ha introdotta.
Ad esempio, poiché sono spesso coinvolto nella correzione dei bug sul codice degli altri, ho una sorta di aspettativa sul tipo di errore che ogni sviluppatore è incline a fare. Dato un certo problema, so che dev A è probabile che dimentichi di aggiornare il file di configurazione, mentre dev B scrive spesso query LINQ errate. Sulla base dello sviluppatore, potrei guardare prima al file di configurazione o al LINQ.
Allo stesso modo, ho lavorato in diverse società come consulente ora, e posso vedere chiaramente che i tipi di bug possono essere prevenuti verso determinati tipi di società. Non è una regola dura e veloce che posso evidenziare in modo conclusivo, ma c'è una tendenza definita.
Può una macchina imparare questo? Può rendersi conto che il dev A ha più probabilità di rovinare la configurazione e dev è più probabile che B abbia rovinato una query LINQ? Certo che può Come ho detto prima, tutto ciò che un essere umano può imparare, una macchina può pure
Tuttavia, come sai che hai insegnato alla macchina l'intera gamma di possibilità? Come puoi mai fornirlo con un set di dati piccolo (cioè non globale) e sapere per certo che rappresenta l'intero spettro di bug? Oppure, dovresti invece creare debugger specifici per aiutare sviluppatori / aziende specifici, piuttosto che creare un debugger che sia universalmente utilizzabile?
Chiedere un debugger appreso in macchina è come chiedere a Sherlock Holmes un dotto apprendista. Non è probabilmente impossibile crearne uno, ma spesso il ragionamento di base per essere un debugger / Sherlock dipende da valutazioni soggettive che variano da soggetto a soggetto e tocco su 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 progressi.