Akceptuj wszystko, nie rozumiejąc niczego

Naciśnięcie Entera, aby zaakceptować sugestie kodu, wymaga mniej wysiłku niż przewijanie ich dalej. Jeden ruch klawisza sprawia, że kod staje się Twój. Czytanie i rozumienie tego kodu nie stało się jednak szybsze.

Istnieje przepaść między szybkością, z jaką akceptujesz kod, a szybkością, z jaką go rozumiesz. To właśnie w tej luce powstają błędy.

Dług techniczny miał kiedyś jasne przyczyny. Miałeś napięte terminy lub szukałeś dróg na skróty. Mogłeś wskazać powód. Teraz budujesz dług w spokojny wtorek. Akceptujesz sześć sugestii pod rząd, bo wyglądają w porządku. Nikt Cię nie poganiał, ale kod pozostaje nieprzebadany.

Brian Kernighan powiedział w 1974 roku, że debugowanie jest dwa razy trudniejsze niż pisanie programu. Mówił o kodzie, który piszą ludzie. Przynajmniej ludzie rozumieją własną pracę.

Dziś sugestia może przejść linter, a nawet testy. Wciąż jednak może opierać się na błędnym założeniu. Dzieje się tak, ponieważ ludzie czytają sugestię jako wynik (output), a nie jako kod. Wynik, który wygląda dobrze, zostaje zatwierdzony.

Jeśli model pisze zarówno kod, jak i testy, to oceniasz zadanie domowe na podstawie odpowiedzi tego samego ucznia. To nie mówi Ci, czy logika jest poprawna. Nie mówi Ci, czy uwzględniono przypadki brzegowe. Łatwo o tym zapomnieć, gdy kod pojawia się w Twoim własnym edytorze i w Twoim własnym stylu.

Tworzy to realne problemy:

  • Debugujesz kod, którego nigdy nie przeczytałeś. Gdy coś zepsuje się kilka tygodni później, zaczynasz od zera.
  • Zawodzą przypadki brzegowe. Sugestia dobrze obsługuje ścieżkę szczęśliwą (happy path). Zawiera sprawdzenie wartości null. Ale pomija specyficzną logikę, której potrzebuje Twój biznes.
  • Nie potrafisz obronić własnych pull requestów. Jeśli recenzent zapyta, dlaczego wybrałeś daną metodę, nie będziesz miał odpowiedzi. To Ty nie podjąłeś decyzji. Po prostu jej nie odrzuciłeś.

Te narzędzia są użyteczne. Pomagają eksplorować bazy kodu lub planować nowe funkcje. Problemem jest Twoja postawa. Musisz traktować każdą sugestię jako coś, co należy przeczytać i ocenić, a nie tylko rzucić na nią okiem.

W przypadku kodu boilerplate lub szybkich skryptów szybkość jest w porządku. W przypadku logiki biznesowej lub bezpieczeństwa Twoje podejście musi się zmienić. Czytaj kod tak, jakbyś miał za niego odpowiadać. Bo będziesz.

Zamiast tego rób tak:

  • Omów swoje rozwiązanie z modelem, zanim poprosisz o kod.
  • Przejrzyj diff tak, jakbyś sam go napisał.
  • Poproś narzędzie o wyjaśnienie toku rozumowania, zanim zaakceptujesz kod.
  • Traktuj sugestie jak pracę junior developera. Są przydatne, ale nie stanowią prawdy objawionej.
  • Zwolnij przy liniach, które Cię zaskakują. Zaskoczenie to sygnał.

Naciśnięcie klawisza stało się tańsze. Twoja odpowiedzialność – nie. Szybkość bez zrozumienia to po prostu szybki dług.

Źródło: https://dev.to/cloudx/accept-all-understand-none-4dob

Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi