Jak mogę sprawdzić swój własny kod? [Zamknięte]

177

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?

Max Yankov
źródło
34
Nie jestem pewien, czy potrafisz, a przynajmniej nie skutecznie - możesz zebrać zespół recenzentów na codereview.stackexchange.com, jeśli Twój kod nie jest zastrzeżony
jk.
8
Nie możesz przejrzeć własnego kodu. Jeśli nie możesz zdobyć innych ludzi, rozważę, co możesz zrobić, aby użyć tak wielu analizatorów statycznych, jak tylko możesz, i włączyć WSZYSTKIE ostrzeżenia.
136
Przeglądanie własnego kodu jest łatwe. Napisz kod częściowy. Odsuń się na 2 tygodnie / miesiące / lata, kontynuując naukę i rozwój innego oprogramowania. Wróć do tego fragmentu i spróbuj zrozumieć, co robi kod. Wiesz, że nauczyłeś się czegoś, kiedy myślisz: „jaki idiota to napisał ?!”.
Jurij Zubariew
6
@YuriyZubarev Ale co, jeśli nie chcesz czekać na tygodnie / miesiące / lata?
anatoliiG
12
Możesz przejrzeć swój kod w zmienionym stanie umysłu. Lub możesz kodować w zmienionym stanie umysłu i przekazać przegląd kodu zwykłemu nudnemu ja.
Logika SK

Odpowiedzi:

92

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

  • testy sprawdzające istnieją i zaliczają (możliwe, że mają docelowy zakres testów, chociaż w niektórych przypadkach może być konieczne ich przerwanie, ale powinieneś być w stanie uzasadnić dlaczego)
  • sprawdź, czy analiza statyczna przebiega pomyślnie (pojawią się tutaj również fałszywe negatywy, ale jest to w porządku, o ile możesz uzasadnić, dlaczego to jest w porządku, aby je ukryć)
  • utrzymuj listę kontrolną dalszych rzeczy do sprawdzenia w trakcie przeglądu (najlepiej dodaj to jako nowe reguły analizy statycznej, jeśli to możliwe), upewnij się, że zaznaczysz wszystko, czego SA nie może sprawdzić, np. czy komentarze są nadal aktualne, czy rzeczy są odpowiednio nazwane (nazwanie rzeczy to oczywiście jeden z 2 trudnych problemów znanych informatyce)
  • w przypadku wykrycia usterki sprawdź, czy przyczyna ma charakter systemowy, i sprawdź, dlaczego nie znaleziono jej we wcześniejszych testach lub przeglądach

Jest to oczywiście przydatne, gdy przeglądasz także kod innych użytkowników

jk.
źródło
3
Jeśli chodzi o listę kontrolną, posiadanie specyfikacji jest bardzo przydatne.
Wayne Werner,
Nie lubię list kontrolnych. Sprawiają, że recenzent koncentruje się na liście kontrolnej zamiast myśleć o problemie, rozwiązaniu i wielu innych rzeczach. Sugeruję więc, aby były minimalne.
Balog Pal
57

Zajrzyj na stronę Code Review Stack Exchange. Służy do udostępniania kodu z projektów, nad którymi pracujesz, do wzajemnej oceny :

Przegląd kodu Stack Exchange to witryna z pytaniami i odpowiedziami służąca do weryfikacji recenzji kodu. Pracujemy razem, aby poprawić umiejętności programistów na całym świecie, pobierając działający kod i ulepszając go.

Jeśli szukasz opinii na temat konkretnego działającego kodu z twojego projektu w następujących obszarach ...

  • Najlepsze praktyki i wykorzystanie wzorców projektowych
  • Problemy z bezpieczeństwem
  • Występ
  • Poprawność w nieprzewidzianych przypadkach

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.

BЈовић
źródło
2
To doskonała odpowiedź na pytanie „Jak sprawdzić mój kod” i ogólnie dobra rada (na pewno to zrobię) - ale wciąż trochę nie na temat.
Max Yankov,
5
Zwykle nie lubię odpowiedzi składającej się z 5 słów, ale ta jest w porządku .
wałek klonowy
20
W najlepszym razie jest to tylko ograniczone rozwiązanie. Ciągłe umieszczanie całej swojej dziennej wydajności na CR.SE nie jest możliwe, ponieważ duże fragmenty będą dość przyziemnym kodem. CR.SE nie będzie również bardzo pomocny w wykrywaniu problemów, które wymagają nietrywialnego zrozumienia całej architektury aplikacji lub domeny, dla której aplikacja jest napisana. Z nieformalnego punktu widzenia spójrz na kod współpracowników, gdy jest sprawdzony stylowo, recenzje, w których pracuję, tego rodzaju błędy są prawdopodobnie bardziej powszechne niż te, które byłyby odpowiednie do przechwytywania za pośrednictwem CR.SE.
Dan Neely,
3
Prawdziwą wartością podczas recenzowania jest otrzymanie fragmentów kodu, które nigdy nie przedstawiłyby problemu zauważonego i wyróżnionego jako nieoczywisty, nie wyjaśniający się ani nawet nielogicznie poprawny . Nie możesz opublikować tego fragmentu, code reviewjeśli jeszcze nie wiesz, że to problem.
ZJR
3
@ZJR Czy kod w twoich projektach jest w 100% sprawdzany? Jeśli tak, twoi inżynierowie mają za dużo wolnego czasu. Co do twojego drugiego komentarza, nie widzę problemów z prośbą o sprawdzenie kodu w kodzie, który Twoim zdaniem jest idealny.
BЈовић
29

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.

shabunc
źródło
27
Nazywam się Bill, Jeff, Bob i Alice, i zatwierdzamy tę wiadomość.
Michael K
22

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ę:

  • czy nazwy zmiennych / metod / klas nadal odzwierciedlają to, do czego są używane?

przegląd długoterminowy (6 miesięcy po sporządzeniu kodu)

Pytam siebie:

  • czy mogę opisać jednym sentymentem, co robi klasa / metoda / zmienna?
  • jak łatwo jest używać klasy w oderwaniu (bez innych klas) lub napisać nieprzyzwoity dla?
k3b
źródło
4
+1 za sugestie przeglądu krótkoterminowego. Korzystanie z git do przeglądania wszystkich zmian między różnymi punktami w czasie może naprawdę pomóc w oczyszczeniu kodu.
Leo
Cicho mi się podoba pomysł na przegląd długoterminowy, myślę, że prawdopodobnie połączyłbym go z ogólną recenzją projektu i może nie przejrzałbym całego kodu (potem znowu nie robię dużo rozwoju solo)
jk.
Próbuję zrobić coś pomiędzy: przejrzyj mój kod za około miesiąc. Podoba mi się również 6-miesięczna recenzja.
David G
18

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.

Jim C.
źródło
15

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.

Patrick Hughes
źródło
3
Wierzę, że technika kaczki została wynaleziona niezależnie w wielu miejscach; oto świetna historia na ten temat: hwrnmnbsol.livejournal.com/148664.html
Russell Borogove
10
Obecnie moją gumową kaczką jest formularz zadawania pytań Stack Exchange. Chęć napisania dobrego pytania załatwia sprawę .
Kevin Reid
Doskonała rada. Jest jeszcze lepiej, ponieważ mam już gumową kaczkę na biurku (była tutaj jako model dla jednej z moich postaci z gry, ale myślę, że nie będzie miała nic przeciwko dodatkowej pracy konsultanta IT).
Max Yankov
5
@KevinReid, chciałbym kochać , aby zobaczyć kilka statystyk na opuszczonych stanowisk SE - zwłaszcza te, które osoby zostały wpisując dłużej niż 60s dalej. Wiem, że zrobiłem to samo co najmniej 5 razy.
Wayne Werner,
Wah! Nie wiedziałem, że to „rzecz”. Właśnie skomentowałem powyżej, że mój profesor nauk ścisłych polecił to podczas naszego pierwszego wykładu sprzed dziesięcioleci. Polecił kota, ale przypuszczam, że zrobiłaby to gumowa kaczka. Jedno jest pewne, nie działa bez pomocnika antropomorficznego :-)
Mawg
13

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ę.

Steve Jackson
źródło
Nie sądzę, aby można było przejrzeć własny kod
BЈовић
4
@VJovic - Nie sądzę, że przeprowadzam najlepszą weryfikację kodu na moim kodzie, ale zwykle znajduję rzeczy, które można poprawić. Czytam też wiele kodów innych osób. Mój punkt widzenia na to, jak wygląda „dobry” kod, stale się rozwija. Wstydzę się kodu napisanego przed laty. Nie różni się niczym od sprawdzania własnego artykułu - wymaga praktyki i dużo więcej wysiłku, ale jest wykonalne. Kluczową rzeczą, której nie mogę ocenić, jest to, czy abstrakcja ma sens dla kogoś innego. Ale mogę zadać sobie pytanie, jak zrobić coś prostszego, czy jest to konieczne itp.
Steve Jackson
@VJovic - jak wspomniał ThomasOwens, możesz również utworzyć listę kontrolną na podstawie błędów z przeszłości i przejrzeć ją dość obiektywnie. To kolejna miła rzecz w byciu formalnym, możesz zobaczyć, co przegapiłeś podczas przeglądu i odpowiednio dostosować swój proces. Uważam, że uczę się wielu lekcji, śledząc siebie i starając się zmienić swoje podejście, gdy jest to wskazane.
Steve Jackson
3
Właściwe nastawienie jest bardzo ważne. Uważam, że to pomaga, jeśli faktycznie wydrukuję kod i przejdę go na papierze za pomocą pisaka. Potem nie mogę nic zmienić podczas recenzji (co uniemożliwia mi przejście do trybu kodowania) i mogę łatwo napisać komentarze i strzałki ruchu na papierze.
Leo
Oznacza to przeglądanie starego kodu, a nie nowego kodu. W tym celu musisz zdobyć doświadczenie, które może potrwać długo.
BЈовић
9

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:

  • Przygotuj szorstką listę kontrolną. Są to rzeczy, które chcesz oflagować podczas czytania kodu.
  • Przenieś swoją recenzję kodu w tryb offline. Może to wydawać się marnotrawstwem, ale weź wydruki, które możesz opatrywać adnotacjami i przewijać w przód iw tył, lub cyfrowy odpowiednik ładnie wyróżnionych plików PDF zsynchronizowanych z iPadem, który jest następnie wyłączany. Odejdź od biurka, aby wszystko, co robisz, było wolne od rozpraszania kodu.
  • Zrób to wcześnie rano, a nie na koniec dnia roboczego. Świeża para oczu jest lepsza. W rzeczywistości może pomóc być z dala od kodu na dzień przed ponownym sprawdzeniem go.

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ę.

Aditya Sahay
źródło
3
Dodałbym też „poczekaj 24 godziny”, żebyś nie patrzył na kod, który właśnie napisałeś. Upewnij się, że ma co najmniej 1 dzień, więc widzisz go po spaniu przez noc i nie dotykając go przez 24 pełne godziny.
Jeff Atwood
Często używam wydruków, gdy muszę przejrzeć kod, a zwłaszcza go przefiltrować. Działa dla mnie cuda.
yitznewton
Podobnie jak w niektórych filmach dowiedzieliśmy się z GB, że fałszywy orgazm jest lepszy niż brak orgazmu - samoocena jest lepsza niż nic. Tak, możesz dużo trenować, żeby robić gumowe kaczuszki. Ale nadal jest dość nieskuteczny w porównaniu z faktyczną recenzją. szczególnie bez narażania się przez jakiś czas na dobrych recenzentów w celu wybrania metod.
Balog Pal
8

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.

Thomas Owens
źródło
7

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:

  1. BDD oznacza najpierw napisanie testu kodu. Dzięki temu cały kod jest objęty testami.
  2. BDD jest zasadniczo TDD, ale z nieco innym ukierunkowaniem i „językiem”. Oznacza to, że ciągle pracujesz nad kodem podczas pracy nad nim i używasz testów, aby upewnić się, że Twoje działania związane z refaktoryzacją są nadal zgodne z specyfikacją produktu.
  3. Język BDD zachęca do pisania testów w formie instrukcji, które zasadniczo kodują wymagania jako testy jednostkowe.

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ć.

rev. S.Robins
źródło
5

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.

Daniel B.
źródło
5

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ć!).

HLGEM
źródło
1
Jak sugeruje Patrick Hughes w swojej odpowiedzi, użycie zastępcy, takiego jak gumowe kaczątko, aby zastąpić recenzenta, pomaga w sposobie myślenia.
Russell Borogove
5

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!

Spedge
źródło
To też moja technika. 3 miesiące to wystarczająco długo, aby wszystko, czego nie potrafię od razu zrozumieć, musi zostać uproszczone lub udokumentowane lepiej, ale na tyle krótkie, że wciąż pamiętam, co się dzieje, aby łatwo to naprawić.
Eric Pohl,
5

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.

20326
źródło
Dobry dodatek do powyższej porady, dziękuję - chociaż myślę, że tablet lub coś takiego (z edytorem, ale bez środowiska programistycznego) też by działało. Zastanawiam się, kto głosował za tym i dlaczego.
Max Yankov
4

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.

mrtsherman
źródło
+1 To byłoby zgodne z podejściem „wyjaśnij to swojemu kotowi”. Używanie różnych części mózgu może być pomocne, gdy nie możesz skorzystać ze współpracownika.
BMitch
plus jeden za gówno
Mawg
3

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.

sarat
źródło
3

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/

użytkownik49613
źródło
0

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.

Ashish Sharma
źródło
0

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 .

Pete
źródło