Summary

To darmowe narzędzie jest sprawdzarką opartą na regułach, a nie modelem AI. Wklejasz git diff albo fragment kodu, a ono przegląda dodane linie pod kątem trzynastu reguł: zaszytych sekretów, SQL składanego ze stringów, połkniętych wyjątków i wyłączonych testów. Oznacza też zbyt duże zmiany i brakujące testy, po czym zwraca wynik 0-100 z numerami linii. Działa w całości w przeglądarce i ma usunąć mechaniczne problemy, zanim zajmie się nimi człowiek.

AI code review narzędzie: sprawdź diff, zanim zrobi to recenzent

Wklej git diff albo fragment kodu. To darmowe narzędzie działa w przeglądarce: wychwytuje sekrety, niebezpieczny SQL, połknięte błędy, pozostawiony kod debugowy i zbyt duże zmiany, a pull requestowi nadaje wynik 0-100.

Sprawdź mój diff
Inżynier przegląda obok siebie diff kodu na monitorze

Sprawdzarka diffa przed review

Wklej unified diff albo dowolny kod. Gdy wykryty zostanie diff, sprawdzane są tylko dodane linie. Nic, co wkleisz, nie opuszcza przeglądarki.

--/100
Wklej kod, aby zacząć
Nic jeszcze nie sprawdzono.
    Jak to działa

    Co sprawdza checker, a czego nie rusza

    Tylko dodane linie

    Gdy wklejasz unified diff, checker czyta nagłówki hunków, liczy numery linii w nowym pliku i skanuje wyłącznie dodane linie. Usunięte linie i niezmieniony kontekst nigdy nie generują znaleziska, więc nikt nie zostaje obwiniony za stary kod.

    Wynik ważony wagą problemu

    Trzynaście reguł dzieli się na trzy poziomy. Wysoki kosztuje 15 punktów: zaszyte sekrety, eval, SQL składany ze stringów, wyłączona weryfikacja TLS. Średni kosztuje 7: połknięte wyjątki, wyizolowane testy, innerHTML, diff na 400 linii. Niski kosztuje 2: TODO, wydruki debugowe, zakomentowany kod. Każda reguła liczy się co najwyżej trzy razy.

    Kontrola rozmiaru i testów

    Powyżej 200 dodanych linii dostajesz delikatną sugestię podziału zmiany, a powyżej 400 mocniejszą. Wynika to z ustaleń studium SmartBear na danych z Cisco: jakość przeglądu spada, gdy recenzent ma przed sobą więcej niż 200-400 linii naraz. Diff z ponad 50 dodanymi liniami bez pliku testowego też zostaje oznaczony.

    Jak używać

    Od wklejenia do czystego pull requesta w czterech krokach

    1. 1

      Wklej diff

      Uruchom git diff main...HEAD albo git diff --staged przed commitem i wklej wynik. Zwykły fragment kodu też zadziała, ale tracisz nazwy plików i wykrywanie plików testowych.

    2. 2

      Najpierw czytaj znaleziska wysokie

      Czerwone pozycje to te, na których recenzent się zatrzyma. Klucz zaszyty w commicie zostaje w historii nawet po usunięciu linii, więc trzeba go unieważnić, a nie tylko usunąć z kodu.

    3. 3

      Napraw albo uzasadnij resztę

      Każde znalezisko ma jednozdaniową poprawkę. Jeśli flaga jest fałszywie dodatnia, napisz to w opisie PR. Oszczędzisz recenzentowi tego samego pytania.

    4. 4

      Skopiuj checklistę

      Przycisk kopiowania zamienia znaleziska w checklistę w markdownie, którą wklejasz do opisu PR, żeby recenzent widział, co już wyłapano.

    Po co wstępny przegląd

    Pierwsze trzydzieści sekund review nie powinno iść na console.log

    Otwierasz pull request od kolegi i znasz tę rutynę. Przewijasz diff, widzisz pozostawiony wydruk debugowy, TODO bez zgłoszenia, pominięty test i blok catch, który połyka błąd. Żadna z tych rzeczy nie wymaga człowieka. Wymaga checklisty, która uruchomi się, zanim prośba o review wyjdzie. Na tym polega luka, którą wypełnia to narzędzie. Uwaga recenzenta jest ograniczona: badanie SmartBear na przeglądach w Cisco pokazało, że wykrywanie defektów utrzymuje się, gdy ludzie przeglądają 200-400 linii w 60-90 minut, a poza tym słabnie. Każda minuta poświęcona mechanicznym znaleziskom to minuta mniej na pytania, na które odpowie tylko człowiek: czy to właściwe podejście, czy pasuje do architektury, czy za pół roku dalej będzie miało sens. Nie zastąpi recenzenta i nie udaje, że może. Usuwa tanie zarzuty, dzięki czemu przegląd przez człowieka zaczyna się od ciekawej części.

    • Wyłapuje mechaniczne znaleziska, zanim prośba o review wyjdzie
    • Podaje numer linii wzięty z nagłówków hunków diffa
    • Działa lokalnie, więc można wklejać kod firmowy
    Dwoje inżynierów rozmawia o zmianie w kodzie przy laptopie
    FAQ

    Pytania o checker

    Czy to narzędzie AI do code review, czy linter?
    Ściśle mówiąc, ani jedno, ani drugie. To sprawdzarka wstępna oparta na regułach. Żaden model nie czyta kodu i nic nie jest generowane. Trzynaście reguł wzorców skanuje dodane linie pod kątem tego, co recenzent zauważa w pierwsze trzydzieści sekund: sekretów, SQL składanego ze stringów, połkniętych wyjątków i pozostawionego kodu debugowego. Mówimy o tym wprost, bo narzędzie, które zgaduje, jest gorsze niż lista kontrolna, która nie zgaduje.
    Czy mój kod opuszcza przeglądarkę?
    Nie. Sprawdzenia działają w JavaScripcie na tej stronie. Nie ma wysyłania plików, wywołań API ani konta. Jedyne, co się zapisuje, to anonimowe zdarzenie, że narzędzie zostało użyte, bez treści z pola tekstowego.
    Skąd biorą się progi 200-400 linii i reguła o plikach testowych?
    Próg rozmiaru wynika z badania SmartBear na danych z przeglądów w Cisco, które zaleca przeglądać nie więcej niż 200-400 linii naraz. Reguła małych zmian opiera się na publicznych praktykach inżynierskich Google dotyczących małych zmian (CL). Reguła brakującego testu to nasza konwencja: diff z ponad 50 dodanymi liniami bez pliku testowego dostaje flagę, bo to pytanie i tak zadają recenzenci.
    Jak liczony jest wynik?
    Zaczyna się od 100. Każde znalezisko odejmuje punkty zależnie od wagi: 15 za wysoki, 7 za średni, 2 za niski. Każda reguła liczy się co najwyżej trzy razy, więc jedna hałaśliwa reguła nie wyzeruje wyniku. To konwencja do ustalania kolejności pracy, a nie miara jakości kodu. Wynik 100 oznacza, że żadna reguła nie zadziałała, a nie że kod jest poprawny.
    Czego nie wyłapie?
    Wszystkiego, co wymaga zrozumienia: błędnej logiki biznesowej, wyścigów (race conditions), złej abstrakcji, API, które źle się zestarzeje. Reguły oparte na wyrażeniach regularnych dają też fałszywe alarmy, na przykład fixture testowy zawierający fałszywe hasło. Każde znalezisko traktuj jako pytanie do odpowiedzi, a nie wyrok.
    Z jakimi językami działa?
    Reguły to wzorce tekstowe, więc działają na JavaScripcie, TypeScripcie, Pythonie, Javie, Go i większości kodu z rodziny C. Niektóre reguły są specyficzne dla języka: goły except to Python, System.out.println to Java, InsecureSkipVerify to Go. Wklej ujednolicony git diff, a numery linii pochodzą z nagłówków hunków.
    Czy jest darmowe?
    Tak, bez rejestracji. Jeśli podczas przeglądu potrzebujesz odpowiedzi o reszcie repozytorium, na przykład kto wywołuje tę funkcję albo gdzie czytana jest dana wartość konfiguracji, właśnie do tego służy codebasechat.

    Przeglądaj, mając w polu widzenia całe repozytorium

    Diff pokazuje, co się zmieniło, a nie czego dotyka. codebasechat odpowiada na pytania o Twój kod zwykłym językiem, więc możesz sprawdzić, kto wywołuje zmienianą funkcję, zanim zatwierdzisz zmianę.

    Wypróbuj codebasechat za darmo