Po utworzeniu działającego programu możesz chcieć przetłumaczyć go na inny język programowania lub poprawić jakość lub wydajność kodu. Oba zadania należy wykonywać ostrożnie, jeśli w ogóle. Tłumaczenie kodu i optymalizacja kodu to powiązane tematy, ponieważ oba dążą do zmiany kodu w jakiś sposób bez zmiany jego funkcjonalności i celu. W tym rozdziale odkryjesz, jak narzędzia AI mogą pomóc.
Aktualizacja przestarzałej zależności z problemem bezpieczeństwa jest naturalnym wyborem dla automatyzacji. (Inne rodzaje błędów nie mogą być tak łatwo zautomatyzowane). Oprócz sprawdzania zależności projektu, Snyk sprawdza również kod w celu znalezienia typowych problemów, które mogą stanowić błędy bezpieczeństwa. Na liście problemów w widoku Projekty w Snyk możesz zobaczyć element oznaczony jako Analiza kodu, jak pokazano na Rysunku .
Jeśli istnieją problemy związane z analizą kodu, w kodzie znaleziono praktyki, które mogą być lukami w zabezpieczeniach. Możesz kliknąć Analiza kodu, a następnie kliknąć wyświetloną listę, aby wyświetlić więcej informacji. Na przykład Rysunek pokazuje wykryty problem z kodem w grze kółko i krzyżyk AI opisanej wcześniej.
Aby dowiedzieć się więcej o błędzie i uzyskać potencjalne rozwiązanie, kliknij przycisk Napraw analizę w prawym górnym rogu ekranu. Ekran Fix Analysis wyjaśnia, jak naprawić błąd i pokazuje podobne rozwiązanie problemu zaimplementowane w innym repozytorium na podstawie danych treningowych Snyk, jak pokazano na rysunku .
W przeciwieństwie do chatbotów AI, Snyk nie dostarcza rozwiązania Twojego problemu. Jednak patrząc, jak problem został rozwiązany w innym projekcie, możesz dowiedzieć się, jak naprawić go w swoim kodzie. W tym przypadku problem polegał na tym, że użycie właściwości DOM innerHTML do ustawienia danych w przeglądarce, które pochodzą bezpośrednio ze zdalnego źródła, mogło potencjalnie narazić aplikację kliencką na atak typu cross-site scripting (XSS). Aby rozwiązać ten problem, zmieniłem właściwość, aby ustawić tekst w przeglądarce na innerText, co powoduje, że przeglądarka wyświetla dowolny kod, który jest częścią odpowiedzi serwera, jako zwykły tekst, bez próby jego interpretacji.
Pakiety Node używają systemu numerowania wersji zwanego wersjonowaniem semantycznym (w skrócie semver), który ma trzy komponenty w formacie X.Y.Z. Kiedy opiekun pakietu Node wydaje nową wersję, zmienia jeden lub więcej komponentów numeru wersji semver, aby wskazać charakter zmian w nowej wersji. Pierwsza cyfra (X) oznacza główną zmianę wersji: zmianę sposobu korzystania z pakietu. Ten typ zmiany nazywa się zmianą przerywającą, ponieważ uaktualnienie do nowej głównej wersji może spowodować uszkodzenie oprogramowania zależnego od pakietu. Druga cyfra (Y) oznacza podrzędną zmianę wersji: do pakietu dodano nową funkcjonalność, ale stara funkcjonalność nadal działa tak samo. Uaktualnienie z jednej podrzędnej wersji do innej nie spowoduje uszkodzenia programu. Trzecia cyfra (Z) oznacza wersję poprawki: błąd został naprawiony, ale do pakietu nie dodano żadnej nowej funkcjonalności. Zawsze należy uaktualniać do najnowszej wersji poprawki.
W poprzedniej sekcji do mojego projektu zastosowano następujące poprawki:
»»Pakiet jsonwebtoken został uaktualniony z wersji 8.5.1 do 9.0.0.
»»Pakiet mongoose został uaktualniony z wersji 6.7.1 do 6.12.0.
W większości przypadków uaktualnienie do wersji zależności, która nie ma luki w zabezpieczeniach, nie spowoduje uszkodzenia kodu ani dodatkowych błędów. Niemniej jednak nadal ważne jest, aby w pełni zrozumieć i przetestować wszelkie automatyczne poprawki błędów. Ponieważ uaktualnienie jsonwebtoken było poważnym uaktualnieniem (liczba po lewej stronie zmieniła się z 8 na 9), znacznie bardziej prawdopodobne jest, że będę musiał naprawić coś innego w moim kodzie. Aby dowiedzieć się, czy nowa wersja pakietu uszkodzi kod, zacznij od przejrzenia dziennika zmian nowej wersji, który jest listą wersji, przez które przeszedł pakiet, przy czym każdy element na liście wskazuje, co zostało zmienione. W przypadku większych zmian pakiety mogą również zawierać notatki dotyczące migracji, które wyjaśniają zmiany, które należy wprowadzić w kodzie, aby obsługiwać nową wersję. Rysunek przedstawia notatki dotyczące migracji z wersji 8 do wersji 9 jsonwebtoken.
Po wprowadzeniu wszelkich niezbędnych uaktualnień do kodu określonego w notatkach dotyczących migracji lub dzienniku zmian należy ponownie uruchomić testy, aby upewnić się, że nadal przechodzą.
Snyk może naprawić niektóre problemy znalezione w kodzie lub zależnościach. Wykonaj następujące kroki, aby zastosować automatyczne poprawki w swoim repozytorium kodu:
Żądanie ściągnięcia (PR) sugeruje i wyjaśnia konkretną zmianę w repozytorium kodu; nie zmienia niczego w repozytorium, dopóki właściciel repozytorium nie zatwierdzi żądania ściągnięcia.
3. Zaznacz lub odznacz problemy, które chcesz naprawić za pomocą Snyk, a następnie kliknij przycisk Otwórz żądanie naprawienia błędów. GitHub wyświetla żądanie ściągnięcia wygenerowane przez Snyk, jak pokazano na rysunku
Po zintegrowaniu poprawek błędów z repozytorium możesz przenieść zmieniony kod do kodu lokalnego i uruchomić testy, aby sprawdzić, czy nadal działa zgodnie z oczekiwaniami.
W idealnym świecie asystent AI mógłby automatycznie skanować kod i sugerować poprawki, zamiast polegać na ręcznym wykrywaniu błędów lub wklejaniu kodu do chatbota. Dzięki integracji wykrywania błędów i poprawek opartych na AI z cyklem życia rozwoju oprogramowania możesz znaleźć i naprawić wiele typów błędów i problemów z bezpieczeństwem, których nie można wykryć za pomocą linterów i o które nigdy nie pomyślałbyś, aby zapytać swojego asystenta kodowania AI.
Chociaż użycie lintera kodu i formatera kodu może pomóc Ci pisać lepszy kod i unikać wielu typowych błędów, problemy, które nie zostaną wykryte podczas tworzenia, zostaną znalezione w procesie testowania lub przez użytkowników końcowych oprogramowania. Narzędzia do debugowania inne niż AI przybierają wiele różnych form, ale generalnie wszystkie działają w ten sam sposób. Kiedy coś nie działa tak, jak oczekujesz w swoim kodzie, możesz użyć narzędzia do debugowania, aby przerwać działanie programu w miejscu, w którym występuje problem, i użyć narzędzia do debugowania, aby zobaczyć, co dzieje się ze zmiennymi, nasłuchiwaczami zdarzeń i innymi typami kodu. Przerywając program lub po prostu wyprowadzając wartości z kodu, możesz zacząć odkrywać, co może być nie tak. Dwa najważniejsze narzędzia w debugowaniu to rejestrowanie i punkty przerwania. Rejestrowanie to proces pisania wiadomości zawierających informacje o uruchomionym programie i występujących błędach. W JavaScript moduł konsoli i jego metoda log() są często używane do rejestrowania. W Pythonie możesz użyć instrukcji print() lub modułu rejestrowania. Punkty przerwania to miejsca w kodzie, w których wskazujesz (za pomocą debugera), że chcesz, aby wykonywanie programu zostało wstrzymane, podczas gdy sprawdzasz zmienne programu. Przeglądarki internetowe mają narzędzie do debugowania, którego możesz użyć podczas debugowania kodu JavaScript uruchomionego w przeglądarce. Rysunek przedstawia narzędzie do debugowania wbudowane w Google Chrome.
Nawet przy użyciu narzędzia do debugowania, ustalenie, co jest nie tak w programie i jak to naprawić, może wiązać się z wieloma frustrującymi pracami. A dziewięć razy na dziesięć problem okazuje się literówką. Czatboty AI, takie jak Copilot Chat lub ChatGPT, często mogą uwolnić Cię od części ręcznej pracy debugowania, śledząc przyczyny problemów i sugerując poprawki. Podobnie jak we wszystkim, co robisz z generatywnymi modelami AI, kluczem do uzyskania dobrych wyników jest zapewnienie wystarczającego kontekstu dla modelu i prawidłowe podpowiadanie AI.
Poniższy listing przedstawia funkcję języka Python zawierającą co najmniej dwa proste błędy na poziomie jednostki:
def calculate_average(numbers):
total = 0
for number in numbers:
if not isinstance(number, (int, float)):
raise TypeError(“Invalid data type. All values must
be numbers.”)
total += number
average = total / len(numbers)
return average
Pod względem składni funkcja calculated_average() jest w porządku. Problem polega jednak na tym, że funkcja oczekuje otrzymania listy liczb, ale nie sprawdza, czy przekazany jej argument jest listą. Zgodnie z zapisem, jeśli przekażesz tej funkcji wartość, która nie jest listą, zostanie wygenerowany błąd TypeError, wskazujący, że wartości muszą być liczbami, co w rzeczywistości nie jest problemem. Ponadto, jeśli przekażesz funkcji pustą listę, zostanie wygenerowany błąd ZeroDivisionError.
Rysunek pokazuje, jak uruchomić funkcję i spowodować błąd TypeError.
W mojej pierwszej próbie zmuszenia chatbota AI do naprawienia błędu otworzyłem plik zawierający funkcję w VS Code i wpisałem /fix w Copilot Chat. Copilot Chat zidentyfikował problem ZeroDivisionError, jak pokazano na rysunku . ale nie rozwiązał problemu, co się dzieje, gdy przekazujesz funkcji wartość, która nie jest listą.
Zaktualizowałem swój kod sugestią Copilota, a także przykładem wywołania funkcji za pomocą ciągu znaków i poprosiłem Copilota o ponowne poprawienie. Tym razem Copilot prawidłowo wskazał, że niepoprawnie wywoływałem funkcję i pokazał mi, jak wywołać ją za pomocą listy liczb, ale nie rozwiązał problemu z funkcją. Następnie wysłałem następujący monit:
Jak mogę naprawić funkcję, aby nie zgłaszała błędu, gdy nie otrzyma listy?
W tym bezpośrednim pytaniu Copilot odpowiedział kodem, który naprawia problem, który chciałem naprawić. Oto poprawiony kod:
def calculate_average(numbers):
if not isinstance(numbers, list):
return “Error: Input should be a list of numbers.”
if len(numbers) == 0:
return None
total = 0
for number in numbers:
if not isinstance(number, (int, float)):
raise TypeError(“Invalid data type. All values must
be numbers.”)
total += number
average = total / len(numbers)
return average
print(calculate_ave rage(‘a’))
Wiele pozostałych błędów zgłoszonych przez ESLint było związanych z zasadami stylu. Na przykład ESLint zgłosił w kilku przypadkach, że wiersze kodu powinny być wcięte o osiem spacji, a nie sześć. W tym przypadku style formatowania wymuszane przez formater kodu Prettier kolidują ze stylami sprawdzanymi przez ESLint. Zamiast ciągle próbować pogodzić te dwa style, zmienię zasady. Fani Star Treka rozpoznają to jako sytuację Kobayashi Maru. W obliczu scenariusza bez wyjścia bądź jak kapitan Kirk i zmień zasady.W kwestiach formatowania kodu, jeśli Twój linter i formater kodu się nie zgadzają, dostosuj zasady lintera. Aby ESLint ignorował wcięcia kodu, możesz zmodyfikować jego plik konfiguracyjny. Ustawienia dla całego projektu dla ESLint znajdują się w pliku o nazwie .eslintrc, który znajduje się w katalogu głównym Twojego projektu. W zależności od tego, jak skonfigurujesz swój projekt, .eslintrc może mieć rozszerzenie, takie jak .cjs lub .mjs. Plik .eslintrc zawiera obiekt konfiguracji z różnymi właściwościami. Możesz przeczytać o wszystkich właściwościach w .eslintrc, przechodząc do https://eslint.org/docs/ latest/use/configure/. Właściwością, której możesz użyć do dostosowania tego, co ESLint zgłasza jako błąd, jest właściwość rules. W tym projekcie React właściwość rules zawiera obecnie tylko jedną regułę, jak pokazano na rysunku
Reguły ESLint modyfikują domyślne zachowanie ESLint i wtyczek ESLint. Reguła zaczyna się od nazwy reguły, po której następuje poziom ważności tej reguły. ESLint ma trzy poziomy ważności dla reguł:
»»Wył. lub 0 wyłącza regułę.
»»Ostrzeżenie lub 1 włącza regułę, ale tylko jako ostrzeżenie, co oznacza, że nie zatrzyma kompilacji kodu, ale należy się tym zająć.
»Błąd lub 2 włącza regułę jako błąd, który uniemożliwi kompilację kodu.
Po uruchomieniu ESLint nazwa każdej reguły, którą narusza Twój kod, jest wyświetlana po prawej stronie raportu lintingu, a waga naruszenia reguły jest po lewej stronie, jak pokazano na rysunku
Gdy raport lintingu pokazuje coś jako błąd, ale uważasz to za problem niekrytyczny lub niebędący błędem, skopiuj nazwę reguły z raportu lintingu i dodaj ją do obiektu rules. Na przykład, Rysunek pokazuje, jak wyłączyć regułę jsx-indent, która obecnie koliduje z Prettier.
Aby rozwiązać pozostałe problemy, wyłączyłem kilka innych reguł, które kolidowały z Prettier lub których nie uważałem za problem, usunąłem nieużywaną funkcję i poprawiłem sposób korzystania z funkcji useState() React.
Jeśli najedziesz kursorem myszy na dowolny kod z czerwoną falistą linią, w wyskakującym oknie zobaczysz link Szybka poprawka, jak pokazano na rysunku
Kliknij łącze Szybka poprawka, aby wyświetlić opcje automatycznego rozwiązania problemu, jak pokazano na rysunku
Jeśli masz zainstalowany GitHub Copilot, zobaczysz opcje naprawy lub wyjaśnienia błędu za pomocą Copilot. Aby dowiedzieć się więcej o błędzie i zobaczyć, jak Copilot naprawi go, kliknij opcję Wyjaśnij za pomocą Copilot. Pojawi się panel czatu Copilot z wyjaśnieniem (czasami znacznie bardziej szczegółowym niż jest to konieczne) problemu i proponowanym rozwiązaniem, jak pokazano na rysunku
Jeśli zgadzasz się z sugestią Copilot, możesz samodzielnie wdrożyć poprawkę lub użyć funkcji Napraw za pomocą Copilot w menu podręcznym Szybka poprawka, aby Copilot wdrożył poprawkę samodzielnie. Jeśli klikniesz opcję Napraw za pomocą Copilota, nad kodem w kwestii otworzy się okno ze zmianą, którą Copilot chce wprowadzić do Twojego kodu. Możesz zaakceptować lub odrzucić zmianę. Rysunek pokazuje, co pojawiło się, gdy poprosiłem Copilota o naprawienie problemu nieużywanych zmiennych w moim kodzie.
Oryginalny kod jest pokazany po lewej stronie, a proponowany nowy kod jest pokazany po prawej stronie. Podświetlony na czerwono kod po lewej stronie zostanie usunięty, jeśli zastosujesz zmiany. Podświetlony na zielono kod po prawej stronie zostanie dodany do Twojego pliku, jeśli zastosujesz zmianę. Obszary po prawej stronie oznaczone liniami ukośnymi reprezentują puste miejsce, którego nie będzie w kodzie, gdy go zaakceptujesz. (Copilot dodaje te linie, aby zmieniony kod był zgodny z oryginalnym kodem.) .Jak widać na Rysunku , Copilot może próbować wprowadzić znacznie większe zmiany w kodzie niż tylko naprawić pojedynczy błąd, o który prosiłeś. W przypadku nieużywanej zmiennej, poprawnym rozwiązaniem byłoby po prostu usunięcie pojedynczego wiersza kodu zawierającego nieużywaną zmienną. Kiedy przejrzałem proponowane zmiany, zobaczyłem, że Copilot naprawiał kilka problemów z kodem naraz. Byłem ciekaw, czy liczba moich błędów lintingowych zmniejszy się o więcej niż jeden, jeśli zastosuję poprawki, więc zaakceptowałem proponowane zmiany. Po tym, jak Copilot wprowadził swoje „poprawki”, ponownie uruchomiłem ESLint, aby zobaczyć, ile błędów naprawił Copilot. Jednak ESLint zgłosił, że mój kod ma teraz o siedem błędów więcej niż przed próbą naprawy przez Copilot, jak pokazano na Rysunku
Nacisnąłem Ctrl+Z, aby cofnąć sugestię Copilota i zastosowałem oczywistą (i poprawną) poprawkę, którą pierwotnie zasugerowało narzędzie Explain. Tym razem, gdy ponownie uruchomiłem ESLint, liczba błędów lintingu spadła o jeden.
Po zgłoszeniu przez ESLint znalezionych błędów, dołącza on komunikat informujący, że niektóre z nich można potencjalnie naprawić, używając opcji –fix. Wykonaj poniższe kroki, aby użyć opcji –fix i zobaczyć, co ESLint może zrobić z tymi błędami.
“scripts”: {
“dev”: “vite”,
“build”: “vite build”,
“lint”: “eslint . –ext js,jsx”,
“preview”: “vite preview”
},
“scripts”: {
“dev”: “vite”,
“build”: “vite build”,
“lint”: “eslint . –ext js,jsx”,
“lintfix”: “eslint . –ext js,jsx –fix”,
“preview”: “vite preview”
},
Po uruchomieniu skryptu lintfix liczba problemów z kodem może się zmniejszyć, jak pokazano na rysunku .
ESLint jest ostrożny ze zmianami, które automatycznie wprowadza do kodu, więc użycie opcji –fix zazwyczaj nie spowoduje awarii. W następnej sekcji dowiesz się, jak używać AI do korygowania pozostałych problemów w kodzie.