Jak ulepszyć Code Review? 7 Sprawdzonych Praktyk

Tak się nie robi. Ale czasami pytania są po prostu pytaniami, a to co powiedziałeś, to to jest takie zaproszenie do dyskusji. To jest też fajna sprawa, jeśli robimy coś, czego nie jesteśmy do końca pewni, to Code Review po prostu może nam służyć jako taki etap w robieniu kodu. Kolejna dobra praktyka. Automatyzujmy co się da. Umówmy się. Linter, Pretier to powinien być w zasadzie już standard. Jeśli jeszcze nie masz Lintera i Pretiera w swoim projekcie i współpracujesz z innymi programistami, to wiedz, że coś się dzieje. Coś jest nie tak. Coś jest nie tak. Myślę, że po prostu sprawdzanie takich bezsensownych rzeczy jak zła indentacja czy cudzysłów zamiast podwójnego albo w ogóle dyskusje o tym, jak jest formatowany kod albo o rzeczach, które po prostu możemy zautomatyzować są trochę bez sensu, więc jeśli mamy do tego narzędzia, to fajnie jest.

I tutaj w sumie wspomniałem o Priterze, to jest w kontekście formatowania, ale linter to też nie jest coś co gryzie, no bo tam trzeba jednak tą konfigurację dodać. Możemy oczywiście użyć jakichś predefiniowanych presetów, możemy też dodać nasze własne reguły po uzgodnieniu ich oczywiście z innymi ludźmi, z którymi współpracujemy. A to koniec końców prowadzi do mniejszego Code Review, bo po prostu Nie znajdują się tam takie rzeczy, które są powtarzalne i bez sensu. Od ogółu do szczegółu, czyli plan na robienie Code Review. Jeżeli robisz komuś Code Review, dobrze jest zaczynać od ogólnego umiejscowienia kodu, czyli czy on się nadaje na właśnie takie umiejscowienie. Czyli przeglądamy strukturę plików, nazwy, foldery i tak dalej, takie podstawowe rzeczy.