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

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?

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

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.

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.

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?

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.

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.

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

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

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.

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

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.

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

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!

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.

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.

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.

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/

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.

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 .