Znalazłem dość obszerną listę lektur na wszystkie tematy związane z uczeniem maszynowym związanym z kodowaniem .
Jak widać, ludzie próbują zastosować uczenie maszynowe do kodowania, ale zawsze w bardzo wąskich dziedzinach, nie tylko maszynie, która może obsłużyć wszystkie rodzaje kodowania lub debugowania.
Pozostała część odpowiedzi skupia się na twojej stosunkowo szerokiej maszynie do „debugowania” i dlaczego tak naprawdę nie została jeszcze podjęta próba (o ile pokazują moje badania na ten temat).
Zredagowałem długą część odpowiedzi. Podsumowując (ważne w następnej części): postępując zgodnie z obecną metodologią uczenia maszynowego, wszystko, czego człowiek może się nauczyć, może także maszyna. Ogranicza nas jedynie sfera fizyczna (szybkość procesora, wielkość maszyny, ...), a nie domniemana ograniczona możliwość zastosowania samego algorytmu uczenia się.
jakie badania przeprowadzono dotychczas w zakresie zastosowania uczenia maszynowego do opracowywania kodu? Co powiesz na debugowanie?
Nie chodzi tu o to, że jest to niemożliwe, ale o to, że jest to niezwykle złożony temat.
Ludzie nawet nie zbliżyli się do zdefiniowania uniwersalnego standardu kodowania, z którym wszyscy się zgadzają. Nawet najszerzej uzgodnione zasady, takie jak SOLID, są nadal źródłem dyskusji na temat tego, jak głęboko należy je wdrożyć. Ze względów praktycznych nie jest możliwe całkowite przestrzeganie SOLID, chyba że masz jakiekolwiek ograniczenia finansowe (lub czasowe); co po prostu nie jest możliwe w sektorze prywatnym, w którym następuje największy rozwój. SOLID jest wytyczną, a nie twardym limitem.
W przypadku braku obiektywnej miary dobra i zła, w jaki sposób będziemy w stanie przekazać maszynie pozytywne / negatywne informacje zwrotne, aby mogła się uczyć?
W najlepszym wypadku możemy sprawić, że wiele osób wyrazi swoją opinię na temat maszyny („to jest dobry / zły kod”), a wynik maszyny będzie wtedy „przeciętną opinią”. Ale to niekoniecznie to samo, co prawidłowe rozwiązanie . Może być, ale nie ma takiej gwarancji.
Po drugie, szczególnie w przypadku debugowania ważne jest, aby pamiętać, że konkretni programiści są skłonni do wprowadzania określonego rodzaju błędu / pomyłki. Na charakter błędu może w niektórych przypadkach wpływać programista, który go wprowadził.
Na przykład, ponieważ często jestem zaangażowany w naprawianie błędów w cudzym kodzie w pracy, mam pewien rodzaj błędu, który każdy programista może popełnić. Biorąc pod uwagę pewien problem, wiem, że dev A może zapomnieć o aktualizacji pliku konfiguracyjnego, podczas gdy dev B często pisze złe zapytania LINQ. W zależności od dewelopera mogę najpierw spojrzeć na plik konfiguracyjny lub LINQ.
Podobnie, pracowałem teraz w kilku firmach jako konsultant i wyraźnie widzę, że rodzaje błędów mogą być stronnicze w stosunku do niektórych rodzajów firm. Nie jest to trudna i szybka zasada, którą mogę jednoznacznie wskazać, ale istnieje wyraźny trend.
Czy maszyna może się tego nauczyć? Czy może zdawać sobie sprawę, że dev A może zepsuć konfigurację, a dev B może zepsuć zapytanie LINQ? Oczywiście że tak. Jak powiedziałem wcześniej, wszystko, czego człowiek może się nauczyć, może także maszyna.
Skąd jednak wiesz, że nauczyłeś maszynę pełnego zakresu możliwości? Jak możesz kiedykolwiek dostarczyć mu niewielki (tj. Nie globalny) zestaw danych i wiedzieć, że reprezentuje on pełne spektrum błędów? A może zamiast tego stworzyłbyś konkretne debuggery, aby pomóc konkretnym programistom / firmom, zamiast tworzyć debuger, który byłby uniwersalnie użyteczny?
Pytanie o uczonego maszynowo debuggera jest jak proszenie o uczonego maszynowo Sherlocka Holmesa. Stworzenie takiego nie jest niemożliwe, ale często głównym powodem debuggera / Sherlocka są subiektywne oceny, które różnią się w zależności od tematu i dotyczą niewiarygodnie szerokiej gamy wiedzy / możliwych wad.
Brak szybko dających się udowodnić poprawnych / niepoprawnych wyników utrudnia łatwe nauczenie maszyny i sprawdzenie, czy robi dobre postępy.