Jak wybrać kod do sprawdzenia?

Należę do zespołu siedmiu programistów w małej firmie programistycznej i staram się wprowadzać regularne recenzje grupowe i projekty. W przeszłości przeprowadziliśmy kilka recenzji, ale było to sporadyczne. Chciałbym, aby było to bardziej regularne.

Czytałem Code Complete i innych podobnych środków i mówią o mechanice jak przeprowadzić opinie kod, ale nie udało mi się znaleźć żadnych najlepszych praktyk w jaki sposób wybrać , co do przeglądu. Mamy bazę kodów, która ma ponad osiem lat i obejmuje różne języki, więc jest wiele rzeczy, na które można spojrzeć.

Oto niektóre z czynników, które mogę wymyślić, które mogą wpłynąć na wybór:

• Język: C, Java, SQL, PL / SQL
• Wiek kodu: nowy kod a stary kod
• Użycie kodu: często używany kod kontra (efektywnie) martwy / mało używany kod
• Znaczenie kodu: kod krytyczny kontra kod niekrytyczny
• Deweloper: młodszy kod programisty a starszy kod programisty

Rozumiem, że nie jest to pytanie z absolutną ostateczną odpowiedzią, ale przydatne byłyby wszelkie wskazówki.

Niektóre pytania peryferyjne:

• Podejścia do przeglądu kodu (wzmianki o recenzowaniu najważniejszych sekcji i nowego kodu programisty)
• Czy powinniśmy spróbować przejrzeć cały nasz kod?

Ogólnie rzecz biorąc, musisz wszystko przejrzeć . Jeśli nowa aplikacja ma 2 000 LOC, wszystkie 2 000 LOC musi zostać poddane przeglądowi.

Dlatego nie ma najlepszej praktyki, jak wybrać, co należy przejrzeć.

Jeśli zbliżysz się do istniejącej dużej bazy kodów, której nigdy wcześniej nie sprawdzałem, to tak samo, kiedy musisz przepisać istniejącą dużą bazę kodów i wybrać, od czego zacząć. Zależy to silnie:

• na bazie kodu (pojedynczy kod monolityczny byłby trudniejszy do przepisania / przeglądu niż zestaw oddzielnych składników itp.),

• Twój kontekst (czy możesz zatrzymać wszystko, nad czym pracujesz i spędzić trzy miesiące (trzy lata?) pracując tylko nad przepisaniem / recenzowaniem, czy musisz to zrobić małymi przerwami, tylko gdy masz wolny czas)?

• rodzaj przeprowadzanej recenzji (czy masz listę kontrolną rzeczy do przejrzenia? W zależności od elementów listy kontrolnej możesz najpierw przejrzeć niektóre części).

Gdybym był na twoim miejscu to bym:

• kieruj się zasadą 80% -20%, o której mowa w pierwszym komentarzu do drugiego pytania, z którym się łączysz.

• weź pod uwagę, że 100%, będąc ideałem, może nie jest tego warte. To jest jak 100% pokrycia kodu dla testów jednostkowych, z tym wyjątkiem, że takie pokrycie kodu jest w większości niemożliwe lub bardzo drogie.

• zacznij od części kodu, których najczęściej używasz i które są najważniejsze. Jeśli baza kodów ma bibliotekę, która uwierzytelnia i rejestruje nowych użytkowników w witrynie firmowej, najpierw ją przejrzyj, ponieważ na pewno chcesz znaleźć luki w zabezpieczeniach, zanim zrobią to hakerzy.

• użyj istniejących danych, aby określić, co jest ważniejsze do przejrzenia. Jeśli część bazy kodu w ogóle nie ma testów jednostkowych, podczas gdy inna, równie ważna część ma 85% pokrycia kodu, zacznij od przejrzenia pierwszej części. Jeśli część bazy kodu została napisana przez programistę, o którym wiadomo, że jest niedoświadczona i wprowadza więcej błędów niż którykolwiek z jego kolegów, zacznij od sprawdzenia jego kodu.

Zacznij od przejrzenia wszystkich zmian dokonanych w kodzie; dzięki temu problem się nie pogorszy. Następnie zacznij przeglądać kod na podstawie częstotliwości zmian; będą to obszary „problematyczne”.

Będziesz chciał znaleźć sposób, aby sprawdzić, czy przejrzałeś fragment kodu, abyś mógł przeanalizować zasięg przeglądu twojego kodu w stosunku do innych problemów.

Jeśli możesz ustalić, który kod nie jest objęty testami, staje się to wyższy priorytet do sprawdzenia.

Przejrzyj wszystkie nowe zmiany, które zostały wprowadzone przed wprowadzeniem ich do produkcji. skrypty instalacyjne, kod źródłowy, zmiany w bazie danych, wszystko! Celem przeglądu kodu jest powstrzymanie złego kodu przed wprowadzeniem go do produkcji. Czy to zły schemat organizacyjny, czy po prostu wprowadzony błąd, ponieważ coś zostało pominięte.

Refaktoryzacja bieżącego kodu, nad którym pracujesz, idzie w parze z przeglądem kodu. Na przykład, gdy przeglądam kod, jeśli w klasie znajdował się zduplikowany kod, który zawierał poprawkę, nawet jeśli programista nie zmienił tego kodu w swojej poprawce, nie przekazałbym go. Chciałbym, żeby wrócili i usunęli zduplikowany kod.

Jeśli dokonasz nieustannej refaktoryzacji, przyda się przegląd kodu. W przeciwnym razie jest to strata czasu.

Jeśli zastosujesz proces sprawdzania kodu jako etap w procesie programowania, baza kodu będzie z czasem ulepszana. Co więcej, nie powinieneś zezwalać programistom na pracę nad nowymi funkcjami lub poprawkami błędów, dopóki zaległości w przeglądzie kodu nie będą puste. To gwarantuje, że przegląd kodu zostanie zakończony.

Jeśli istnieją znane obszary, które wymagają refaktoryzacji, ale ich wykonanie zajmie dużo czasu (tj. 1 tydzień lub dłużej). Następnie samodzielnie utwórz element roboczy dla tego refaktoryzacji i dodaj go jako element do obróbki.

Zacznij od przejrzenia całego nowego kodu i modyfikacji istniejącego kodu.

Podczas przeglądania modyfikacji istniejącego kodu programista powinien przestrzegać zasady boyscout. Zostaw kod lepiej niż go znalazł.

To nie znaczy, że musisz naprawić cały plik, aby był doskonały. Ale to nie powinno przyczynić się do bałaganu, powinno sprawić, że będzie trochę lepiej. Być może przez przeniesienie modyfikacji do nowych klas, które są odpowiednio ustrukturyzowane, i pozostawienie pozostałej części oryginalnego pliku kodu bez zmian (w końcu jego „działanie”).

Gdy zaczniesz ulepszać kod, przeglądając cały nowy kod i modyfikacje, jako programiści powinieneś wiedzieć, które obszary aplikacji wymagają najwięcej zmian. Następnie przejrzyj je, dyskutuj, w jaki sposób można je stopniowo ulepszać.

Recenzowanie kodu napisanego 10 lat temu, ze względu na jego weryfikację, jest bezcelowe, programista powinien był poprawić w ciągu tych 10 lat. Więc nie ma sensu przeglądać tego, aby dowiedzieć się, co wszyscy wiecie.

Celem przeglądów kodu jest poprawianie i poprawianie błędów, które obecnie popełniacie, oraz dzielenie się tą wiedzą wśród zespołu.

W moim projekcie uwzględniamy przegląd kodu jako niezbędny element w większości przypadków dla każdego zadania / historii użytkownika / błędu. Używamy procesów scrum / agile, a bilet / historia nie jest przenoszony do kompilacji (czyli zaległości w kontroli jakości), dopóki testy jednostkowe nie zostaną napisane i przegląd kodu zostanie zakończony.

W tym celu wykorzystujemy analizę Atlassian FishEye z przeglądem kodu Crucible zintegrowanym z JIRA + SVN.

Gdy programista sprawdza kod pod kątem określonej historii, tworzy nową recenzję kodu w FishEye, gdzie wybiera innych członków zespołu, którzy dokonają przeglądu.

Po zakończeniu przeglądu kodu (narzędzie wyróżnia przesłane zmiany i pozwala pozostawić komentarze do określonego wiersza kodu) programista poprawia wspomniane problemy / wdraża sugerowane ulepszenia i przenosi bilet do kolumny Wbudowane w JIRA - oznacza to, że historia jest gotowy do przetestowania i nie oczekuje się żadnych zmian kodu dla tego konkretnego elementu pracy.

Dzięki temu QA nie testuje niczego, co mogłoby zostać zmienione i potencjalnie uszkodzone podczas refaktoryzacji kodu po przejrzeniu kodu .

Podsumowując, cały kod musi zostać przejrzany - wspiera to wysoką jakość kodu, co zwykle skutkuje lepszym projektowaniem, czytelnością, łatwością konserwacji i testowalności kodu oraz poprawia wydajność programowania w dłuższej perspektywie.