Pracuję nad projektem solo i muszę utrzymywać własny kod. Zwykle recenzji kodu nie dokonuje autor kodu, więc recenzent może spojrzeć na kod świeżym okiem - jednak nie mam takiego luksusu. Jakie praktyki mogę zastosować, aby skuteczniej przeglądać własny kod?
code-reviews
solo-development
Max Yankov
źródło
źródło
Odpowiedzi:
Przede wszystkim skorzystaj z narzędzi, aby sprawdzić jak najwięcej. Testy (poparte pewnym uzasadnieniem pokrycia kodu) dadzą ci pewność co do poprawności kodu. Narzędzia do analizy statycznej mogą wychwycić wiele najlepszych praktyk. Zawsze będą jednak problemy, na które ludzkie oczy będą musiały ustalić, i nigdy nie zrobisz tak dobrej pracy, przeglądając własne rzeczy, jak ktoś inny, są jednak pewne rzeczy, które możesz zrobić, aby pomóc, jednak
Jest to oczywiście przydatne, gdy przeglądasz także kod innych użytkowników
źródło
Zajrzyj na stronę Code Review Stack Exchange. Służy do udostępniania kodu z projektów, nad którymi pracujesz, do wzajemnej oceny :
Możesz także użyć narzędzi do analizy statycznej kodu, aby wykryć pewne problemy, ale w niektórych przypadkach będą generować fałszywe alarmy i nie będą w stanie zasugerować, jak poprawić projekt.
źródło
code review
jeśli jeszcze nie wiesz, że to problem.W mojej głowie rozwinęło się kilka zupełnie różnych osób. Jeden z nich nie jest nawet programistą! Rozmawiamy, rozmawiamy o nowościach i sprawdzamy nawzajem kod.
Zdecydowanie polecam swoje podejście.
ps On nie żartuje.
źródło
Zgadzam się z opinią jk-a, że opinia jednoosobowa nie jest tak skuteczna jak recenzja 2-osobowa. możesz jednak spróbować jak najlepiej:
przegląd krótkoterminowy (krótko po opracowaniu kodu)
Używam git jako lokalnego repozytorium. Za każdym razem, gdy kończę funkcję lub naprawiam błąd, przesyłam zmiany do repozytorium.
Przed odprawą porównuję zmiany w kodzie i ponownie myślę:
przegląd długoterminowy (6 miesięcy po sporządzeniu kodu)
Pytam siebie:
źródło
Najpierw odłóż swój kod na bok tak długo, jak to możliwe. Pracuj nad czymś innym, jakimś innym kodem. Nawet po dniu będziesz zaskoczony tym, co znajdziesz.
Po drugie, udokumentuj swój kod. Wielu programistów nie lubi dokumentować swojego kodu, ale usiądź i napisz dokumentację, jak korzystać z kodu i jak działa. Patrząc na kod w inny sposób, znajdziesz błędy.
Mówi się, że prawdziwym opanowaniem przedmiotu jest umiejętność nauczenia go kogoś innego. Z dokumentacją próbujesz nauczyć kogoś innego swojego kodu.
źródło
Przekształć tę technikę debugowania w technikę przeglądu kodu: http://en.wikipedia.org/wiki/Rubber_duck_debugging
Ta koncepcja zdziała cuda, pozwalając na właściwe nastawienie do pracy z kodem tak, jakby był nowy.
źródło
Oprócz przydatnych narzędzi wspomnianych w innych odpowiedziach, myślę, że modyfikacja twojego sposobu myślenia jest przydatna podczas przeglądu kodu. To głupie, ale mówię sobie: „Wkładam kapelusz do recenzji kodu”. Robię to samo z kontrolą jakości.
Dlatego ważne jest, aby ograniczyć się do tego sposobu myślenia. Jesteś recenzentem lub recenzentem, nie możesz być jednocześnie naraz. Jako recenzent robię obiektywne notatki, aby podzielić się z recenzentem. Nie zmieniam kodu podczas recenzji, nie jest to coś, co recenzent powinien zrobić.
Czasami formalność wydaje się trochę absurdalna, ale podczas pracy solo uważam, że często pociągam w wielu kierunkach. Więc niekoniecznie muszę zamknąć pętlę recenzji, zanim pojawi się coś innego - ta formalność (i tak naprawdę mówię szorstkie notatki w narzędziu wiki), jest przydatna do upewnienia się, że recenzja się zakończy. Podobnie z moim kapeluszem kontroli jakości, dodaję bilety na błędy, zanim je naprawię.
źródło
Wydaje się, że powszechne jest przekonanie, że samoocena nie jest skuteczna. Nie zgadzam się i uważam, że samodzielna recenzja może wychwycić wiele problemów, jeśli zostanie wykonana dokładnie.
Oto wskazówki z mojego kilku lat doświadczenia:
Tylko informacja - te wytyczne były częścią zaleceń Oracle kilka lat temu, kiedy tam pracowałem, gdzie celem było wychwycenie błędów „w górę” zanim kod przejdzie do testowania. Bardzo pomogło, chociaż wielu programistów uznało je za nudną pracę.
źródło
Technika przetwarzania oprogramowania osobistego w recenzjach może być przydatna, chociaż opiera się na danych historycznych dotyczących Twojej pracy i jakości produktów.
Zaczynasz od danych historycznych o swoich produktach pracy, w szczególności liczby i rodzajów wad. Istnieją różne metody klasyfikacji defektów, takie jak ta z kursu PSP . Możesz opracować własne, ale chodzi o to, że musisz umieć powiedzieć, jakie błędy popełnisz po drodze.
Gdy dowiesz się, jakie błędy popełniasz, możesz opracować listę kontrolną, której możesz użyć podczas przeglądu. Ta lista kontrolna zawiera informacje o najczęściej popełnianych błędach, które Twoim zdaniem najlepiej nadają się do przeglądu (w przeciwieństwie do korzystania z innych narzędzi). Za każdym razem, gdy przeglądasz produkt roboczy, skorzystaj z listy kontrolnej i poszukaj tych błędów lub błędów, udokumentuj je i napraw. Okresowo zmieniaj tę listę kontrolną od czasu do czasu, aby upewnić się, że koncentrujesz się na prawdziwych, istotnych problemach w kodzie.
Polecam także korzystanie z obsługi narzędzi, gdy ma to sens. Narzędzia analizy statycznej mogą pomóc w znalezieniu niektórych defektów, a niektóre nawet wspierają sprawdzanie stylu w celu wymuszenia spójności i dobrego stylu kodu. Używanie IDE z uzupełnianiem kodu i podświetlaniem składni może również pomóc w zapobieganiu lub wykrywaniu niektórych problemów przed kliknięciem „buduj”. Testy jednostkowe mogą obejmować problemy logiczne. A jeśli Twój projekt jest wystarczająco duży lub złożony, ciągła integracja może połączyć je wszystkie w regularnie uruchamiany proces i tworzyć dla Ciebie ładne raporty.
źródło
Praca w pojedynkę oznacza, że o ile nie ufasz nieznajomym, że sprawdzą kod w Twoim imieniu, będziesz musiał spojrzeć na sposób pisania oprogramowania, aby zachować jego jakość.
Przede wszystkim powinieneś mieć środki, aby upewnić się, że kod spełnia wymagania, a po drugie, że twój kod będzie stosunkowo łatwy do zmiany, jeśli później zdecydujesz, że coś jest nie tak. Moja sugestia byłoby zastosować Development Behavior Driven podejście z następujących powodów:
Chodzi o to, że ciągłe refaktoryzowanie kodu, nawet po zdaniu testów, oznacza, że skutecznie przeglądasz własny kod i używasz testów jednostkowych jako „dodatkowej pary oczu”, która upewnia się, że kod nie „ t zboczyć z wymagań zakodowanych w testach. Ponadto wysoki zasięg testu oparty na wymaganiach gwarantuje, że będziesz w stanie zmienić swój kod w przyszłości, nie spełniając wymagań.
Prawdziwym problemem dla Ciebie będzie to, czy będziesz w stanie wykryć potencjalne problemy w kodzie, które wskażą na potrzebę refaktoryzacji. Na rynku istnieje kilka narzędzi do profilowania, które mogą ci w tym pomóc, a także kilka innych narzędzi, które dotyczą wskaźników jakości kodu. Mogą one często powiedzieć ci wiele rzeczy, których brakuje w recenzjach kodu, i są koniecznością przy samodzielnym opracowywaniu projektów. Jednak w rzeczywistości kluczem jest doświadczenie, a gdy już będziesz miał zwyczaj bezlitości w refaktoryzacji, prawdopodobnie staniesz się bardziej krytyczny wobec własnego kodu. Jeśli jeszcze tego nie zrobiłeś, sugeruję przeczytanie książki Martina Fowlera na temat refaktoryzacji jako punktu wyjścia i szukanie dobrego interfejsu BDD API, który Twoim zdaniem będzie działał dla Ciebie w dowolnym języku, z którym zdecydujesz się współpracować.
źródło
Ilekroć byłem w takiej samej sytuacji jak ty, próbowałem rozwiązać problem „zbytniej bliskości kodu, aby obiektywnie go zbadać” za pomocą narzędzi do przeglądania / pomiaru kodu. Jest rzeczą oczywistą, że narzędzie nie może dać takiej samej wartości jak doświadczony recenzent, ale nadal można go używać do wskazywania obszarów złego projektu.
Jednym z narzędzi, które uznałem za dość przydatne w tym względzie, było SourceMonitor . Jest to nieco uproszczone, ale daje dobrą opinię na temat średniego poziomu twojego kodu, taką jak liczba metod w klasie i złożoność każdej z metod. Zawsze uważałem, że ten rodzaj informacji był równie ważny (jeśli nie ważniejszy niż) wymuszanie stylów kodowania za pomocą narzędzi takich jak StyleCop itp. (Które są ważne, ale często nie są źródłem największych problemów). Używaj tych narzędzi ze zwykłymi zastrzeżeniami: wiedz, kiedy złamać ogólną zasadę, a coś, co jest zielone w narzędziu metryki kodu, nie jest automatycznie dobrej jakości.
źródło
Nie potrafię powiedzieć, ile razy wyjaśniałem coś recenzentowi kodu, a żarówka w mojej głowie włącza się i mówi: „Hej, poczekaj chwilę”. Często więc znajduję własne błędy w przeglądzie kodu, których druga osoba nie widziała. Możesz więc spróbować, po prostu zacznij wyjaśniać kod, tak jakby obok ciebie siedziała osoba, która próbowała zrozumieć, co zrobiłeś i dlaczego.
Inną rzeczą, którą często znajduję w recenzjach kodu, jest to, że programista faktycznie nie spełnił tego wymagania. Zatem porównanie twojego kodu i jego rzeczywistych wymagań jest dobrym sprawdzianem.
Często robimy takie rzeczy, jak pakiety SSIS, które mają podobne potrzeby strukturalne - dla przeglądów kodu opracowałem listę kontrolną rzeczy do sprawdzenia (czy konfiguracja jest poprawna, czy rejestrowanie jest skonfigurowane, czy korzysta z bazy metadanych, czy pliki znajdują się w standardowej lokalizacji, itp.). Możesz mieć pewne rzeczy, które byłyby przydatne do sprawdzenia za każdym razem podczas przeglądu kodu. Usiądź i zastanów się, co umieścisz na liście kontrolnej rzeczy, które chcesz sprawdzić w przeglądzie kodu (pierwszy element, upewnij się, że spełniono wymaganie, następny element może mieć coś wspólnego z błędami zalewania i logowania). Kiedy popełniasz błędy i je poprawiasz, możesz dodawać inne elementy do listy (powiedz coś, czy przechodzę do następnego rekordu w pętli, czy też mam zamiar bez końca powtarzać ten sam pierwszy element - wystarczy jedna nieskończona pętla, aby nauczę cię tego szukać!).
źródło
Daj mu 3 miesiące, a potem wróć i spójrz na swój kod. Obiecuję ci, że jeśli nie możesz znaleźć w tym czegoś złego (lub pytania, kto napisał te śmieci!), Jesteś lepszym człowiekiem ode mnie!
źródło
Zwykle drukuję cały mój kod, siadam w cichym otoczeniu i czytam go, znajduję wiele literówek, problemów, rzeczy do refaktoryzacji, sprzątania w ten sposób. To dobry sprawdzian, który moim zdaniem powinien zrobić każdy.
źródło
Po studiach byłem nauczycielem pisania. Z pewnością dało mi to pewne perspektywy kodowania, o których myślę, że wielu programistów nigdy by nie pomyślało. Jednym z najważniejszych jest odczytanie kodu na głos. Nie brzmi to dużo, ale dam idealny przykład, do którego myślę, że każdy może się odnosić.
Czy kiedykolwiek napisałeś wiadomość e-mail lub artykuł, przeczytałeś wiele razy, aby upewnić się, że jest poprawny, a następnie wysłałeś go tylko po to, by stwierdzić, że masz rażący błąd pisowni, literówki lub błędu gramatycznego? Zrobiłem to wczoraj, gdy poprosiłem klienta o naciśnięcie klawisza shit zamiast klawisza Shift. Kiedy czytasz w swojej głowie - widzisz to, co chcesz zobaczyć.
Jest to skrót do sugestii „poczekaj tylko dzień, tydzień lub miesiąc”. Jeśli czytasz to na głos, łapiesz te same rzeczy. Nie wiem, dlaczego jest tak skuteczny, ale po tym, jak usiadłem z setkami uczniów i kazałem im czytać na głos, wszystko, co mogę powiedzieć, to to, że działa.
źródło
Większość ludzi uważa swój kod za własne dzieci i karmi je ego raczej niż rzeczywistością. Podobnie jak w przypadku innych recenzji kodu, sprawdzaj go, gdy widzisz kod innej osoby. Całkowicie zapomnij, że coś napisałeś. Przejrzyj każdą linię kodu. Lista kontrolna byłaby pomocna z punktu widzenia estetyki przeglądu własnego kodu. Zautomatyzowane narzędzia do przeglądu kodu mogą w pewnym stopniu pomóc. Użyłem niektórych narzędzi, takich jak klocwork (oprogramowanie komercyjne), jest to dość przydatne, gdy pracujesz w dużych projektach i pracuje nad nim kilku programistów. Zawsze skupiaj się na wykrywaniu wad, a nie na korekcji.
Ale najlepszą praktyką byłoby sprawdzenie siebie, a następnie zaangażowanie co najmniej dwóch innych osób do przeglądu z wyróżnionymi rolami.
źródło
Zastanów się nad samodzielnym przeprowadzeniem inspekcji Fagana - będziesz musiał dostosować proces, ponieważ jesteś sam, ale powinieneś być w stanie uzyskać z niego całkiem sporo korzyści. Sztuką będzie znalezienie odpowiedniego „zestawu reguł” do oceny twojego kodu jako twórcy solo, a następnie dyscyplina w zadawaniu tych pytań w krytycznym, analitycznym i bezlitosnym usposobieniu za każdym razem. Podejrzewam, że być może zechcesz przeprowadzić burzę mózgów na własne 4-5 kluczowych pytań, a następnie rozwinąć je z czasem. Niektóre osoby sprzeciwiają się formalnym inspekcjom, ponieważ wydają się być czasochłonne ... zanim zdecydujesz, że są zbyt drogie, pamiętaj o wszystkich danych statystycznych, że prawidłowe przeprowadzenie inspekcji faktycznie skraca czas projektu. Oto link do Wikipedii, z którym możesz rozpocząć dalsze badania:
http://en.wikipedia.org/wiki/Software_inspection
Pojawiło się też kilka książek, np. Google dla „Software Inspection Process” autorstwa Straussa i Ebenau.
Inną opcją jest zapłacenie komuś za sprawdzenie ważnego projektu - a może zapłata od czasu do czasu za sprawdzenie całego kodu. Ten facet jest całkiem niezły, wylecieliśmy z niego kilka razy, aby szkolić naszych nowych deweloperów:
http://www.javaspecialists.eu/
źródło
Oprócz wszystkich zaleceń dotyczących przeglądu kodu, możesz użyć narzędzi takich jak PMD i findBug, aby zrobić pierwszy poziom rozsądku dla swojego kodu.
źródło
To nie zostało jeszcze umieszczone w odpowiedzi (ale zostało dodane jako komentarz do istniejącej odpowiedzi)
Przejrzyj swój kod po dobrze przespanej nocy, np. Zacznij dzień od przejrzenia kodu napisanego poprzedniego dnia.
Nie da to oczywiście wspólnego doświadczenia zespołu, ale pozwoli ci przejrzeć kod z nowej perspektywy.
Na przykład, jeśli zostawiłeś kawałek kodu z nieprzyjemnym hackowaniem, możesz nie być zbyt skłonny do jego naprawy, jeśli przejrzysz kod natychmiast po tym. W końcu, kiedy zaczynasz sprawdzać swój kod, wiesz już i zaakceptowałeś obecność tego hacka. Ale jeśli dobrze się wyspałeś, prawdopodobnie masz większą motywację do znalezienia lepszego rozwiązania.
Kiedy śpimy, mózg tak naprawdę nie przestaje pracować z naszymi problemami, więc możesz rzeczywiście znaleźć rozwiązanie, chociaż czasem mogą się one przedstawiać w dziwny sposób .
źródło