W którym momencie „konstruktywna” krytyka twojego kodu staje się nieprzydatna?


39

Niedawno zacząłem jako młodszy programista. Oprócz tego, że jestem jedną z najmniej doświadczonych osób w zespole, jestem również kobietą, która ma wiele wyzwań związanych z pracą w środowisku zdominowanym przez mężczyzn. Ostatnio mam problemy, ponieważ mam wrażenie, że dostaję zbyt wiele nieuzasadnionej pedantycznej krytyki mojej pracy. Pozwól, że podam przykład tego, co się ostatnio wydarzyło.

Kierownik zespołu był zbyt zajęty, aby wcisnąć kilka gałęzi, które stworzyłem, więc dotarł do nich dopiero w weekend. Sprawdziłem pocztę, nie zamierzając wykonywać żadnej pracy, i odkryłem, że moje dwie gałęzie zostały odrzucone na podstawie nazw zmiennych, dzięki czemu komunikaty o błędach są bardziej opisowe i przeniesienie niektórych wartości do pliku konfiguracyjnego.

Nie uważam, że odrzucenie mojej gałęzi na tej podstawie jest przydatne. Wiele osób pracowało przez weekend i nigdy nie powiedziałem, że będę pracować. W rzeczywistości niektóre osoby prawdopodobnie zostały zablokowane, ponieważ nie miałem czasu na zmiany i ponowne przesłanie. Pracujemy nad projektem, który jest bardzo wrażliwy na czas i wydaje mi się, że nie jest pomocne całkowite odrzucenie kodu w oparciu o rzeczy, które są przezroczyste dla klienta. Mogę się mylić, ale wygląda na to, że tego rodzaju rzeczy powinny być obsługiwane w zatwierdzeniach typu patch, kiedy mam czas.

Teraz widzę, że w niektórych środowiskach byłaby to norma. Jednak krytyka nie wydaje się równomiernie rozłożona, co prowadzi do mojego następnego problemu. Podstawą większości tych problemów był fakt, że byłem w bazie kodu napisanej przez kogoś innego i starałem się być minimalnie inwazyjny. Naśladowałem nazwy zmiennych używane w innym miejscu pliku. Kiedy to stwierdziłem, otwarcie powiedziano mi: „Nie naśladuj innych, po prostu rób to, co słuszne”. To chyba najmniej przydatna rzecz, jaką mogłem powiedzieć. Jeśli kod, który jest już zarejestrowany, jest niedopuszczalny, jak mam powiedzieć, co jest dobre, a co złe? Jeśli podstawa zamieszania wynikała z kodu źródłowego, nie sądzę, że ”

W tej sytuacji czuję się naprawdę wyróżniona i sfrustrowana. Udało mi się znacznie lepiej postępować zgodnie z oczekiwanymi standardami i czuję się sfrustrowany, że na przykład, kiedy zmieniam fragment kodu w celu sprawdzenia, czy brakuje wcześniej sprawdzania błędów, słyszę tylko, że nie spraw, aby błędy były wystarczająco szczegółowe (a gałąź została odrzucona na tej podstawie). Co jeśli nigdy go nie dodałem? Jak to się stało, że kod był tak źle? Właśnie dlatego czuję się tak wyróżniony: ciągle napotykam ten istniejący problematyczny kod, który albo naśladuję, albo refaktoryzuję. Kiedy go naśladuję, jest to „złe”, a jeśli go zmienię, jestem zniesławiany za to, że nie robię wystarczająco dużo (i jeśli pójdę na całość, wprowadzam błędy itp.). Ponownie, jeśli jest to taki problem, nie rozumiem, w jaki sposób jakikolwiek kod dostaje się do bazy kodu,

W każdym razie, jak sobie z tym poradzić? Proszę pamiętać, że powiedziałem na górze, że jestem kobietą i jestem pewien, że ci faceci zwykle nie muszą się martwić o decorum, kiedy przeglądają kod innych facetów, ale szczerze mówiąc, to nie działa dla mnie i powoduje, że jestem mniej produktywny. Martwię się, że jeśli porozmawiam o tym z moim kierownikiem, pomyśli, że nie mogę poradzić sobie ze środowiskiem itp.


18
Jestem facetem, młodszym (w tej firmie) i czułem podobny podwójny standard. Baza kodów często wygląda jak bzdura, a jednak oczekuje się, że będę przestrzegać znacznie wyższego standardu. Okazało się, że bzdury się tam pojawiły z powodu „marszów śmierci”, które miały miejsce w przeszłości. Poza tym najwyraźniej wyglądam o 5 lat młodziej. Kiedy moi koledzy odkryli mój prawdziwy wiek, stałem się znacznie mądrzejszy z dnia na dzień. Ludzie są niedoskonałymi małpami. To pomaga, jeśli dzielisz z nimi lunch i śmiejesz się z ich żartów, ale nie przesadzaj. Faceci interpretują WSZYSTKO jako flirt.
Job

4
@Job: Cóż, jeśli podstawa kodu jest badziewna, powinno być lepiej, dlatego twoje commity muszą mieć wyższy standard. W przeciwnym razie stałoby się jeszcze bardziej gówniane, prawda? :)
Macke

@Marcus, masz rację, ale naprawdę pomocne byłoby, gdyby reguły były jasno określone, a te same zasady obowiązywały wszystkich. Jest też coś do powiedzenia na temat mieszania z tymi samymi standardami kodu, jak wspomniał pytający. Widziałem, jak młodszy facet został zwolniony jako kozioł ofiarny. Kierownictwo skarżyło się, że inżynierowie popełnili zbyt wiele błędów. Inżynierowie nie mogli wykonać przyzwoitej pracy, ponieważ kierownictwo wyznaczyło im ustalone terminy. Tak więc, gdy coś pójdzie nie tak, zawsze jest młodszy facet, który ma najwięcej wpadek do winy i odpuszczenia. en.wikipedia.org/wiki/Dedovshchina
Job

3
Jedna rzecz, która mnie wyróżniała to: „Są przyzwyczajeni do facetów, więc nie używają decorum”. Powiedziałbym, że musisz to zassać, chyba że jest to wyraźnie kwestia dyskryminacji. Czy poszedłbyś na plac budowy i spodziewałbyś się, że będziesz traktowany inaczej niż reszta twórców? Hartować. Jeśli pracujesz w środowisku zdominowanym przez mężczyzn, musisz umieć sobie radzić i dostosowywać się do różnych norm społecznych tak samo jak oni. Nie bądź taki „wrażliwy”.
Rig

1
Wiem, że jest o kilka lat za późno, ale myślę, że jest to ważny temat dla przyszłych czytelników. Nie wykluczaj, że Twój zespół po prostu wie lepiej; jest prawdopodobnie starszy i rozwinął intuicję w problematycznych kwestiach związanych ze stylem - wzywam każdego w tej sytuacji, aby traktował to jako okazję do nauki i rozwoju. Z szacunkiem poproś o wyjaśnienie kwestii, których nie rozumiesz, i uważaj, aby nie zinterpretować suchej osobowości współpracownika jako złośliwej.
weberc2

Odpowiedzi:


41

Istnieje szansa, że ​​zostaniesz wyróżniony jako kobieta, ale możliwe jest również, że jesteś młodszym programistą i dopiero zaczynasz pracę.

Ważne są sprawdzanie błędów i ekspresyjne komunikaty. Jeśli zamierzasz coś dodać do kodu, upewnij się, że jest to zgodne z normami zespołu. Podobnie, jeśli modyfikujesz czyjś kod, spróbuj go poprawić tam, gdzie to możliwe - nie przerywaj przepisywania całego tekstu, ale postaraj się pozostawić go trochę czystszym, niż go znalazłeś.

Czy istnieje pisemna wersja standardów kodowania, których przestrzega Twój zespół? Jeśli nie, dobrym pomysłem może być spisanie tego wszystkiego. Możesz przewodzić wysiłkowi, zapisując popełniane błędy i tworząc z nich listę kontrolną, do której możesz się odwołać przed przesłaniem zmian do przeglądu. Jako efekt uboczny możesz użyć tego pisemnego standardu, aby odwołać się do przyszłych odrzuceń, jeśli są one sprzeczne.

Wygląda na to, że między tobą a kierownikiem zespołu może być brak zrozumienia. Pomocne może być poproszenie go na spotkanie indywidualne i omówienie, co możesz zrobić, aby poprawić. Możesz wprowadzić coś w rodzaju „Czuję, że wciąż brakuje mi wielu niuansów tego, co powinienem robić. Jako młodszy programista chcę się rozwijać i doskonalić. Czy możesz mi pomóc się tam dostać?” i zobacz co się stanie.


Odpowiedzi Anny są na ogół bardzo rozsądne. +1. Myślę, że praca w miejscu pracy doprowadziłaby mnie do szału. Czy twoje kierownictwo nie dba o dotrzymywanie terminów? Jeśli kod działa, wyślij go. Posprzątaj później. Cholera, możesz go nawet posprzątać w poniedziałek i przeforsować w następnej wersji. Takie zachowanie twojego kierownika nigdy nie poleciałoby do mojego miejsca pracy i cieszę się, że mogę skoncentrować się na dotrzymywaniu terminów zamiast na polityce. Mam nadzieję, że Twoja sytuacja się poprawi i że znajdziesz rozwiązanie. :)
jmort253

11
@ jmort253 Dzięki. :) To powiedziawszy: „jeśli kod działa, wyślij go” może być niebezpieczne. Działający kod nie zawsze jest dobrym kodem (chociaż z pewnością jest lepszy niż uszkodzony kod), a jakość kodu jest ważna w perspektywie długoterminowej. Sprzątanie go później prawie nigdy się nie zdarza, ponieważ pojawiają się inne terminy i pojawiają się bardziej naglące rzeczy. Jest na to określenie - „dług techniczny”.
Adam Lear

@Anna, uzgodnij znaczenie zgodnego kodu. Przeczytałem, że niezgodny kod wystarczy, aby Linus Thorvalds od razu odrzucił przesłaną łatę dla Linuksa (ale nie mogę jej teraz znaleźć).

@ Anna / Thorbjorn - Czasami po prostu musisz zrobić to, czego chce klient, jeśli jest termin. Twój klient nie będzie bardzo wyrozumiały, jeśli straci przychody biznesowe o wartości 15 000 USD, ponieważ po prostu chcesz usunąć błędy kapitalizacji. Niestety próba wyeliminowania 100% długu technicznego nie zawsze jest możliwa. Byłoby to podobne do czekania 40 lat, aby zaoszczędzić wystarczająco dużo gotówki na zakup wymarzonego domu zamiast zaciągania kredytu hipotecznego. Jasne, byłbyś wolny i czysty, ale spędziłbyś całe swoje życie na kontaktach z podejrzanymi właścicielami.
jmort253

Projekty open source różnią się od projektów typu profit. Wiele projektów open source może pozwolić sobie na surowsze standardy, ponieważ nie zawsze można zyskać / stracić zysk. Projekty zastrzeżone mają różne cele, a czasem te cele biznesowe mają pierwszeństwo. Nie twierdzę, że kod nie powinien być zgodny, tylko że czasami musisz po prostu zrobić to, co musisz i mieć dyscyplinę, aby wrócić i naprawić problem po wdrożeniu.
jmort253

25

Wygląda na to, że bierzesz te rzeczy trochę zbyt osobiście. Nie; takie rzeczy zdarzają się cały czas.

Powody odrzucenia twojego zameldowania (nazwa zmiennej, jakość komentarza, lokalizacja konfiguracji) wydają mi się dość standardowe.

To była decyzja lidera twojego zespołu i nie martwiłbym się tym, gdybym był tobą. Jeśli ktoś zostanie zablokowany w weekend, kierownik zespołu może zezwolić na odprawę i poprosić o jej naprawienie. Jeśli uzna to za stosowne, aby go odrzucić, chociaż może to blokować innych programistów, to jest to jego odpowiedzialność.

Co do kierownika zespołu, który mówi, żebyś nie naśladował innych, ale robił to, co słuszne, wygląda na to, że próbuje dać ci inicjatywę, by ulepszyć bazę kodu. To dobry znak. Ufa, że ​​wykorzystasz swój osąd, więc idź dalej i rób to, co uważasz za słuszne. Nie oznacza to, że musisz zmieniać kod wszystkich innych, ale oznacza to, że powinieneś wziąć odpowiedzialność za jakość pisanego kodu.


2
+1 Skupiasz się na relacjach i emocjach. Programiści, z którymi pracujesz, brzmią bardzo sucho, ale koncentrują się na problemach z kodem. Jest to dość powszechne w środowiskach programistycznych, w których pracowałem. Nawiasem mówiąc, widziałem to niezależnie od płci.
Michael Durrant

14

Dodatek do innych odpowiedzi:

Jako główny programista jestem zazwyczaj bardziej wybredny w stosunku do młodszych deweloperów, ponieważ są znacznie bardziej plastyczni niż ludzie, którzy pracują od kilku lat. (Moje umiejętności ppl nie są już tak dobre ... jeszcze.)

Bardzo trudno jest zmienić kogoś, kto przez jakiś czas pracował (i zarabiał przyzwoitą pensję) i jest zadowolony ze swojego poziomu kodu (nawet jeśli jakość można poprawić). Ci faceci nie dbają o to, jeśli spróbujesz poprowadzić ich do zostania lepszymi / świetnymi programistami. Z przyjemnością pracują w fabryce kodów.

Nowi faceci, tacy jak ty, OTOH, zwykle tęsknią za wskazówkami i wiedzą, co jest dobre, a co nie. Są również w stanie przyswoić sobie słabość i zmienić swoje drogi na lepsze. Nie są ustawione na inne sposoby.

Jeśli weźmiesz te rady do serca i uczynisz je częścią swojego codziennego życia, przekonasz się, że w krótkim czasie nie będziesz pisać kodu, który jest lepszy od większości istniejącej bazy kodu.

Więc ...

.. może być tak, że dostajesz więcej opinii tylko dlatego, że masz potencjał, aby coś z tego zrobić. :)


To podnosi wiele dobrych punktów.
sevenseacat

13

Jest całkiem możliwe, że jesteś wyróżniony, ponieważ ... jesteś młodszym programistą.

Z twojego opisu brzmi to tak, jakbyś nie przestrzegał standardu, jak postrzega go kierownik zespołu .

Rozwiązanie jest proste:

  • Jeśli to standard, postępuj zgodnie z nim.
  • Jeśli nie rozumiesz standardu, poproś o wyjaśnienie.
  • Jeśli twoja interpretacja standardu lub instrukcji różni się od kierownika zespołu, poproś o wyjaśnienie

Nie rób z tego bitwy; jeśli spróbujesz sprawić, że zespół poprowadzi „złą”, to nawet jeśli wygrasz, przegrasz. Naucz się odpowiedniej lekcji i kontynuuj rozwój.


1
Próba podążenia za „standardem” do „T”, gdy ma się do czynienia z dorkami tak, jak opisuje, nie przyniesie wiele dobrego. Będzie to niekończący się spór o definicje i semantykę.
MrDatabase

4
@MrDatabase Nie brzmią dla mnie jak dork. Być może trochę wybredna, ale diabeł często tkwi w szczegółach, a kiedy zaczniesz tracić swoje standardy, cała Twoja aplikacja może szybko zejść.
Adam Lear

3
To prawda, że ​​standardy powinny być przestrzegane. Jednak wyraźnie pokazuje, że tak naprawdę nie jest to standard (poprzedni programiści nie stosowali się do niego). Dlatego jej współpracownicy narzucający jej „standard” (nie mówiąc czegoś w stylu „hej, wyglądamy ... wiemy, że wydaje się to niekonsekwentne, ale naprawdę staramy się ulepszyć naszą bazę kodu”) jest obłudny i nieprzydatny. Kiedy współpracownicy zachowują się w ten sposób, musisz przyjąć inne, inteligentniejsze podejście.
MrDatabase

@ user15859: jeśli odwołujesz się do mojej odpowiedzi, to wcale nie był mój zamiar. Myślę, że powiedziałem dokładnie to samo, co Anna powiedziała w swojej odpowiedzi. Żadne przestępstwo nie było zamierzone. Naruszone standardy, o których wspomniałeś, są ważne dla długoterminowej konserwacji, a wszelkie niejasności w zakresie stosowania standardów muszą zostać rozwiązane wraz z liderem zespołu. Gdybyś był leniwy, nie opublikowałbyś tutaj. Gdybyś był niekompetentny, nie przejmowałbyś się tak bardzo. Nie wierzę, że jesteś jednym z nich.
Steven A. Lowe,

1
Myślę, że odnosi się do tego, co powiedział Woot4Moot, gdy używał słowa „lenistwo i nieudolność” w swoim komentarzu. Myślę, że twoja odpowiedź jest dobra, ponieważ daje OP możliwość odwołania się i podjęcia działań w oparciu o jej interpretację tego, co naprawdę się dzieje.
jmort253

10

Notka autora

Kilka lat później; Zredagowałem to, aby dokładniej odzwierciedlić, co sądzę o sytuacji. Włożyłem więcej niuansów w swoją odpowiedź, ponieważ uczę się więcej o niuansach w tych sytuacjach. Łatwo jest uzyskać odpowiedź „czarną lub białą”, ale wszyscy wiemy, że nie jest to takie proste. Moja odpowiedź odzwierciedla to teraz.

Z tego, co opisałeś; Twoje zachowanie nie ma nic wspólnego z płcią. Nie oznacza to, że nie doświadczasz żadnego traktowania związanego z płcią (mam nadzieję, że nie), tylko to, co opisujesz, nie wydaje się być związane z płcią.

Kiedy byłem liderem zespołu, traktowałem wszystkich jednakowo. W technologii nie ma miejsca na złe traktowanie kogoś z powodu jego płci. Nie wiem, jak sobie z tym poradzić, jeśli ci się to przytrafia.

Ważne jest, abyś ufał, że kierownictwo Twojego zespołu traktuje mężczyzn i kobiety jednakowo. Jeśli istnieją dowody, że nie jest, wówczas stosuje się stare powiedzenie: Zmień swoje środowisko lub zmień środowisko.

Przez równe rozumiem, że traktuje wszystkich jednakowo, bez szacunku dla płci. Jeśli dobrze wykonuje swoją pracę, nie powinieneś widzieć go krytykującego kogokolwiek innego; i nie powinni widzieć, jak cię krytykuje. Przed innymi bardzo ważne jest, aby lider zespołu wykazywał pewność siebie, nawet jeśli spędził ostatnie pięć minut przed korektą zachowania na osobności.

Przejdźmy teraz do poruszonych problemów:

Zaewidencjonowałeś kod, który nie spełniał ustanowionego przez siebie standardu, więc odrzucił twój oddział. Gdybym był w jego butach, nie zrobiłbym tego samego w ten sam sposób, ale upewniłbym się, że moi podwładni (dziwne słowo; ponieważ nie uważam przywódcy za „przełożonego” za ludzi, których oni ołów, ale dokładnie (nie odpowiednio) opisuje sytuację) wiedzieć, co należy zrobić. Jeśli nie wiedzą, jakie są standardy, to moja wina jako lidera. To do mnie należy to naprawić. W tym przypadku mogłeś popełnić błąd, ale sam fakt, że tak się stało, oznacza, że ​​albo 1) nie powiedziano ci, co należy zrobić, albo 2) nie był odpowiednio mentorowany. Twoja wina też nie jest.

Jedną z najważniejszych części bycia programistą jest uświadomienie sobie, że podstawa kodu, nad którą pracujesz, musi być utrzymywana przez wiele różnych osób. Wszelkie zmienne komunikaty i inne rzeczy, które przeszkadzają w czytaniu kodu, nie są przezroczyste dla klienta , ponieważ naprawienie trudniejszych do odczytania problemów w kodzie zajmuje więcej czasu.

Jeśli Twój zespół napisał wytyczne dotyczące kodowania, zastosuj się do nich. Jeśli nie, to powinna istnieć jakaś konwencja społeczności dla twojego języka (w .NET i C #, Microsoft ma standard, który przestrzega wiele firm).

Zapytaj swojego kierownika zespołu, gdzie znajdują się wytyczne dotyczące kodowania, aby upewnić się, że je przestrzegasz. Weź dwa meldowania na spotkania, na których dwóch innych programistów konsekwentnie nie postępuje zgodnie z wytycznymi, więc gdy mówi, że nie ma żadnych, możesz wskazać, że inni też mają z tym problem, a każdy skorzystałby na tym te wytyczne.

Jeśli traktuje cię uczciwie, to zobaczy to i powinno to być na szczycie jego listy rzeczy do zrobienia. Jeśli nie traktuje cię uczciwie, masz amunicję, jeśli tak się dzieje.

Mówienie „dojdę do tego później” jest złe. Później nigdy się nie zdarza. Poświęć czas, aby zrobić to dobrze. Nie ma już programowania.

Trudno jest być młodszym programistą. Czujesz presję, by występować, a wiele osób patrzy na ciebie, a każdy błąd, który popełniasz, jest związany z Twoim imieniem i kontrolą źródła na zawsze.


1
Popieram komentarz na temat „Dojdę do tego później”. Gdybym miał nikiel za każdym razem, gdy to słyszę, cóż, nie byłoby mnie tutaj, piszącego w tym komentarzu. :-)
Eric King

Dla .Net jest policjant stylu. Włącz go, aby kod nie budował się, dopóki StyleCop nie będzie zadowolony. To usuwa ludzką podmiotowość, jest zastraszaniem siły roboczej. Widzisz, technologia może pomóc ci zdecydować, czy Michael Phelps był numerem 1 czy 2. W łyżwiarstwie figurowym jednak ... figureskating.about.com/od/famousskaters/tp/scandals.htm Prowadzenie zespołu nie powinno polegać na potykaniu się o władzę. W zespole nie powinno być [dis-] faworytów. Trzeba uważać, aby takie wrażenie nie powstało. Jednym z dobrych sposobów jest włączenie reguł, które sprawdzałyby kod i dawały obiektywną odpowiedź.
Job

3

Nigdzie w swoim poście nie wspominasz o tym, jak inni są traktowani. Powtarzasz, że „czujesz”, że jesteś „wyróżniony”, ponieważ jesteś „kobietą”.

Myślę, że jesteś traktowany jak młodszy programista bez względu na płeć i powinieneś być za to wdzięczny, ponieważ to właśnie oznacza równość. Czuję też, że robisz ogromne zamieszanie w związku z drobnymi, 5-minutowymi zmianami estetycznymi kodu, które musisz teraz zrobić zamiast umieszczania ich na liście rzeczy do zrobienia i nigdy się z nimi nie dogadując.

Nigdzie w twoim poście nie wspomniałeś, że kazano ci robić te rzeczy w weekend. Poprawki mogą być sprawdzane w poniedziałek rano.

Twój zespół może być trochę pedantyczny jak na mój gust, ale z twojego postu nie widzę nic złego w jego prośbach.

Proszę przestać grać kartą płci za darmo . Uważam, że jest to niegodne i podważa koncepcję równości płci.


1

Nie uważam, że odrzucenie mojej gałęzi na tej podstawie jest przydatne. Wiele osób pracowało przez weekend i nigdy nie powiedziałem, że będę pracować. W rzeczywistości niektóre osoby prawdopodobnie zostały zablokowane, ponieważ nie miałem czasu na zmiany i ponowne przesłanie. Pracujemy nad projektem, który jest bardzo wrażliwy na czas i wydaje mi się, że nie jest pomocne całkowite odrzucenie kodu w oparciu o rzeczy, które są przezroczyste dla klienta. Mogę się mylić, ale wygląda na to, że tego rodzaju rzeczy powinny być obsługiwane w zatwierdzeniach typu patch, kiedy mam czas.

Trudno powiedzieć coś pożytecznego jako osoba, która nie widziała Twojego kodu ani nie wiedziała o harmonogramie twoich projektów. Ale jeśli twój lider zachowuje się odpowiedzialnie i wykonuje dobrą robotę, wie, że inni nie byli tak naprawdę zablokowani i sprint nie będzie spóźniony. Więc nie przejmuj się tym. Być może przeceniasz wpływ na swoje zatwierdzenie. W przeciwnym razie: jeśli twój projekt ma krytyczne znaczenie dla czasu i przejdzie wszystkie testy, byłoby zbyt wybredne, aby odrzucić kod, który można naprawić po wydaniu w mgnieniu oka.

Zrób to Zrób to zrób Zrób to szybko

Tak więc, jeśli twój przywódca podjął decyzję o odrzuceniu twojego zobowiązania, jako profesjonalista powinien wiedzieć, co robił.

Teraz widzę, że w niektórych środowiskach byłaby to norma. Jednak krytyka nie wydaje się równomiernie rozłożona, co prowadzi do mojego następnego problemu. Podstawą większości tych problemów był fakt, że byłem w bazie kodu napisanej przez kogoś innego i starałem się być minimalnie inwazyjny. Naśladowałem nazwy zmiennych używane w innym miejscu pliku. Kiedy to stwierdziłem, otwarcie powiedziano mi: „Nie naśladuj innych, po prostu rób to, co słuszne”.

Jako Junior trudno jest znaleźć drogę do bazy kodów firm.

Najlepsze: istnieją udokumentowane standardy kodowania - i mam nadzieję, że nauczysz się je opanowywać.

Zwykle: istnieją nieudokumentowane standardy kodowania - i musisz się uczyć metodą prób i błędów, czy powinienem powiedzieć „ zatwierdz i odrzuć”? Jest to często bolesne (jak w twoim przypadku). Jest to czasami niebezpieczne z punktu widzenia jakości kodu i może prowadzić do programowania kultowego ładunku , w którym nie tylko naśladuje się zmienne nazewnictwo, ale w dobrej wierze kopiuje i wkleja struktury i wzorce z bazy kodu, należy to zrobić. Nie rób tego! Nawet nie naśladuj istniejących nazw zmiennych.

Trzymaj się kodu Clean . Jest to dobra praktyka i zapewnia łatwą do obrony pozycję. Jeśli jest to czytelny, testowalny i możliwy do utrzymania kod, przeważnie wygrałeś jakąkolwiek dyskusję.

A to prowadzi do kolejnej (ostatniej) porady: kieruj się zasadą harcerza !

Zawsze zostawiaj bazę kodu w lepszym stanie, niż był. Nawet jeśli otaczający kod, z którym pracujesz, jest nieprzyjemny, wyczyść swój - i jeśli masz czas, napraw otoczenie.


0

Poświęć trochę czasu na poznanie różnych niuansów osobowości twoich współpracowników. Z mojego doświadczenia wynika, że ​​można uniknąć irracjonalnej, niepotrzebnej, niekonsekwentnej lub po prostu bezwartościowej krytyki, jeśli obejmie się dziwactwa współpracowników.

Na przykład niektórzy współpracownicy mogą być kacami w poniedziałki. Mogą być bardzo irytujące i zbyt chętne do odrzucenia niektórych gałęzi kodu lub zatwierdzeń. Jeśli musisz współpracować z kimś takim, unikaj wprowadzania kodu w poniedziałki.

Z drugiej strony kacik może być zbyt blady, aby przejmować się gadatliwością komunikatów o błędach ... więc poniedziałek rano może być idealnym czasem na zatwierdzenie kodu :-p

Dziwactwa osobowości w biurze lub miejscu pracy są dosłownie nieograniczone. Mamy nadzieję, że dowiesz się, kogo unikać i kiedy ich unikać. Nie bądź też dla siebie zbyt trudny :-) Zawsze możesz rzucić pracę i znaleźć inną pracę!


1
Znajdź pracę przed odejściem, wielu menedżerów ds. Rekrutacji nawet nie przeprowadzi rozmowy, jeśli nie będziesz zatrudniony.
Woot4Moo,

-2

Nigdy nie pracowałem w środowisku, w którym kod jest odrzucany z powodu nieprzestrzegania pewnych konwencji. Gdybym był w twoich butach, miałbym pokusę, by szukać pracy w miejscu, w którym jestem bardziej upoważniony do podejmowania właściwych decyzji i gdzie klient jest najważniejszy, a nie kod.

Nie twierdzę, że czysty kod i standardy nie są ważne, ale klient i oś czasu produktu nie powinny cierpieć z powodu błędu ortograficznego w czymś, czego nie zobaczy żadna osoba nietechniczna, klient ani kierownictwo.

Powiedziawszy to, brzmi to tak, jakbyś pracował w środowisku, w którym oczekiwania nie są jasne lub nie rozumiesz w pełni wymagań z jakiegokolwiek powodu.

Niezależnie od sytuacji to Ty musisz przejąć kontrolę i zadać wyjaśnienia. Bądź proaktywny, jeśli jeszcze tego nie zrobiłeś. Członkowie zespołu i kierownicy zespołu prawdopodobnie będą cię bardziej szanować za zadawanie pytań w celu wyjaśnienia zasad meldowania się. Możesz również poprosić o „przegląd po działaniu”, w którym ty i lider zespołu dyskutujecie o tym, co powinniście zrobić i jak to zrobić umie odróżnić, o ile należy podjąć określone działania, a kiedy nie.

Proponuję dać czas, ponieważ jesteś nowy, aby sprawdzić, czy możesz pokonać wszelkie przeszkody i rozwiązać te problemy dzięki doświadczeniu, komunikacji i poznaniu standardów. Jeśli jednak po kilku miesiącach sytuacja się nie zmieni, a otoczenie nadal jest nękane przez dwuznaczność, może być czas na poszukiwanie pracy w innej firmie.

Nie każda organizacja jest tak drakońska i może się okazać, że inne środowiska pracy będą bardziej dostosowane do twojej osobowości, stylu i wymagań komunikacyjnych.


2
To nie wydaje się „drakońskie”; spójność jest ważnym elementem w utrzymywalności, konserwowalność jest ważnym składnikiem jakości, a oprogramowanie wysokiej jakości ma znacznie większą szansę na wysyłkę na czas i po niższych kosztach niż „kod kompromisowy”. Może być zachęcające, że około 80% firm produkujących oprogramowanie chce obniżyć jakość i ponieść konsekwencje, więc wydaje się, że nie brakuje żadnych „nie-drakońskich” możliwości zatrudnienia. :)
weberc2

1
Nie chciałbym pracować w środowisku, w którym podstawowe konwencje nie są egzekwowane. Jeśli projekt poddaje się w obronie swoich wytycznych kodowania, jest skazany na niemożność utrzymania na dłuższą metę. Zwłaszcza nazewnictwo zmiennych nie jest drobiazgiem: bez względu na to, ile istniejącego kodu nazywa się pewną macierzą A, nigdy nie zaakceptowałbym zatwierdzenia, które wywołuje inną matrycę Bdla zachowania spójności. Oczywiście nie wiem, co OP rozumiał przez „naśladowanie [...] nazw używanych gdzie indziej” dokładnie, jednak biorąc pod uwagę jakość kodu, który widziałem, może być w tym kierunku.
cmaster
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.