Code Review – Na co zwrócić uwagę?

W życiu każdego programisty przychodzi moment, kiedy musi sprawdzić poprawność kodu innej osoby. Nie da się ukryć, że sprawne oko seniora jest w stanie wychwycić problemy, których junior nigdy by się nie spodziewał. Sam przekonałem się wiele razy, że oddając do sprawdzenia idealny w moim wyobrażeniu kod, wracał on z trafnymi uwagi, z rzeczami do poprawy. Analizując, jak wygląda ten proces, wypisałem sobie listę wskazówek, na co zwrócić uwagę przy sprawdzeniu kogoś kodu.

Architektura
  • Czy kod jest dla mnie zrozumiały?
  • Czy kod zawiera duplikaty?
  • Czy klasy i funkcję charakteryzują się wysoką kohezją? Czy są spójne?
  • Czy można bardziej podzielić kod?
  • Czy można wyodrębnić osobne klasy lub funkcje?
  • Czy udostępniamy na zewnątrz klasy tylko to, co niezbędne?
  • Czy kod jest zgodny z przyjętymi standardami kodowania?
  • Czy nazwy zmiennych, funkcji i klas są wystarczająco opisowe?
  • Czy jakaś część kodu jest zakomentowana?
  • Czy są jakieś niepotrzebne komentarze?
  • Czy w kodzie nie używamy żadnych „magicznych” wartości?
  • Czy jakiś kod możemy zastąpić gotową już implementacją (biblioteki zewnętrzne, inne części systemu itp.)?
Język
  • Czy klasa posiada publiczne zmienne? Czy możemy je zastąpić akcesorami?
  • Czy stałe wartości możemy zastąpić typem wyliczeniowym?
  • Czy możemy uogólnić zwracane lub przyjmowane typy wartości?
Bezpieczeństwo
  • Czy wszystkie wartości są zainicjalizowane?
  • Czy wszystkie parametry wejściowe są sprawdzane?
  • Czy wszystkie użycia zewnętrznego kodu zawierają obsługę błędów?
  • Czy wszystkie parametry z zewnętrznego kodu są walidowane?
  • Czy zostały użyte poprawne typy danych, wykorzystane struktury są odpowiednio wydajne?
  • Czy wszystkie pętle mają skończone ograniczenia?
  • Czy wszystkie zasoby zostaną prawidłowo zwolnione?
  • Czy podczas kompilacji nie występują żadne ostrzeżenia?
  • Czy wartości null nie są zwracane przez funkcje?
  • Czy w logice nie występuje problem dzielenia przez zero?
Utrzymanie
  • Czy klasy są testowalne?
  • Czy klasy zawierają odwołania do obiektów globalnych, klas statyczych itp.?
  • Czy wszystkie informacje o błędach zostaną zalogowane?
  • Czy żadne wyjątki nie są ignorowane?
  • Czy żadne wyjątki nie są ukrywane?
  • Czy logowane są tylko niezbędne informacje?
  • Czy nie udostępniamy na zewnątrz żadnych danych poufnych?

Lista stworzona w celu usystematyzowania wiedzy i zamierzam ją uzupełniać o kolejne punkty 🙂

Facebooktwitter

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *