W mojej firmie, przed dostarczeniem jakiegokolwiek projektu, mój szef prosi moich seniorów o przejrzenie programów napisanych przeze mnie lub innych członków zespołu, a czasami szef również siedzi z nami do przeglądu.
Myślę, że to dobry sposób na zdobycie wiedzy, ale czasami, gdy programy działają dobrze, po sprawdzeniu nie działają tak samo i muszę ponownie zajrzeć do mojego programu.
Mówią, że recenzja pomaga zoptymalizować wykonanie programu i zapytania, ale czy możemy preferować optymalizację niż faktyczne działanie programu?
Odpowiedzi:
„Działa dobrze” jest rzeczywiście świetnym miernikiem, ale jeśli jesteś jedynym w zespole, który jest w stanie rozszyfrować to, co napisałeś, a tym samym zachować go, kod jest prawie bezwartościowy dla firmy w perspektywie średnio- lub długoterminowej.
Dobry kod to co najmniej:
(Niektóre z tych wymagań faktycznie się pokrywają, ale warto rozważyć je indywidualnie ...)
Przeglądy kodu służą celowi poza częścią „roboczą”, co można wykonać za pomocą testów automatycznych.
Osobiście wiem, że to denerwujące, że coś działa, a jednocześnie trzeba je odbudować od podstaw. Ale często wynika to z nieporozumienia ze strony kierownika wyższego szczebla / technicznego. Jeśli więc uważasz, że musisz zbyt często przepisywać, następnym razem idź do recenzenta przed napisaniem pojedynczej linii i spróbuj uzyskać jak najwięcej informacji o tym, czego się spodziewa, w każdym szczególe. Byłoby również świetnie, gdyby zespół recenzentów kodu streścił swoje oczekiwania w formalnym dokumencie, do którego może się odwoływać każdy programista.
Z bardziej pozytywnej strony sesja może być również okazją do wymiany dobrych praktyk / projektów.
źródło
Zinterpretowałem twoje pytanie jako „Czy mój działający kod można poddać kontroli w recenzji do tego stopnia, że nawet się nie kompiluje?” .
Tak, może. Ogólnie rzecz biorąc, podczas przeglądu sprawdzasz, jak Twój kod robi to, co robi. Kiedy chcesz przekazać swój kod, mówisz, że ukończyłeś pewną część programu.
Mówisz, że to działa. Następnie wykonuje się testy w celu zweryfikowania tego. Zaliczenie modułu nie oznacza, że modułu nie należy dotykać ponownie.
Moduł, który wydaje się funkcjonalny, może być katastrofą czekającą na zdarzenie, albo w czasie wykonywania, albo za kilka miesięcy, gdy ty lub ktoś inny będzie musiał przeprowadzić na nim konserwację. Zmieniając kod w recenzji i wskazując, co było z nim nie tak, recenzent (miejmy nadzieję) próbuje cię czegoś nauczyć.
źródło
Recenzowane recenzje to bez wątpienia świetny sposób na naukę. Ktoś może zobaczyć coś innego, ma inne doświadczenie i powinien być w stanie przyczynić się do poprawy. Nie powinno to być dyskredytujące. Spodziewam się, że każdy programista będzie mógł komentować i konstruktywnie krytykować czyjś kod!
Wydaje mi się, że niektóre z tych „udoskonaleń” faktycznie dokonują przełomowych zmian, ponieważ (jak można się spodziewać) deweloper recenzujący ma mniej doświadczenia z oprogramowaniem niż autor.
Ten trend to samoocena, może twój kod jest trudny do naśladowania lub utrzymania? Czy twoje recenzje są cenne? Absolutnie! Widzę, jak to może być frustrujące, aby mieć działający kod, który twoi rówieśnicy wydają się łamać, nie powinieneś się zniechęcać - powinieneś pracować, aby chronić swój kod przed tymi zmianami.
Powstaje zatem pytanie, jak chronić funkcjonalność programów, aby wiedzieć, że funkcjonalność nadal działa po zakończeniu recenzji. Moją sugestią byłoby upewnienie się, że masz przyzwoity zasięg testu jednostkowego. W ten sposób, ilekroć Ty / Twój recenzent / twój następca zmienisz kod, mogą być pewni, że wprowadzone przez nich zmiany są bezpieczne.
ETA: Właśnie zauważyłem jeden z twoich komentarzy, jestem pewien, że jest to oczywiste, ale recenzje kodu powinny zostać wykonane, zanim zespół testowy się w to zaangażuje. W przeciwnym razie nie testują produktu końcowego.
źródło