Czy moi koledzy powinni sprawdzać nawzajem kod z systemu kontroli źródła?

Oto moja historia: jeden z moich kolegów używa do przeglądu całego kodu hostowanego w systemie wersji. Nie mówię o odpowiednim przeglądzie zmian w częściach, do których on należy. Obserwuje kod pliku do pliku, linia po linii. Każdy nowy plik i każdy zmodyfikowany. Mam ochotę być szpiegowanym!

Domyślam się, że jeśli kod był już hostowany do sterowania systemem, powinieneś zaufać temu co najmniej jako wykonalnemu. Moje pytanie brzmi: może jestem po prostu zbyt paranoiczny i praktyka wzajemnego sprawdzania kodu jest dobra?

PS: Jesteśmy zespołem tylko trzech programistów i obawiam się, że jeśli będzie nas więcej, kolega po prostu nie będzie miał czasu na sprawdzenie całego kodu, który napiszemy.

Powiedziałbym tak!

Dwa szybkie powody:

1) Jeśli kod jest w produkcji, nie można zakładać, że jest poprawny. Każda zmiana w innym miejscu w systemie może powodować błędy. Myślę, że bardzo ważne jest regularne sprawdzanie kodu. W ten sposób refaktoryzacja odbywa się regularnie, utrzymując porządek i poprawiając kod (bardziej aktualny jest prawdopodobnie lepszy).

2) Umiejętność czytania kodu jest bardzo ważną umiejętnością, jeśli zamierzasz zostać programistą. Jest to umiejętność, nad którą musisz popracować. Dla każdego programisty rozpoczynającego pracę nad istniejącą bazą kodu, jeśli nie jest przyzwyczajony do czytania kodu innej osoby, istnieje stroma krzywa uczenia się, próbująca zapoznać się z tym, co się dzieje.

Nie sądzę, że powinieneś czuć się szpiegowany. Zaakceptuj każdą krytykę, którą ktoś ci daje (jeśli jest to oczywiście ważne). I zachęcaj innych do wyrażania WAŻNEJ krytyki. To jest sposób, w jaki się uczymy. Gdy przestaniemy się uczyć (lub chcemy przestać), pojawią się duże problemy.

Jeśli wspomniany kolega zapewnia dobre i konstruktywne opinie, jest to fantastyczna rzecz i powinieneś bardzo ją docenić.

To BĘDZIE łapać błędy, o których nie pomyślałeś podczas pisania. Ten BĘDZIE powodować piszesz lepszy kod, bo wiesz, że inni będą go zobaczyć.

Byłoby dobrze, gdyby cały zespół dokonywał recenzji kodu zamiast jednej osoby. Idealnie każdy zaprosiłby kogoś do przejrzenia swojego kodu po zakończeniu. Pomocne jest utrzymywanie go w sposób nieformalny (trzymanie menedżerów z daleka) i umożliwienie recenzentowi omówienia twoich ustaleń. Idealnie, jeśli recenzent udziela tylko informacji zwrotnych i nie wprowadza zmian w kodzie, oczywiście można go trochę sparować.

Naprawdę pomaga mieć standardy kodowania, aby uniknąć ciągłych dyskusji na temat białych znaków i stylu kodu. Posiadanie pewnej statycznej analizy kodu na komputerze kompilacji może być pomocne w powstrzymywaniu niektórych dyskusji.

Jeśli chodzi o aspekt czasowy, teoria ta pozwala zaoszczędzić czas. Im później zostaną wykryte usterki, tym droższa będzie ich zasada. Przegląd kodu równorzędnego może złapać sporo problemów.

Twój kolega brzmi jak sumienny programista, powinieneś pójść za jego przykładem.

W podobny sposób obserwuję nasz system kontroli wersji. Nasza baza kodów jest zbyt duża, aby oglądać każdą linię, ale staram się uzyskać wyczucie poziomu na większość zmian. Patrzę też na meldunki, które najprawdopodobniej wywołują skutki uboczne, i przeglądam je wiersz po wierszu. Za minimalny czas spędzony na tym, wypłata jest ogromna. (Uwaga: nie jestem jedynym programistą w naszym zespole z tym nawykiem).

Ten rodzaj recenzji ma tendencję do łapania błędów lub wywoływania dyskusji co tydzień. To oszczędza czas podczas przeprowadzania kontroli jakości. Dyskusje obejmują najlepsze praktyki, projektowanie algorytmów i wiele innych. Kluczem na tym froncie jest to, że wszyscy uważają to za konstruktywne.

Osobiście pozwala mi to lepiej zrozumieć, co dzieje się w innych częściach bazy kodu, których nie dotykam regularnie. Gdy inni potrzebują pomocy, jestem w stanie wskoczyć szybciej. Gdy pojawią się nowe pomysły, mogę z nich skorzystać wcześniej.

Czy czujesz, że to szpiegostwo (!)? Ale z perspektywy kolegi powiedziałbym, że robi właściwe rzeczy dla rozwoju swojej kariery. Przeczytaj inne kody i dowiedz się, jak projektują i wdrażają logikę, to wiele zyska!

IMHO, jeśli ktoś wskaże coś złego w kodzie, musisz to zaakceptować i dowiedzieć się od nich, jak napisać dobry kod

Przez 6-7 miesięcy robiłem to samo. Nie szpiegować, ale kontrolować jakość. Każdy wiersz kodu aktywnie rozwijanej aplikacji, przypisanej do centralnego repozytorium, 2 głównych języków, kilku innych języków, ogromnych plików makefile na 4 platformy.

To bardzo zła praktyka . Pewnego dnia dowiedziałem się, że nie jestem w stanie uchwycić wszystkiego ze względu na wytrzymałość. Kolejnym argumentem przeciwko temu jest podmiotowość - każdy może się mylić.

Lepiej jest, gdy programiści sprawdzają nawzajem swoje kody, a ktoś ma doświadczenie w podejmowaniu ostatecznych decyzji i określaniu kierunków.

Przeglądy kodu w zespole (przy użyciu rybiego oka , tygla lub innych narzędzi) są niezwykle ważne i przydatne. jedyną lepszą rzeczą jest bezpośrednie programowanie par, aby upewnić się, że kod, który dostaje się do systemu za pierwszym razem, jest dobrze przemyślany i przeszedł przez mózg więcej niż jednej osoby.

To zdarzyło się raz w moim zespole. Niestety zakończyło się to winą. Ludzie ciągle czekali, aż inni sprawdzą kod i zawsze starali się znaleźć w nim coś złego i cały czas grali w winę.

Mam nadzieję, że masz bardziej dojrzałą publiczność.

Jest to dość standardowa praktyka w przemyśle. Firmy, w których pracowałem, mają bardzo ścisłe wytyczne dotyczące przeglądu kodu. Jeden nawet nie pozwoliłby ci zatwierdzić, chyba że kod został sprawdzony.

Nie obrażaj się i nie czuj się obserwowany. Potraktuj to jako siatkę bezpieczeństwa i doświadczenie edukacyjne.

W poprzednim zadaniu starszy programista oglądał i sprawdzał wszystkie zameldowania, a ja często otrzymywałem doskonałe opinie, które pomogły mi stać się lepszym programistą.

W mojej obecnej pracy obserwuję wiele meldunków i trzy dni temu znalazłem błąd i powiadomiłem programistę.

Ta praktyka absolutnie złapie błędy i sprawi, że cały twój zespół będzie lepszy, jeśli ją przyjmiesz .