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

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?

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.

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

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

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.

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

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

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.

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.

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

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.

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.

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.

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ś;)

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

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.

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.

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”?

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.

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.

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.

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