Jak zareagowałbyś, gdyby ktoś powiedział ci, że Twój kod to bałagan?

86

Jestem dobrym programistą, a przynajmniej tak myślałem wcześniej. Zawsze lubię programować. I chcę nauczyć się wielu rzeczy na temat programowania, aby uczynić mnie lepszym programistą. Studiowałem programowanie przez 1 rok, a teraz pracuję jako programista przez prawie 2 lata. Krótko mówiąc, mam prawie 3-letnie doświadczenie w programowaniu.

Nasz zespół składa się z 5 programistów, a 4 z nas jest nowych, 1 ma ponad 3-letnie doświadczenie. Pracujemy nad programem od prawie roku i nikt nigdy nie sprawdzał mojego kodu, a ja dostałem stronę do pracy. Nigdy nie mieliśmy przeglądu kodu i wszyscy jesteśmy nowi, więc nie wiemy, jak wygląda czysty kod. Myślę, że programiści uczą się sami?

Wdrożyliśmy nasz program do programu bez dokładnych testów. Teraz jest ciasno i potrzebujemy zatwierdzenia i przeglądu kodu, zanim wprowadzimy zmiany w kodzie. Po raz pierwszy ktoś sprawdza mój kod i mówi, że to bałagan.

Czuję się taki smutny i zraniony. Naprawdę uwielbiam programować i zmuszanie ich do mówienia czegoś takiego bardzo mnie boli. Naprawdę chcę się poprawić. Ale wygląda na to, że nie jestem genialnym programistą jak w filmach. Czy możesz mi doradzić, jak być lepszym? Czy kiedykolwiek spotkałeś się z krytyką kodu i czujesz się naprawdę zraniony? Co robisz na tych wydarzeniach?

teamwork code-reviews maintenance

— początkujących
źródło

51

„Ale wygląda na to, że nie jestem genialnym programistą jak w filmach” . Twoim błędem jest wiara w to, co widzisz w filmach na temat twórców oprogramowania, hakerów i wszystkiego, co dotyczy technologii rzeczywistej.

— Stephen C

160

Gratulacje! Na dzień dzisiejszy jesteś oficjalnie prawdziwym programistą! Mówienie, że jesteś okropny, jest jednym z najważniejszych kroków w tym zawodzie. Nie rozumiem tego: każdy profesjonalny programista powiedział, że coś, co napisali, było okropne w pewnym momencie, i to coś szczypie, gdy jesteś nowy, ale to prawda i usłyszysz to wiele razy podczas kursu twojej kariery! Buck up, właśnie dołączyłeś do zawodu. Dobrzy programiści biorą te dźgnięcia i uczą się, aby nie popełniać tych samych błędów (zamiast tego robią różne za każdym razem!)

— Jimmy Hoffa,

15

@ newbie, kiedy jesteś nowy i zbudowałeś trochę ego i nie spieprzyłeś wystarczająco dużo, aby zdać sobie sprawę, że jesteś zły, jestem zły, wszyscy jesteśmy w tym źli, ponieważ to naprawdę trudne. Jeśli zostanie ci jakieś ego, przejdzie ono na drugą stronę, gdy popełnisz więcej błędów. Poważnie, podnieście rękę, jeśli jesteście profesjonalnym inżynierem i przypadkowo zdmuchnęliście bazę danych, zanim podnieście rękę

— Jimmy Hoffa,

14

Rozczarowany? Dlaczego do diabła miałbyś być rozczarowany? Mój były CTO zadzwonił do mnie w artykule, który napisał (nie wymienił mnie konkretnie, ale wszyscy w naszym zespole wiedzieli, o kim mówi), a pierwszą szansę, jaką dostałem , zacytowałem ten artykuł w jednej z moich odpowiedzi tutaj . Poza tym jestem złym programistą opisanym w tym pytaniu . Zachęciłem PO do opublikowania pytania, a nawet na nie odpowiedziałem;)

— yannis,

19

Pamiętajcie ludzie, tylko dlatego, że ktoś powiedział, że kod był zły, nie czyni go prawdziwym. Po usłyszeniu „Twój kod to bałagan” OP zasługuje na „i oto dlaczego”. Następnie można rozpocząć analizę .

— Tony Ennis,

175

Prawda jest taka, że prawdopodobnie za 2 lata, kiedy zobaczysz swój obecny kod, zgodzisz się, że to był bałagan. Nauka programowania jest niekończącym się procesem i zawsze znajdzie się ktoś, kto jest w tym lepszy niż ty.

Więc jeśli osoba, która powiedziała, że twój kod jest bałaganem, nie jest po prostu wredna i nie jest to kolejny przypadek choroby „zrobiłbym to lepiej” powszechnej wśród programistów, powinieneś zapytać ją, co dokładnie jest nie tak z twoim kodem i jak możesz poprawić to.

— onlineapplab.com
źródło

27

Masz rację! Śmieję się z mojego kodu 2 lata temu. Myślę, że za dwa lata będę się śmiał z mojego kodu. Po prostu trochę się tym podnieciłem. W każdym razie postaram się stać lepszym.

— nowicjusz

5

@newbie: Proszę bardzo. To naprawdę musisz wiedzieć. Moje motto brzmi: „Nigdy nie będę tak dobry, jak za dwa lata”, od ponad dziesięciu lat. I jeszcze się nie myliłem. Nie nauczyłem się tego aż tak daleko w mojej karierze, jak ty. Twój kolega wyświadczył ci wielką przysługę.

— pdr

27

Myślę, że sześć miesięcy powinno wystarczyć na nienawiść do twojego kodu. Martwię się, że pewnego dnia znajdę kod, który napisałem sześć miesięcy wcześniej, i nie znajdę w nim czegoś, czego nienawidzę. Byłby to znak, że nie rozwijam się jako programista.

— zzzzBov,

37

2 lata! Mogę śmiać się po południu z kodu, który napisałem rano.

— dan_waterworth

9

Powiedziałbym również, że recenzje kodu są niezwykle pomocnymi procesami. Jak stwierdza ta odpowiedź, jeśli w ogóle jesteś dobrym programistą, z czasem również pomyślisz, że to okropny kod - to naturalne. Powiedziałbym również, że twój recenzent kodu nie podchodzi do procesu recenzji poprawnie. To ma być konstruktywny proces krytyki, w którym przekazywana jest wiedza, a nie negatywny proces karny, w którym recenzowany programista czuje się nieznaczny. Neguje to wiele dobra, które może pochodzić z recenzji.

— Mattygabe,

68

Nie bądź dumny z tego, jak dobrze kodujesz. Bądź dumny z tego, jak dobrze się uczysz. Następnie nauczenie się, że Twój kod wymaga ulepszenia, daje Ci możliwość wykazania, jak dobry jesteś w nauce, zamiast krytykowania tego, jak zły jesteś programistą.

Przeczytaj http://www.perlmonks.org/?node_id=270083, jeśli nie masz pojęcia, o czym mówię.

— btilly
źródło

fajny artykuł. :) więc mam do czynienia z moim ego.

— początkujący

2

@newbie Dokładnie. Kiedy otrzymujesz krytykę swojego kodu, może cię to zdenerwować tylko wtedy, gdy twoje ego jest związane jakością tego kodu. Oddziel swoje ego od kodu, a problem zniknie.

— btilly,

5

Zgadzam się z dumą z tego, jak dobrze się uczysz, ale powinieneś również być dumny z tego, jak kodujesz. Jeśli nie jesteś dumny z tego, jak kodujesz, nie zostaniesz doprowadzony do poprawy.

— Bryan Oakley,

1

Powinieneś także uważać na dumę z nauki, ponieważ może to prowadzić do tych samych problemów, jeśli nie jesteś tak dobry w nauce.

— Nico Burns

Myślałem, że duma jest jednym z 7 grzechów głównych? Co się dzieje z tymi, którzy dziś to polecają? Co powiesz na poczucie zadowolenia z dobrej pracy.

40

Po ponad 20 latach wiem, że część mojego własnego kodu wciąż jest bałaganem. Wszystko sprowadza się do podjęcia decyzji między pisaniem najlepszego kodu a pisaniem tego, co jest wymagane do wykonania zadania. Wykonanie pracy w ustalonym czasie przebija niekończące się dążenie do technicznej perfekcji każdego dnia.

Sztuką jest nauczyć się go akceptować. Naucz się akceptować, że możesz zrobić lepiej. Naucz się żyć z wadami. Naucz się akceptować fakt, że tym razem i prawdopodobnie następnym razem nie uda ci się osiągnąć ideału, i że jest to celowy wybór, ponieważ alternatywa nie zapewnia. I to gorzej.

Oświadczenie: nic z tego nie powinno być czytane jako „zły kod jest OK”.

— Maximus Minimus
źródło

2

Dążenie do „wykonania pracy” jest mierne. Masz rację, działa i może być skuteczny - wystarczy spojrzeć na chińskie produkty. Ale dążenie do tego, aby wszystko było wspaniałe, sprawia, że 20 lat programowania jest warte, aby zostać przyjacielem. Patrząc wstecz na 20 lat, co to pokazuje - wykonywanie pracy lub wykonywanie pracy z dumą?

— kingdango,

9

Zawsze chodzi o „wykonanie zadania”, chyba że piszesz jakiś dziwny projekt artystyczny oparty na kodzie. Pisanie „dobrego kodu” vs. „miernego kodu” jest kompromisem między ukończeniem natychmiastowego zadania a zwiększeniem możliwości utrzymania kodu w celu wykonania zadania w przyszłości. Ignorowanie tego prowadzi do perfekcjonizmu, który prowadzi do nieosiągnięcia niczego. Przeciętny kod napisany szybciej jest lepszy niż dobry kod napisany powoli dla skryptu jednorazowego.

— Steven Burnap,

8

Podobnie jak długi pieniężne, dług techniczny szybko rośnie, a nauka zarządzania długiem technicznym jest jedną z podstawowych umiejętności programisty w świecie rzeczywistym. Każdy, kto ma wystarczająco dużo czasu, aby za każdym razem wykonać idealną robotę, jest albo niewiarygodnie dobry, poważnie niedostatecznie pracowany, albo sam się łudzi.

— Mark Booth

1

Osiągnięcie właściwej równowagi może być trudne, zwłaszcza że efekty kontynuowania miernego projektu są często znacznie bardziej widoczne niż skutki spędzania zbyt dużo czasu na udoskonalaniu projektu, gdy mierny projekt byłby doskonale wystarczający przez cały okres jego użytkowania.

— supercat,

1

To naprawdę zasmuca mnie, że „wykonanie pracy” i „techniczna doskonałość” nie muszą być oddzielnymi światami, które przedstawiacie. Osobiście nie czerpię wielkiej satysfakcji z mojego wydanego kodu, który jest całkowicie podejrzany i jest w ten sposób ze względu na ograniczenia czasowe i, jak to ująłeś, „wykonać zadanie” .

— crmpicco

39

Kod każdego jest bałaganem i nie ma dobrych programistów.

Tam są:

programiści, którzy wysyłają szybko,
programiści, którzy zawsze wysyłają semantycznie poprawny kod,
programiści zawsze wymyślający optymalne rozwiązanie i najszybszy algorytm,
programiści, których kod jest przyjemny dla oka.

Prawie, jeśli w ogóle, to ostatecznie ta sama osoba.

Są też programiści, którzy muszą dorastać i:

zapytaj co jest nie tak
nie należy komentować osobiście, jako miernika ich wartości jako istoty ludzkiej;
zdajcie sobie sprawę, że w zespołach istnieją wytyczne dotyczące składni i należy ich przestrzegać, i są one arbitralne, więc nie należy ich omawiać ad nauseam , ponieważ nie ma optymalnego rozwiązania ani słowa końcowego;
lepiej komentować swój kod;
lepiej komentować swój kod; (sic)
znaleźć łatwiejsze do debugowania, mniej sprytne, rozwiązania prostych, przyziemnych zadań;
wziąć udział w zajęciach SQL
(wysłałbym połowę populacji tego świata, aby wziął udział w zajęciach SQL, żeby być bezpiecznym)

To nie jest sztuka, to rzemiosło.
Zapewniamy, że jesteś sprytny: programujesz komputery, cholera.
Nadal AMD64i x86nie są zmuszeni siłą twojej prozy. Uprość wszystko.

— ZJR
źródło

3

Dosłownie śmiejąc się na głos. tak dobrze. roflcopters

— kingdango,

1

AMD64 i x86 nie są zmuszane siłą twojej prozy. - niesamowite.

— Sam Brinck,

+1 za udział w zajęciach w SQL

— HLGEM

28

Cóż, osoba mówiąca, że Twój kod to bałagan, nie jest konstruktywna, nawet jeśli ma rację. Podali ci powody, dla których to bałagan? Metody są zbyt długie, obowiązki zmieszane razem, zbyt wiele rozgałęzień itp. Szczerze mówiąc, każdy kod, który napisałem rok temu, powiedziałbym, że to bzdura, ponieważ od tego czasu nauczyłem się ton. Więc nie przejmuj się tym. Byłbym bardziej zmartwiony, gdybyś nadal lubił czytać kod, który napisałeś dawno temu.

Im czystsza jest twoja baza kodu, tym mniej czasu poświęcasz na walkę z bazą kodu, aby rozwiązać dany problem. Rok to świetny moment na rozpoczęcie, ponieważ możesz poczuć ból związany z decyzjami projektowymi podjętymi wcześniej w projekcie.

W moim obecnym projekcie dokonaliśmy kilkakrotnej aktualizacji, ponieważ poczuliśmy się bardziej komfortowo dzięki naszemu stosowi technologii. Należy to zachęcać i zanotować zadania, które trwają dłużej niż powinny z powodu obecnej bazy kodu.

Czy przejrzałeś niektóre starsze części napisanego kodu? Prawdopodobnie możesz zobaczyć rzeczy, które chciałbyś teraz zrobić inaczej lub zmienić.

Również, gdy wspominasz o braku testowania, zawsze jest to coś, na co warto spojrzeć. W naszym projekcie nie przeprowadziliśmy zautomatyzowanych testów, w wyniku czego powstało wiele wysoce sprzężonego kodu. Nawet jeśli nie piszesz regularnie testów jednostkowych / integracyjnych / czegokolwiek, zrobienie tego przez pewien czas pozwoli ci na uczynienie kodu bardziej modularnym (a co za tym idzie mniej bałaganu).

— Kryptic
źródło

26

Czuję się taki smutny i zraniony. Naprawdę uwielbiam programować i zmuszanie ich do mówienia czegoś takiego bardzo mnie boli. Naprawdę chcę się poprawić.

To jest dobre. To o wiele lepsze niż reakcja typu „mój recenzent nie ma pojęcia, o czym mówi”, „mój recenzent jest zbyt wybredny” lub po prostu „mój recenzent mnie nie lubi” i ignorowanie ich. Takie podejście jest dobre.

Ale wygląda na to, że nie jestem genialnym programistą jak w filmach.

Nie jestem pewien, jakie filmy oglądasz, ale 90% programistów w filmach jest tak fałszywych, że pod koniec sekwencji mam łzy.

Czy możesz mi doradzić, jak być lepszym?

Czytaj i ćwicz. Sprawdź książki, takie jak Code Complete lub The Pragmatic Programmer . Spójrz na Amazon na podobne książki.

Czy kiedykolwiek spotkałeś się z krytyką kodu i czujesz się naprawdę zraniony? Co robisz na tych wydarzeniach ...

Dlaczego czujesz się zraniony? Czuję się rozczarowany, że jestem takim debilem. Używam tej motywacji do czyszczenia kodu i upewnienia się, że nie popełnię tego samego błędu ponownie . Ostatnią rzeczą, którą chcę to zrobić, nie ucz się z tego. Zostałeś raz uśpiony, nie pozwól, aby to się powtórzyło z tego samego powodu.

Żaden programista nie rodzi się idealny ani nawet bliski. Im więcej kodu piszesz, tym więcej recenzji i opinii, które udostępniasz , sprawi, że będziesz o wiele lepszym programistą.

— Sójka
źródło

2

+1 za złożenie go razem i reviews you provideponieważ krytyczność wobec innych może być ważną praktyką w poprawianiu krytyczności własnego kodu w celu uzyskania lepszej jakości.

— Jimmy Hoffa

2

„90% programistów w filmach jest tak fałszywych, że pod koniec sekwencji mam łzy”. 90%? Jakie filmy są Państwo oglądać? : PI nie widziałem jeden film, który dokładnie opisuje co to robimy. A potem były „Miecznik” i „Dzień Niepodległości” ...

— Nik Bougalis,

Dobrze powiedziane i zwięźle tak!

— kingdango,

16

Jedną z najlepszych rzeczy w byciu programistą jest to, że każdy dzień to proces uczenia się. Zawsze znajdzie się ktoś, kto nie wie czegoś, co robisz, i zawsze będzie ktoś, kto wie coś, czego ty nie wiesz. Z pewnością nie uważałbym się za nigdzie indziej niż na poziomie podstawowym / młodszym, ale doceniam każdą krytykę, jaką mogę uzyskać, o ile jest to zarówno uzasadnione, jak i udzielone z szacunkiem.

Odpowiednia analogia może dotyczyć okresu, w którym byłem nauczycielem pisania na uniwersytecie, a także kiedy brałem udział w kursach pisania kreatywnego. Pisanie kodu do wszystkich celów i celów przypomina pisanie wiersza, eseju, opowiadania lub powieści. Każda osoba ma swój sposób na zrobienie tego, ale jednocześnie nawet najlepsi pisarze (lub w tym przypadku programiści) popełniają błędy lub pozwalają, aby sprawy wymknęły się spod kontroli. Często możemy nie zauważyć tych rzeczy, ponieważ przyzwyczajamy się do własnego głosu (lub, w tym przypadku, stylu kodu).

Podobnie jak w każdej dziedzinie, są tacy, którzy są uważani za ekspertów. Gdyby ci ludzie nie istnieli, nie mielibyśmy nikogo do nauki. Zakładając, że ta osoba jest naprawdę ekspertem, wysłucham jego wypowiedzi i zapytam, co byś zrobił, aby ulepszyć swój kod. Nigdy jednak nie zapominaj, że nie tylko on może udzielić pomocy; mamy szczęście, że istnieje mnóstwo zasobów, takich jak SE / SO.

— Paweł
źródło

9

„ Zawsze znajdzie się ktoś, kto nie wie czegoś, co robisz, i zawsze będzie ktoś, kto wie coś, czego ty nie wiesz ” - niesamowite; +1.

— Maximus Minimus,

Tak, i chcę się nauczyć wszystkiego, co mogę

— nowicjusz

@mh: Dodałbym, że mądra osoba nauczy się znacznie więcej, niż się myli. Nie oznacza to, że należy próbować się mylić, ale raczej nie należy się tym zniechęcać, pod warunkiem, że skorzysta się z okazji do nauki.

— supercat,

10

Bałagan jest raczej subiektywny. Najlepszą rzeczą, jaką możesz zrobić, to zapytać tę osobę (lub raport z przeglądu): dlaczego jest bałagan? (to znaczy z ich punktu widzenia)

Będą musieli Ci odpowiedzieć, a będziesz w stanie:

Argument przeciwko temu (oczywiście jeśli masz dobry powód)
Poczuj się bardzo szczęśliwy, ponieważ właśnie nauczyłeś się czegoś nowego, a twój przyszły kod będzie z pewnością bardziej niesamowity, ponieważ dzięki ich radom wiesz, jak zmniejszyć bałagan.

— Omega
źródło

Nie skomentował :( Ale oto mój kod -> codereview.stackexchange.com/questions/18719/...

— nowicjusz

jak myślisz, dlaczego jest bałagan?

— nowicjusz

7

@newbie: Zatem ten recenzent nie jest zbyt dobry. Jak programista powinien coś poprawić, nie wiedząc, na czym polega problem (nawet nie ma pojęcia!)?

— Omega,

1

Ok, dziękuję ... Nie jestem też programistą jquery. Jestem programistą Java ....

— nowicjusz

1

Tym razem dostępny jest tylko mój kod. W każdym razie masz rację, zapytam o więcej szczegółów na ten temat. Dziękuję :)

— nowicjusz

8

To, że się martwisz, jest dobrym znakiem. Zacznijmy od tego. Wspominasz, że lubisz programować, ale czy lubisz być profesjonalnym programistą? Jest duża różnica między entuzjastą a profesjonalistą. Jako profesjonalista będziesz pod stałą kontrolą produktu pracy.

Our team is composed of 5 programmers, and 4 of us are new

Fakt, że pracowałeś dwa lata bez żadnej konfrontacji, mówi mi, że pracujesz w bardzo wyluzowanej pracy, co nie jest tak dobre, jeśli naprawdę chcesz iść do przodu jako profesjonalista. Pamiętaj, że niektórzy z najlepszych programistów na świecie pracują dla fundacji Linux i bądź pewny, że nie są traktowani uprzejmie, kiedy popełniają marginalne błędy ... a tym bardziej „niechlujny kod”.

Aby szybko zapoznać się z niektórymi dość standardowymi wytycznymi dotyczącymi kodowania, Standardy społeczności współtwórców systemu Linux powinny dać ci wyobrażenie o poziomie odpowiedzialności, do której należy dążyć za swój produkt. Zobacz: UZYSKIWANIE PRAWEGO KODU.

Aby pogodzić się z tym stwierdzeniem, powinieneś nauczyć się przyjmować recenzję, ponieważ większość dobrego oprogramowania jest dokładnie sprawdzana. Potwierdza to prawo Linusa stwierdzające ...

„Jeśli jest wystarczającej liczby recenzentów, wszystkie problemy można łatwo rozwiązać”.

Osobiście widziałem, jak wysoko wykwalifikowani, odpowiedzialni i niezawodni programiści zdobywają siekierę za coś tak prostego, jak zapomnienie o pozostawieniu komentarzy ... więc jeśli ktoś powie ci, że twoje kody to bałagan, prawdopodobnie jest to ... Przejdź to ... Refaktoryzacja. To część koncertu.

I feel so sad and hurt.

Idź zrób aplikację smutku, aby ocenić, jak bardzo się denerwujesz, gdy nie aplikujesz siebie.

Odpowiedziałeś na swój problem ... Nie testujesz!

Po tym, jak napisałeś komentarz, że jesteś programistą Java, prawie się zdenerwowałem. Więc jeśli dobrze rozumiem, że mówisz, że ty i twój zespół programistów pracujesz w sklepie Java i nie masz ram testowych dla swoich aplikacji ...

Tam leży rub

„Wdrożyliśmy nasz program do programu bez dokładnych testów”.

Cribbing UML Creator Grady Booch ...

Amatorski inżynier oprogramowania zawsze szuka magii, jakiejś sensacyjnej metody lub narzędzia, którego aplikacja może uczynić tworzenie oprogramowania trywialnym. Znakiem profesjonalnego inżyniera oprogramowania jest wiedzieć, że nie ma takiego panaceum.

Alistair Cockburn udostępnia na swojej stronie wiele informacji na temat stosowania zwinnych metodologii w celu zwiększenia wydajności i jakości dla Ciebie i Twojego zespołu.

Jednym z najważniejszych aspektów programowania i życia jest znajomość swoich mocnych i słabych stron. Jeśli nie pracujesz nad swoimi słabościami, nie będziesz mieć dobrze zaokrąglonego zestawu umiejętności.

Outro ... Dobrze sobie radzisz - tylko nie jęcz. Pójdź naprzód w rozwoju swojego rzemiosła i pozwól, aby pasja do programowania działała dalej. Powodzenia :-)

— Eddie B.
źródło

5

Nie pozwól, aby twoje emocje przeszkadzały w ulepszaniu kodu. Celem przeglądu kodu jest znalezienie problemów, więc nie powinieneś być zbyt zaskoczony, jeśli takie są. To powiedziawszy, nie powinny to być również sesje bicia koderów.

Nie powinni też tak po prostu mówić „Ewwww” i na tym zostawiać. Zawsze istnieje powód, dla którego coś jest nie tak z programowaniem. Na przykład źle jest pozostawiać wiele skomentowanych kodów wszędzie, ale jest to złe, ponieważ zaśmieca kod i utrudnia czytanie, a nie dlatego, że ktoś tak powiedział w książce.

Twój kod nie jest tobą. Zapamietaj to.

— Michael Shaw
źródło

4

Będę tu kutasem i doradzę na podstawie ... no cóż, oczywistego. Oczywiście Twój kod JEST bałaganem lub pytaniem, które zadajesz, jest pytanie: „DLACZEGO ktoś mówi, że mój kod to bałagan?” Ale nie kwestionujesz przypuszczeń. Po prostu zachowujesz się zraniony i, szczerze mówiąc, może być płacz, ale nie ma uczucia, jeśli chodzi o uzasadnienie programowania.

Ale tak naprawdę, dlaczego pytasz? Wiesz, że Twój kod jest do bani, a może zadajesz inne pytanie. Gdyby ktoś powiedział mi, że śmierdziało moim kodem internetowym, śmieję się i mówię „dobrze, co jest z tym nie tak?” Gdyby powiedzieli mi, że śmierdzę JavaScript, dałbym programistom społecznym odpowiednik grubej wargi i nigdy nie poprosiłbym o radę, jak zareagować, ponieważ te małe suki są wyraźnie! @ # $ Ing źle.

Posiadaj to, w czym jesteś dobry. Naprawdę mam na myśli wzięcie za to odpowiedzialności. ponieważ potrzeba tylko jednego głupka, by zgadnąć. Nie proś o pozwolenie na bycie dobrym. Po prostu poznaj swoje rzeczy. Koniec.

— Erik Reppen
źródło

Amen. A znajomość swoich rzeczy wymaga ... cóż ... wysiłku, aby upewnić się, że znasz swoje rzeczy. Ale pamiętaj, aby również rozerwać kołnierzyk, tak robią teraz wszystkie elitarne dzieci. : /

— kingdango,

Tak, myślę, że właśnie doradziłem gdzie indziej bardziej doświadczonym deweloperom, którzy jako pierwsi przyznają, że się mylą. Mogę zamaskować wiele osobowości.

— Erik Reppen,

4

Pamiętaj: najgorszy kod, jaki kiedykolwiek zobaczysz, to Twój własny!

Jeff Atwood z codinghorror.com napisał dużo na ten temat, możesz zacząć tutaj: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

Jeśli chcesz się poprawić, zacznij czytać informacje o stylu kodowania, wzorach, przepływach pracy, w zasadzie wszystkim, co możesz dostać. Naucz się także więcej języków programowania, zobacz, jak to robią. Jeśli robisz OOP, przeczytaj to: http://en.wikipedia.org/wiki/Design_Patterns

Porozmawiaj także z innymi programistami i sparuj programowanie lub obejrzyj inne kody.

Popełnianie błędów jest nieuniknione, powtarzanie ich jest.

— Lucas Hoepner
źródło

To dobry sentyment (mój ulubiony jest związany z tym, że zawsze zaczynam od założenia, że problem z aplikacją to moja wina), ale niestety okazuje się, że nie, najgorszy kod, jaki kiedykolwiek zobaczysz, może nie być twoim własnym ... , nie, jeśli jesteś wystarczająco bystry, żeby tu być i zapytać o to w pierwszej kolejności ...

— Murph,

4

Przez większość czasu powinieneś powiedzieć „dziękuję” osobie, która ci to powiedziała.

Są szanse, że dbają o swój zawód, dbają o swoją pracę, dbają o swój zespół i dbają o Ciebie.

Krytyka może być trudna. Nie denerwuj się tym. Pomyśl o tym, co próbują ci powiedzieć i nie pozwól, aby twoje emocje zwyciężyły.

Programuję od dłuższego czasu (30 lat), a mój styl i kod cały czas się poprawiają (mam nadzieję). Jedyny sposób, w jaki wiem, że się poprawia, to kiedy inni ludzie mi mówią lub wrócę i sprawdzę mój kod.

Spróbuj przyjrzeć się kodowi, który napisałeś na początku swojej kariery. Jak ci to teraz wygląda? Czy wygląda tak dobrze, jak się spodziewałeś, kiedy to napisałeś;)

— Fortyrunner
źródło

3

Przede wszystkim musisz zrozumieć, że programowanie jest procesem iteracyjnym, podobnie jak pisanie artykułu lub książki. Najpierw napisz „wstępną wersję roboczą” swojego programu, aby uruchomić go. Na tym etapie Twój kod będzie bałaganem. Dlatego dokonujesz refaktoryzacji, aby kod był czysty. Następnie profilujesz i widzisz, co musisz zoptymalizować, aby przyspieszyć. Sztuką jest ciągłe refaktoryzowanie, w przeciwnym razie bałagan będzie narastał. Musisz regularnie czyścić kod, tak jak musisz czyścić dom.

Recenzje kodu są absolutnie niezbędne. Twój kod musi być sprawdzony przez co najmniej jedną inną parę oczu. Kiedy spędzasz niezliczone godziny, przyglądając się kodowi, przyzwyczajasz się do niego i możesz łatwo ominąć błąd lub zapach kodu, który twój współpracownik może natychmiast zauważyć.

Również wyjaśnienie kodu komuś innemu to świetny sposób na sprawdzenie, czy coś przeoczyłeś. To jest jak czytanie gazety, którą piszesz na głos. Twój mózg przetwarza informacje audio i wizualne na różne sposoby, a błędy można znaleźć w swoim rozumowaniu, zmieniając modalność. Ponadto, jeśli wyjaśnisz swój kod współpracownikowi, a coś nie ma dla niej sensu, jest to dobra wskazówka, że powinieneś ponownie go kodować.

Podczas przeglądu kodu bardzo ważne jest, aby zarówno autor, jak i recenzent sprawdzali swoje ego przy drzwiach. Celem jest ulepszenie kodu. Recenzent musi więc szanować, a autor musi mieć otwarty umysł. Pamiętaj, że to twoi współpracownicy będą musieli utrzymywać twój kod, więc musi to być dla nich jasne. Jeśli recenzent nie rozumie, co robi zmienna, zmień jej nazwę. Jeśli recenzent nie może zrozumieć, co robi blok kodu, przekształć go w funkcję o nazwie opisowej. Niezależnie od tego, co myślisz, jeśli Twoi współpracownicy nie rozumieją Twojego kodu, nie jest to dobre.

Mówiąc o refaktoryzacji, absolutnie musisz mieć platformę testów jednostkowych, ponieważ bez niej nie można refaktoryzować.

Na koniec gorąco polecam przeczytanie „Czystego kodu” Roberta C. Martina. Powie ci, dlaczego twój kod jest bałaganem i co możesz zrobić, aby go wyczyścić.

— Dima
źródło

3

Czy możesz mi doradzić, jak być lepszym?

Odpowiedź Jaya, która zaleca książki, jest dobra, ale wydaje się, że jesteś już w punkcie zwrotnym w pracy.

Przeszłość:

Nasz zespół składa się z 5 programistów, a 4 z nas jest nowych, 1 ma ponad 3-letnie doświadczenie. Pracujemy nad programem od prawie roku i nikt nigdy nie sprawdzał mojego kodu, a ja dostałem stronę do pracy.

Obecny:

Teraz jest ciasno i potrzebujemy zatwierdzenia i przeglądu kodu, zanim wprowadzimy zmiany w kodzie.

Wygląda na to, że Twoja firma / zespół / dział uczy się jako całość, zarówno pod względem zarządzania projektami i zespołem, jak i programowania. Rozpoczęcie przeglądu kodu jest doskonałą okazją do ulepszenia praktycznie we wszystkich obszarach, jeśli zostanie się odpowiednio uwzględnionym.

Wykorzystaj to jako okazję; zakładając, że przeprowadzasz wzajemne oceny (z innymi programistami w zespole), sugeruj im, że ten proces jest ważny i że każdy może się z niego uczyć.

Na początku będzie to szybki przegląd z wynikiem „tak, wygląda dobrze”. Przy odrobinie bardziej skoncentrowanego wysiłku możesz odrzucić od siebie pomysły: „tak, to działa, ale mógłbyś podejść do tego w ten sposób, co uczyniłoby twój cel wyraźniejszym ...”. Rób notatki na przyszłość, nawet jeśli kod zostanie uznany za odpowiedni do wdrożenia.

Jeśli to się powiedzie, musisz poprosić zespół i menedżera o pomoc, co często oznacza dla nich wyjaśnienie korzyści. Dla innych programistów jest to okazja do nauki. Dla Twojego menedżera jest to okazja do podniesienia umiejętności zespołu przy niewielkich kosztach, dlatego tworzenie wyników a) o większej wartości lub b) szybszych c) przy niższych kosztach utrzymania (zwykle duży problem!).

To zmiana kultury, której nie możesz samemu wymusić, ale możesz pomóc popchnąć rzeczy we właściwym kierunku!

Nie zapominaj, że taka zmiana kultury może być bardzo korzystna dla organizacji; dobrzy menedżerowie zauważą, że pracujesz nad ulepszeniem całego zespołu, co jest warte nagrody.

— Matt
źródło

3

Czy możesz mi doradzić, jak być lepszym? Czy kiedykolwiek spotkałeś się z krytyką kodu i czujesz się naprawdę zraniony? Co robisz na tych wydarzeniach?

Odpowiedź na to pytanie można znaleźć w firmach nowej generacji. Byłem w takich firmach jak Google i FaceBook i widzę, że jeśli podążasz religijnie za procesem Agile / Scrum, możesz pisać lepszy kod i ulepszać go przy każdym sprincie.

How to be better?

Odpowiedzią jest ciągłe refaktoryzowanie. Nowoczesne narzędzia programistyczne, takie jak studio graficzne, zawierają wiele narzędzi, które pomagają w tym procesie. Jeśli postępujesz zgodnie z procesem tworzenia oprogramowania Scrum, powiedz na przykład, że napisałeś zły kod w pierwszym cyklu sprintu i ktoś zauważył podczas przeglądu, że jest zły, a następnie w sprincie 2 masz możliwość zmiany kodu.

Problemy te występują przede wszystkim z powodu braku dobrego procesu. Rozwiązaniem jest zatem opracowanie dobrego procesu tworzenia oprogramowania dla zespołu i przećwicz ciągłe refaktoryzowanie.

— Avinash Kumar
źródło

3

Chciałbym im podziękować za informację zwrotną, a następnie poprosić o wyjaśnienie, co czyni to złym i jak należy to poprawić.

Jeśli zgadzasz się, że osoba przekazująca informacje zwrotne ma sens, rozważ wprowadzenie zmian w przyszłości. Ale pamiętaj, tylko dlatego, że ktoś mówi, że to nie znaczy, że to prawda.

Czy możesz podać konkretne przykłady tego, co nazwano „bałaganem”?

— Tony Ennis
źródło

Uczucia mogą czasem być trudne, ale z pewnością mam taką nadzieję.

— Thomas Padron-McCarthy

3

Po pierwsze, ktoś, kto mówi, że Twój kod to bałagan, jest bardzo niejasny i subiektywny. Może oznaczać różne rzeczy dla różnych ludzi. Dlatego; należy wziąć pod uwagę dwie różne rzeczy.

Struktura

Struktura twojego kodu jest regulowana przez język, standardy branżowe i standardy firmowe, żeby wymienić tylko kilka. Oczywiście są też inne czynniki.

Są to rodzaje błędów, które identyfikują włókna, narzędzia testowe i podobne produkty. Są dobrze zdefiniowane i Ty lub Twoje narzędzia możecie podejmować obiektywne decyzje co do ich ważności / poprawności.

Styl

Pomimo ustandaryzowanej struktury / reguł dla kodu, każdy programista ma określony styl w sposobie pisania i podejścia do problemu lub zadania. Wykonuj konserwację kodu w dowolnym środowisku zespołu, az czasem będziesz w stanie zgadnąć, kto napisał kod w oparciu o styl. Będziesz także rozwijać swój własny styl, który będzie się zmieniał w miarę zdobywania doświadczenia i nauki rzemiosła.

Więc za każdym razem, gdy ktoś mówi, że Twój kod jest bałaganem , musisz zrozumieć, jeśli mówi on o strukturze lub stylu . Są to dwie bardzo różne rzeczy; struktura jest obiektywna, a styl absolutnie subiektywny.

Biorąc to pod uwagę, wszelkie konstruktywne opinie od innych programistów mogą być dla ciebie bardzo cenne. Wszystko zależy od ciebie i tego, jak podejmiesz krytykę. Z czasem dowiesz się, kogo wziąć sobie do serca, a kogo wziąć z odrobiną soli.

W miarę postępów w karierze spojrzysz wstecz na swój kod i zobaczysz rzeczy, które możesz zrobić inaczej, lepiej, czysto i szybciej. Jest to część procesu uczenia się, a dostrzeganie własnych błędów w przeszłości jest prawdziwym sygnałem, że szlifujesz i doskonalisz swoje rzemiosło.

Nie pozwól, by odrobina krytyki uspokoiła cię. Weź z tego, co możesz, a jeśli jest to sensowne i cenne, dodaj to do swojego zasobu wiedzy.

— Stephen
źródło

3

Choć ważne jest, aby rozpoznać, kiedy własny kod jest bałagan (bardzo typowe uczucie wśród programistów, szczególnie, ponieważ stają się bardziej doświadczony i ich wcześniejszych epok kodu) jest nawet bardziej ważne, aby słuchać, gdy inni ludzie wam tak.

W twoim kodzie jest tylko tyle problemów, które możesz rozpoznać, ponieważ zostały one stworzone w ramach twojej obecnej wiedzy programistycznej.

Przegląd kodu jest niezbędną okazją do nauki, ponieważ prawdopodobnie naraża cię na nową wiedzę, której nie miałeś podczas pracy nad kodem (w przeciwnym razie używałbyś go i nie byłoby bałaganu).

Myślę, że przetwarzanie negatywnych opinii składa się z dwóch części.

1. Określ charakter poruszonych problemów i czego należy się z nich nauczyć

Kiedy przeglądam lub sprawdzam mój kod, sortuję informacje o problemach z kodem w przybliżeniu w takich segmentach:

narusza twarde wymagania technologiczne
- po prostu źle (nie działa lub nie spełnia wymagań)
- zawiedzie w innych okolicznościach (zmiana środowiska / konfiguracji)
- używa przestarzałej funkcjonalności i ulegnie awarii w dającej się przewidzieć przyszłości
narusza najlepsze praktyki branżowe, brakuje takich rzeczy jak
- stosując sprawdzone podejście do konkretnego problemu
- występ
- kompatybilność wsteczna
- łatwość konserwacji
- styl kodowania
- dokumentacja
narusza najlepsze praktyki w miejscu pracy
- taki sam jak przemysł, ale bardziej specyficzny dla firmy / współpracowników i może różnić się szczegółami od branży
niezgodne z osobistą wiedzą specjalistyczną
- może być w jakiś sposób poprawiony, w opinii osoby recenzującej

Zauważ, że waha się to od bardzo obiektywnych rzeczy („to się zepsuje po wdrożeniu na naszym serwerze produkcyjnym”) do bardzo subiektywnych rzeczy („Nie podoba mi się, jak nazwałeś zmienne”).

2. Ustal, które (jeśli jakieś) zmiany w kodzie zostaną wprowadzone w wyniku przeglądu

Po przetworzeniu informacji pojawia się decyzja, czy można ją wykonać i czy należy zmienić kod. To niekoniecznie jest twoja decyzja, twoja opinia może, ale nie musi mieć znaczenia, w zależności od zaangażowanych stron i specyfiki twojej sytuacji (staż pracy itp.). Ale możliwe wyniki to w przybliżeniu:

rozwiązać problem w całości
- naprawić uszkodzony
- format do wymaganego stylu kodowania
- i tak dalej
dojść do kompromisu, jeśli problem należy rozwiązać w całości lub w części, ponieważ może tak być
- brak zasobów (takich jak czas lub budżet)
- nie ma potrzeby (osiągnie jedynie nieznaczną poprawę, zagrozi stabilności itp.)
zrozumiałem, że podniesiony problem jest nieważny
- informacje zwrotne (szczególnie z subiektywnej kategorii opinii) mogą być bardzo szkodliwe i nie powinny być podejmowane na ślepo

Nauczyłeś się, że bolesne jest otrzymywanie negatywnych opinii i bardzo dobrze może być bolesne za każdym razem w przyszłości. Jednak odszedłeś, aby dowiedzieć się, jak ważna jest szansa na naukę i jak ten proces pomaga ci ulepszyć zawodowo i miejsce pracy, aby osiągnąć lepszą bazę kodu.

— Rarst
źródło

1

Nie czuj się złamany. W końcu nauczysz się na błędach. Po zakończeniu problemu możesz porozmawiać z facetem, aby poczuł, że chcesz się poprawić. Spróbuj słuchać więcej i mniej się kłócić.

Przeszedłem przez tę sytuację i rozumiem.

— Hisham
źródło

0

TL; DR

Jak zareagowałbyś, gdyby ktoś powiedział ci, że Twój kod to bałagan?

Moje proste: „zbyt długo nie czytałem (wszystkie odpowiedzi - przepraszam, mam nadzieję, że znajdę czas na później i w razie potrzeby edytuję / poprawię)” odpowiedź / wskazówka:

Dobra, stara recenzja. Poproś różne załogi o różnych mentalnościach zbiorowych, poziomach wiedzy specjalistycznej i / lub poziomach agresywności o sprawdzenie kodu.
Aby rozwinąć nieco to, co rozumiem przez „różne” grupy rówieśnicze: diaspora StackExchange jest prawdopodobnie najbardziej zamożną, profesjonalną i cenioną grupą ze względu na względną trudność w byciu jej częścią w porównaniu, powiedzmy, z Reddit. Reddit wydaje się być bardzo agresywny w bardziej popularnych pod-redditach - ale o dziwo, podreddity programistyczne są dość przyjazne (z tego, czego doświadczyłem).

Dobrym, być może najlepszym przykładem agresywnej, gangsterskiej mentalności kliki są tłumy XDK Forum, a najgorsze z najgorszych trofeów, jakie wręczam forom CyanogenMod for Android / kanałowi IRC.

To było trochę dłużej niż zamierzałem; Miałem na myśli, że - otrzymuj różnorodne recenzje, ale skup się na uzyskaniu uczciwej krytyki od ludzi, którzy znają się na swojej branży i wiedzą, jaka jest konstruktywna krytyka. Och, i być w stanie przyjąć jakąkolwiek formę krytyki, nie pozwalając, by cię to przygnębiło. Ogólna zasada: jeśli zaczniesz słyszeć podobne komentarze dotyczące rzeczy, które mogą być wzajemne dla komentarzy, zrób bardziej szczegółową introspekcję.

— skopp
źródło