Co powinno być pierwsze: testowanie lub przegląd kodu?

Jestem całkiem nowy w programowaniu wzorców projektowych i cykli życia i zastanawiałem się, co powinno być pierwsze, przegląd kodu lub testowanie, biorąc pod uwagę, że są one wykonywane przez oddzielne osoby?

Z jednej strony, po co męczyć się z recenzowaniem kodu, jeśli nikt nie sprawdził, czy w ogóle działa? Z drugiej strony niektóre błędy można znaleźć wcześnie, jeśli przejrzysz je przed testowaniem.

Które podejście jest zalecane i dlaczego?

Najpierw testuję jednostki programistów, potem przegląd kodu, a potem testy jakości. Czasami przegląd kodu odbywa się przed testem jednostkowym, ale zwykle tylko wtedy, gdy recenzent jest naprawdę zalany i to jedyny raz, kiedy może to zrobić.

Naszym standardem jest sprawdzenie kodu, zanim produkt przejdzie do kontroli jakości. Powodem tego jest to, że po przetestowaniu i weryfikacji produktu istnieje mniejsza motywacja do refaktoryzacji i modyfikacji kodu wewnętrznego w inny sposób. Trzeba by to wszystko ponownie przetestować. Pamiętaj, że w większości przypadków przeprowadzamy również testy jednostkowe.

Idealnie, w zwinnym świecie, oba :)

Programowanie oparte na testach to metoda, która zachęca do opracowania testów jednostkowych przed napisaniem rzeczywistego kodu - w ten sposób można przechwycić specyfikację w kodzie i napisać testy, które przejdą testy. Następnie zautomatyzowane testy integracyjne, które zapewniają, że wszystkie różne komponenty pasują do siebie, są Dobrą Rzeczą, aby dodatkowo upewnić się, że funkcjonalność aplikacji jest zgodna z oczekiwaniami.

Jeśli chodzi o recenzje kodu, programowanie parami jest użytecznym sposobem, aby inny umysł przeoczył kod podczas pisania. Jednak niekoniecznie jest to praktyczne podejście. W mojej obecnej firmie działa tak, że kod jest sprawdzany po przetestowaniu na osobistym komputerze programisty, ale przed wdrożeniem go na współużytkowanym serwerze programistycznym.

Przegląd kodu ma na celu „dopracowanie” rzeczy, które już działają, aby upewnić się, że kod ma pożądany poziom jakości i spełnia wytyczne kodeksu określone przez firmę.

Przegląd kodu może również nastąpić w ramach przyszłej ogólnej optymalizacji, w której dokonujemy refaktoryzacji i ulepszenia starego kodu.

Jeśli ćwiczysz sprawdzanie kodu przed dokonaniem odprawy, to przegląd kodu przechodzi między dwoma etapami testowania: Ty jako programista najpierw testujesz swój kod, twój rówieśnik dokonuje przeglądu kodu, sprawdzasz go, a następnie dedykowani testerzy wykonają dokładniejsze indywidualne i testy integracji.

Najpierw przetestuj. Testuj ostatni. Test, test, test.

Przegląd kodu jest przyjemny. Ale trudne - może być bolesnym procesem, jeśli zaangażowane osobowości lub różne opinie.

Testowanie jest bardzo jasne: albo działa, albo nie działa. Więc testuj, testuj, testuj! I jeśli to możliwe, przegląd kodu.

W mojej ostatniej pracy mieliśmy trzy różne rodzaje przeglądów kodu, które robiliśmy na różnych etapach cyklu życia produktu. Pierwszy typ nazwaliśmy Sanity Review, i miałoby to miejsce, zanim deweloper nawet przeprowadził testy jednostkowe - w rzeczywistości Sanity Review zostały wykonane jeszcze przed ukończeniem funkcji. Chodziło o to, aby para członków zespołu usiadła i po prostu przejrzała kilka przypadkowych sekcji kodu, tak jak było to w trakcie procesu programowania, aby upewnić się, że rozwój postępuje dobrze i że nie otrzymamy giganta Wejście do TDWTF, gdy funkcja była gotowa do włączenia. Odbyło się to głównie dla osób, które potrzebowały dodatkowych wskazówek (młodsi programiści, nowi pracownicy i osoby przydzielone do pracy nad czymś, z czym nie byli zaznajomieni niż inni członkowie zespołu), i ogólnie rzecz biorąc odbyło się krótkie spotkanie, które dotyczyło tylko rażących problemów.

Następnie mieliśmy recenzje jednostek. Były one generalnie wykonywane z trzema programistami i byłyby wykonywane, gdy jednostka / funkcja została przetestowana i była gotowa do połączenia z głównym drzewem. To była najbardziej mięsista recenzja i zagłębiałaby się w szczegóły. Mieliśmy do tego trzech programistów, ponieważ mieliśmy oryginalnego autora kodu, opiekuna drzewa, który musiał się wypisać na kodzie, aby mógł zostać scalony, oraz trzeciego programistę, który został wybrany jako kopia zapasowa oryginalnego programisty (pomysł jest taki, że po ukończeniu sekcji kodu powinien nastąpić pełny transfer wiedzy do jednego innego członka zespołu, więc w zespole zawsze były co najmniej 2 osoby, które były w pełni zadowolone z dowolnej części bazy kodu).

Na koniec mieliśmy recenzje projektów. Obejmowało to cały zespół i zajęło to około tygodnia, a zrobiono to po kontroli jakości i wprowadzeniu produktu na rynek, a celem było, aby wszyscy usiedli i przejrzeli wszystkie zmiany w całej bazie kodu w ostatnim cyklu wydawniczym, gdzie każdy mógł porozmawiajmy o zmianach architektonicznych, gotach i zdecyduj, co należy zmienić i naprawić, zanim zaczniemy opracowywać kolejną wersję projektu.

Najpierw napisz automatyczne testy kodu, który ma zostać opracowany. Przejrzyj testy, aby upewnić się, że wszystkie znane wymagania są testowane. Napisz kod. Sprawdzaj tak często, jak chcesz.

Jeśli wymagane jest jakiekolwiek testowanie ręczne, bardzo ważne jest przejrzenie kodu przed wykonaniem testów ręcznych. W przeciwnym razie ulepszenia projektu sugerowane w przeglądzie kodu zostaną odrzucone, ponieważ konieczne będzie ponowne uruchomienie testów ręcznych.

Co jest pierwsze, jajko czy kurczak?
To zależy.

Jeśli jesteś nowy i nie masz pewności, co robisz, to zdecydowanie poproś kogoś o pomoc. Jest to nieformalna, ale bardzo poważna i cenna recenzja kodu.

Generalnie, chociaż sugerowałbym, abyś najpierw wykonał swoją własną brudną robotę, upewnij się, że wyprasowałeś kod, dobrze skomentowałeś w odpowiednich miejscach (tj. Trudne, nieoczywiste fragmenty), ale przynajmniej w zasadzie działa (masz testowane przy bardzo ogólnych przypadkach i niektórych przypadkach granicznych lub wyjątkach). Następnie weź to do swojego kolegi.

Zbyt wczesne sprawdzenie kodu może skończyć się strasznym marnowaniem czasu użytkownika. Zbyt późne sprawdzenie może skończyć się straszną stratą czasu. Musisz znaleźć właściwą równowagę dla najwyższej wydajności. Najpierw niektóre testy, potem przegląd, potem kolejne testy. Potencjalnie możesz mieć kilka recenzji kodu, w zależności od złożoności i iteracji, w różnych celach i celach.

Im mniej pewny jesteś, tym więcej recenzji (gdy jesteś we wczesnej fazie nauki, jest to normalne). Im bardziej jesteś pewny, tym więcej recenzji (nigdy nie warto być zbyt pewnym siebie, co oznacza, że ​​ogólnie nie jesteś tak dobrym graczem zespołowym i możesz wpędzić innych w kłopoty, musisz upewnić się, że Twój kod jest zrozumiały) i używane przez innych). Właśnie wtedy, gdy jesteś w środku, opinie można rozdzielić.

Tylko moje dwa centy.

Capers-Jones, który badał i mierzył wynikową wydajność i jakość procesów tworzenia oprogramowania bardziej niż ktokolwiek inny, zaleca następującą sekwencję działań związanych z usuwaniem wad:

• Kontrole projektu
• Inspekcje kodu
• Testy jednostkowe
• Nowe testy funkcji
• Testy regresji
• Testy wydajności
• Testy systemu
• Zewnętrzne testy beta

Jednym z powodów przeprowadzenia kontroli kodu przed testowaniem jest to, że przegląd może wziąć pod uwagę nie tylko sam kod, ale także jego testowalność.