Praca jako jedyny programista: sprawdzanie kodu

39

Nie mam innego wyboru, jak pracować samemu i nie mogę znaleźć odpowiedniego rozwiązania, które pozwoliłoby mi przejrzeć moją pracę, sprawdzić zdrowie psychiczne, poprosić kogoś o burzę mózgów, omówić najlepsze praktyki i tak dalej.

Pomyślałem, że otrzymam odpowiedź z artykułu Jeffa Atwooda: W Programowaniu „One Is The Loneliest Number” , najlepszy, jaki mogłem znaleźć na ten temat, ale okazało się, że to tylko powtórzenie mojego pytania.

Wiem, że witryny Stack Exchange takie jak ta i Code Review to oczywista potencjalna odpowiedź, ale jak wielu by to doceniło, DALEKO od ideału:

Chociaż nie mogę wymienić wszystkich pułapek, często sformułowanie pytania i ułożenie go w samodzielny problem często wymaga tak dużo pracy, że zanim wystarczająco go przygotowałeś, odpowiedziałeś na własne pytanie więcej inaczej, niż zajęłoby to inaczej. Ponadto ukrywanie szczegółów w celu zadania dobrze zdefiniowanego pytania eliminuje możliwość zauważenia przez kogoś problemów, o których nie pomyślałeś. Ponadto, chociaż nie mogę do końca tego dotknąć, responsywności swobodnej rozmowy nie da się porównać z żadną formą dyskusji tekstowej w Internecie, o której mogę pomyśleć. I na koniec, nie chcę publikować całego mojego projektu, aby świat mógł przyjrzeć się reszcie wieczności, z oczywistych powodów.

Czy są jakieś odpowiedzi inne niż płacenie konsultantowi za sprawdzenie mojego kodu?

CL22
źródło
3
Mam również ten problem (choć przy projektach dla zabawy), tyle że mam szczęście, że mam kilku bliskich przyjaciół programistów gotowych przejrzeć mój kod.
Austin Hyde
23
Zawsze możesz porozmawiać ze sobą - jest to szczególnie przydatne do sprawdzania szaleństwa :-)
Danny Varod
4
Jeśli możesz sobie na to pozwolić, jest to jeden z powodów, dla których warto wynająć biuro / biurko w parku biznesowym (najlepiej tam, gdzie skupiają się ludzie IT). Miałem wiele dobrych rozmów z pracownikami IT w sąsiednich biurach, kiedy byłem samotnym programistą pracującym w biurze.
JW01
6
Praca w pojedynkę może być lepsza niż praca z idiotami.
Job
2
Nie do końca rozwiązanie, ale możesz spędzać czas na pogawędce SO lub na odpowiednim kanale IRC; które mogą złagodzić niektóre z obciążeń związanych z pracą samemu.
Tikhon Jelvis

Odpowiedzi:

36

Byłem w twoich butach i nie sądzę, że istnieje łatwe rozwiązanie. Płacenie konsultantowi za przegląd kodu nie jest dobrym sposobem na wydawanie pieniędzy. Jeśli twoim problemem jest to, że czujesz się samotny i nie masz z kim porozmawiać o programowaniu, nie mogę ci pomóc, ale jeśli naprawdę zależy Ci na poprawie jakości kodu, najlepiej go ustawić odłóż na bok i wróć do niego za około tydzień. Jeśli kod jest naprawdę zły, będzie to oczywiste, ponieważ nie będziesz w stanie go zrozumieć i możesz zacząć go refaktoryzować, aby miał sens. Po kilku iteracjach tego procesu zaczniesz zauważać wzorce kodu, które ułatwiają zrozumienie kodu i poprawi jego jakość.

davidk01
źródło
Dobry! ... 15
Marjan Venema
2
Teoretycznie może to zadziałać, w praktyce NIE MA SPOSOBU NA PIEKŁO , by spojrzał wstecz na kod napisany 2 tygodnie temu, jeśli to zadziała. Prawdopodobnie też nie powinien ... Jeśli powrót do przeszłości powoduje, że spędza się na nim tylko z tego powodu, że jest ładniejszy, to strata czasu, należy to zrobić, kiedy i jeśli zostanie dotknięty ponownie.
Thomas Bonini,
3
@Krelp: Cały czas patrzę na poprzedni kod i nie ma możliwości dodania funkcji i ogólnie utrzymania oprogramowania bez patrzenia na wcześniej napisany kod. Nie ma czegoś takiego jak idealna architektura, a nieszczelne abstrakcje są raczej regułą niż wyjątkiem, więc nie można uniknąć patrzenia na wcześniej napisany kod. Wiem, że kodery maratonów są ubóstwiane w kręgach programistycznych, ale kodowanie maratonu szybko prowadzi do wypalenia i porzuconych projektów, więc oprócz poprawy jakości kodu robienie przerw i powrót również utrzymuje mnie przy zdrowych zmysłach.
davidk01
@ David: wspomniałeś o spojrzeniu na kod po ustalonym czasie, nawet jeśli nie ma takiej potrzeby. Początkowo nie powiedziałeś, aby patrzeć wstecz na kod tylko wtedy, gdy musisz to zrobić, aby dodać nowe funkcje. Więc jeśli - zgodnie z tym, co powiedziałeś - musisz w końcu spojrzeć wstecz na cały stary kod, dlaczego nie zrobić więc za chwilę jest to istotne zamiast po określonym czasie?
Thomas Bonini,
3
@Krelp: Jeśli masz wystarczającą pewność co do swoich umiejętności, idź naprzód i patrz na działający kod tylko wtedy, gdy masz na to ochotę, ale jeśli dopiero zaczynasz i nie masz pewności, jak dobrze tworzysz swój kod, a następnie stale szukaj wróć do tego, co napisałeś kilka tygodni temu, a refaktoryzacja to naprawdę dobry sposób na naukę właściwej struktury kodu. Moja rada była dla osób, które chcą poprawić i dojść do punktu, w którym restrukturyzacja wcześniej napisanego kodu staje się coraz mniej konieczna, ponieważ początkowa wersja ma odpowiednią rozszerzalną strukturę. Z przyjemnością zignorujesz moją radę.
davidk01
17

Czy są jakieś odpowiedzi inne niż płacenie konsultantowi za sprawdzenie mojego kodu?

Nie.

Moja rada to dołączyć do lokalnej grupy programistów \ użytkowników i porozmawiać o swoich pomysłach z innymi. Porozmawiaj o swoim projekcie. Zapytaj innych, jak podeszli do niektórych problemów.

Jeśli sprawdzą Twój projekt, nawet bez patrzenia na Twój kod, powinno to wystarczyć.

Kretynowie
źródło
4
Robi to wielu profesjonalnych pisarzy.
JeffO
10

Istnieją techniki samokontroli, takie jak rozwój oparty na testach, który może pomóc w uzyskaniu informacji zwrotnej. Kiedy staje się to trudne, wiesz, że twoja architektura prawdopodobnie jest nie do zniesienia.

sformułowanie pytania i ułożenie go w samodzielny problem często wymaga tak dużo pracy, że zanim wystarczająco go przygotujesz, odpowiesz na własne pytanie w czasie dłuższym niż zajęłoby to inaczej.

Problem rozwiązany. Nie potrzebujesz zewnętrznej informacji zwrotnej na temat każdego wiersza kodu w celu poprawy, wystarczy dobre próbkowanie przy kluczowych rozwidleniach na drodze i staranne samodzielne sprawdzanie w punktach pomiędzy.

Musisz przestać myśleć, że możesz utrzymać ten sam poziom jakości pracując samemu w tym samym czasie, co ktoś pracujący w zespole. Jest powód, dla którego ludzie pracują w zespołach. Dobra wiadomość jest taka, że ​​nie masz konfliktów dotyczących decyzji projektowych. Zła wiadomość jest taka, że ​​nie masz konfliktów dotyczących decyzji projektowych. Mamy nadzieję, że dodatkowy czas poświęcony na utrzymanie jakości jest w pewnym stopniu równoważony przez zalety pracy w pojedynkę.

Karl Bielefeldt
źródło
Nie widzę tutaj odpowiedzi na TDD.
Aaronaught
1
@Aaronaught Jestem na tej samej łodzi co TS i mogę was zapewnić, że pisanie testów (przed kodem jak w TDD lub po nim) jest NAJLEPSZYM sposobem sprawdzenia, czy kod jest zdrowy. Jeśli nie możesz tego przetestować, jest źle.
stijn
1
@stijn: Może być (nieco) prawdą, że zły kod trudniej jest napisać testy, ale nigdy nie jest to niemożliwe - tak właśnie aktualizuje się starsze systemy. Nawet jeśli przyjmiemy na pierwszy rzut oka wątpliwe twierdzenie, że dobry kod prowadzi do dobrych testów, twierdzenie odwrotne wciąż nie zostało udowodnione; pozytywny wynik testu nie oznacza, że ​​kod ma jakąkolwiek rozsądną jakość. W rzeczywistości założenie TDD - „czerwony, zielony, refaktor” - w gruncie rzeczy oznacza pisanie niechlujnego kodu, który przechodzi test, a następnie refaktoryzację go w celu poprawy jakości, więc pod koniec dnia wracasz do miejsca, w którym zacząłeś, tylko z testami.
Aaronaught,
2
@Aaronaught: robisz ważne punkty, ale nadal utrzymuję, że testy są bardzo dobrym sposobem na sprawdzenie poprawności kodu (choć nie jest to jedyny sposób); doświadczenie mnie udowodniło, szczególnie przydatne jest sprawdzenie, gdzie SRP zostaje poważnie naruszone.
stijn
@ Mark: To miłe, ale wszystkie te anegdoty są warte nawet mniej niż twierdzenie reklamowe „Straciłem 50 funtów w ciągu 2 tygodni”, ponieważ rzecz, o której mówi się, nawet nie została zmierzona , a co dopiero zaobserwowana w kontrolowanych warunkach. Tak, istnieją dowody na to, że TDD zmniejsza defekty przedpremierowe, i to jest świetna rzecz; przeglądy kodu rozwiązują zupełnie inny problem i nie ma podstaw do przyjęcia, że ​​TDD rozwiązuje ten sam problem. Testy jednostkowe w „starej szkole” są prawdopodobnie lepsze do tego celu, ponieważ nakładają ograniczenia na testowanie poszczególnych klas zamiast ich grup.
Aaronaught
6

Poleciłbym jak najwięcej kontaktów sieciowych na konferencjach i lokalnych grupach użytkowników. Znam wielu programistów, którzy przez cały czas strzelają w oczyszczone fragmenty kodu pocztą e-mail lub im, tylko po to, aby zachować ostrość i wspólnie przejrzeć algorytmy. Nie, nie jest to rozmowa twarzą w twarz, i tak, czasami jest to problem z odkażaniem kodu, ale od czasu do czasu przegląd 20 kodów komunikatora może być bardzo przydatny, szczególnie gdy desperacko potrzebujesz drugiej pary oczu.

Morgan Herlocker
źródło
4

Jestem w podobnej sytuacji i polegam w dużej mierze na przepełnieniu stosu, jeśli chodzi o uzyskiwanie informacji zwrotnych na trudne pytania. Z racji tego, że muszę napisać opis problemu, stwierdzam, że odpowiedź często staje się oczywista. Jeśli chodzi o najlepsze praktyki, jestem programistą .Net i korzystam z ReSharper, który zaproponuje dobre praktyki alternatywne do kodu, który piszę (co czasami po prostu ignoruję - może to być trochę pedantyczne). Innym przydatnym narzędziem jest FxCop, który przeprowadzi statyczną analizę kodu i uwypukli wszelkie problemy, które nie pasują do jego zestawu reguł.

W przeciwnym razie to ty będziesz czytać i być na bieżąco z aktualnymi praktykami. Lubię poranną rosę Alvina Ashcraft'a za linki do nowości i ulepszeń w świecie .Net.

David Clarke
źródło
4

Sugerowałbym próbę utworzenia (lub znalezienia) małej grupy użytkowników. Udostępnij swój kod i zachęć wszystkich do działania, aby działał - pół godziny lub dłużej dziennie.

jmoreno
źródło
3

Konstruktywne informacje zwrotne z mojego doświadczenia są takie, że w pierwszych latach rozwoju programista byłby bardzo ważny, choć nie obowiązkowy, aby doświadczony programista sprawdził Twój kod, aby stworzyć podstawy. Po zdobyciu doświadczenia możesz zastosować podejście sugerowane przez @ davidk01, tj. Okresowo przeglądać własny kod, aby poprawić jego jakość.

Karthik Sreenivasan
źródło
2

Nie znam szczegółów twojej sytuacji, ale tam, gdzie teraz jestem, jest wielu głodnych doświadczonych studentów, którzy z radością pracują jako stażyści i czegoś się uczą.

Może się wydawać, że zajęcie się nimi i nauczenie ich tego i tamtego, ale wszyscy byliśmy tam, kiedy zaczynaliśmy i myślę, że nadszedł czas, aby spłacić.

Nie są ekspertami i czasami mogą cię wprowadzić w błąd, ale zwykle kwestionują wszystko i są pełne pomysłów i świetnie nadają się do dyskusji, w której musisz bronić każdego szczegółu kodu.

azerafati
źródło
2

Chociaż nie mogę wymienić wszystkich pułapek, często sformułowanie pytania i ułożenie go w samodzielny problem często wymaga tak dużo pracy, że zanim wystarczająco go przygotowałeś, odpowiedziałeś na własne pytanie więcej inaczej, niż zajęłoby to inaczej.

To samo dotyczy> 75% zadawanych przeze mnie pytań.

Nie jest to jednak argument za tym, aby nie zawracać sobie tym głowy. Jest to skutecznie debugowanie gumowej kaczki. Znajdujesz odpowiedzi na pytania, które Twoim zdaniem mogą się pojawić w odpowiedzi na twoje pytanie; co oznacza, że ​​myślisz o problemie z punktu widzenia różnych osób; co oznacza, że ​​myślisz o problemie ze wszystkich możliwych kierunków; co jest najlepszym sposobem na znalezienie wady.

W najlepszym wypadku ostatecznie udowodniłeś, że wyraźnie nie możesz wymyślić tutaj odpowiedzi. W „najgorszym” kończy się odpowiedź na własne pytanie. Zwróć uwagę na cytaty, ponieważ wcale nie jest tak źle. Być może było to trochę nieefektywne czasowo, ale powolne rozwiązywanie problemu jest lepsze niż szybkie decydowanie się na rozwiązanie problemu . W końcu szybciej uzyskasz rozwiązanie problemu.

Przykładem:

Kiedy byłem początkującym programistą, wiele razy zajmowałem się stroną błędów platformy ASP.Net . Potrzebowałem Google, aby dowiedzieć się, co jest nie tak. może minąć kilka godzin, zanim otrzymam właściwe rozwiązanie. Zasadniczo popełniłem każdy błąd w książce, a następnie musiałem poradzić sobie z konsekwencjami konieczności debugowania problemów.

Teraz, gdy pojawia się błąd, już znam „zwykłych podejrzanych”, co może być przyczyną problemu. Moja lista mentalna „zwykłych podejrzanych” skutecznie opiera się na problemach, z którymi najczęściej miałem problemy podczas mojej kariery. Bez wcześniejszej nieefektywnej pracy godzinnej w Googlingu nigdy nie zrobiłbym tej listy mentalnej . Ale teraz, kiedy mam tę listę mentalną, znacznie szybciej rozwiązuję problemy.


Ponadto, chociaż nie mogę do końca tego dotknąć, responsywności swobodnej rozmowy nie da się porównać z żadną formą dyskusji tekstowej w Internecie, o której mogę pomyśleć.

Trochę się tu nie zgadzam. Masz rację, że komunikacja internetowa jest mniej responsywna, ale (moim zdaniem) się mylisz, że jest to dla ciebie złe.

Jako samotny programista będziesz polegać na debugowaniu gumowej kaczki. Kluczowym składnikiem działania RDD jest oczekiwanie na pytania, które może mieć dla Ciebie gumowa kaczka. Oczywiście nie możesz polegać na tym, co faktycznie mówi gumowa kaczka.

Kiedy masz do czynienia z powolnymi systemami przesyłania wiadomości (wysyłanie wiadomości na StackOverflow lub komunikowanie się poprzez pisanie listów), z natury rzeczy zachęcasz się do upewnienia się, że otrzymałeś to poprawnie za pierwszym razem. Ponieważ konieczność poprawienia błędu będzie procesem powolnym i uciążliwym.
Dla porównania weź pod uwagę, że systemy szybkiego przesyłania wiadomości (konwersacja, komunikatory) możesz natychmiast coś poprawić. Zdolność do szybkiego poprawienia czegoś sprawia, że ​​ludzie są mniej motywowani do upewnienia się, że jest to poprawne.

Cztery przypadki w punkcie:

  • Kiedy tworzę własną osobistą analizę / listę rzeczy do zrobienia jako programista, nadal używam długopisu i papieru. Zauważyłem, że podczas pisania notatek omijam założenia i kłamstwa, ponieważ mój umysł myśli, że „mogę to łatwo naprawić później”. Jednak konieczność poprawienia czegoś, co napisałeś na papierze, jest denerwujące, musisz przekreślić rzeczy i napisać między wierszami, a dokument będzie wyglądał o wiele gorzej, gdy będzie na nim rysowanie. Pisanie na papierze zmusza mnie do sprawdzenia faktów, zanim zdecyduję się je napisać. To wychwytuje wiele nieporozumień wcześnie, zanim jeszcze napisam kod, który mógłby powodować błędy.
  • Moja babcia była sekretarką (wiek maszyny do pisania). Napisanie literówki w oficjalnym dokumencie oznaczało konieczność ponownego wpisania całej strony. Moja ciocia jest sekretarką (wiek edytora tekstu). Może polegać na automatycznym sprawdzaniu pisowni, a błędy można naprawić łatwo i przy minimalnym wysiłku. Nic dziwnego, że moja babcia popełnia znacznie mniej błędów pisowni i błędów ortograficznych w porównaniu do mojej ciotki.
  • Gry wideo były drukowane na kartridżach. Naprawienie błędu po wydaniu było prawie niemożliwe. Trzeba będzie ponownie wydrukować wszystkie naboje, rozprowadzić je wśród wszystkich dostawców i mieć nadzieję, że dostawcy w jakiś sposób będą mogli skontaktować się z klientami, którzy już kupili grę. Kosztowałoby to mnóstwo pieniędzy (podwójny fizyczny koszt produkcji) i nadal nie docierałoby do niektórych klientów. Teraz, w dobie łatek internetowych, twórcy gier okazali się znacznie mniej zainwestowani w testowanie swoich gier, aby mogli uniknąć błędów związanych z wydaniem, ponieważ o wiele łatwiej jest po prostu wprowadzić poprawkę bezpośrednio do każdego klienta. Wpływ popełnienia błędu jest zminimalizowany do punktu, w którym lepiej jest naprawić garść problemów po fakcie, niż testowanie wszystkich możliwych błędy, które mogą wystąpić.
  • Mieszkałem w mieszkaniu na trzecim piętrze, bez windy, i często musiałem zaparkować jedną lub dwie ulice od mojego budynku. Prawie nigdy nie zapomniałem zabrać czegoś z mojego samochodu. Teraz mieszkam w domu z samochodem tuż obok mnie na podjeździe. Cały czas zapominam zabierać rzeczy z mojego samochodu .

Podstawową ideą jest to, że trudny system wymiany zachęca ludzi do dokonywania poprawnych i sprawdzonych faktów wymian . Surowość kary (= trudny proces korekty) uczy, aby nie popełniać błędów.


Ponadto ukrywanie szczegółów w celu zadania dobrze zdefiniowanego pytania eliminuje możliwość zauważenia przez kogoś problemów, o których nie pomyślałeś.

Kiedy tworzysz MCVE , nie powinieneś go po prostu tworzyć i publikować w pytaniu. Najpierw powinieneś zrobić to sam , abyś mógł wyizolować problem. A potem, gdy myślisz, że problemu nie można już zmniejszyć, a nadal nie widzisz przyczyny; to masz ważne pytanie dotyczące StackOverflow.

Przykładem:

Zawsze mam drugi program Visual Studio z prostą aplikacją konsolową o nazwie Sandbox. Ilekroć napotykam problem techniczny, kopiuję niepoprawny kod do piaskownicy i zaczynam się nim bawić.

  • Co się stanie, gdy zmienię to ustawienie?
  • Czy mogę odtworzyć problem, jeśli skrócę kod?
  • Które ustawienia umożliwiają / uniemożliwiają odtworzenie problemu?

W 90% przypadków znajduję przyczynę problemu, ponieważ piaskownica pomogła mi spojrzeć na niepoprawny kod, nie rozpraszając go otaczającym kontekstem (lub, na przykład, niepewnością co do wartości, które pochodzą z różnych części kodu.

W pozostałych 10% przypadków mam minimalny kod do odtworzenia problemu, który stanowi doskonały przykładowy fragment do opublikowania na StackOverflow.


I na koniec, nie chcę publikować całego mojego projektu, aby świat mógł przyjrzeć się reszcie wieczności, z oczywistych powodów.

Kiedy już masz swój MCVE, nie powinieneś mieć dużo na drodze do osobistych (lub firmowych) informacji. Jeśli tak, ponieważ kod jest minimalny, łatwo jest zmienić nazwę rzeczy na bardziej podstawowy przykład foo / bar / baz.

Flater
źródło