Jak kodujesz bez obrażania?

Rozumiem przez to, jak sobie radzisz z tworzeniem kodu opartego na kodzie udostępnianym programistom, którzy pracowali nad nim od lat i są z nim bardzo obeznani?

Nie chcę nadepnąć na nikogo, ale nie dostaję tak subtelnych skarg na sposób, w jaki robię różne rzeczy, czy to, jak wstawiam biały kod, czy jak często loguję się do SVN (zbyt często). Chociaż mogę z łatwością zmieniać te rzeczy - ogólnie chcę być lepszym programistą zespołu.

Nie jestem pewien, co robić, poza pytaniem, ale może macie jakieś przemyślenia, które mógłbym przećwiczyć.

AKTUALIZACJA

Nie ma tu żadnego przewodnika po stylu - po prostu ludzie nie są przyzwyczajeni do dzielenia się bazą kodu. Każdy ma swój mały, wyciszony świat kodu.

To jest sklep Perla, ale jestem pewien, że dotyczą one dowolnego języka

AKTUALIZACJA 2

CTO, który później został CEO, był kompletnym megalomanem i był głównym źródłem tych skarg. Jeśli nie robiłeś rzeczy dokładnie tak, jak lubił, bez względu na to, czy korzystał z komputera Mac, Emacsa, czy 4 tabulacji zamiast 2, czy też ubierał się w określony sposób, byłeś gorszy. To była okropna sytuacja, którą próbowałem skorygować, ale jedyną prawidłową odpowiedzią było dla mnie wyjście.

Jestem przekonany, że był to przypadek zastraszania w miejscu pracy, a następnie jestem bardziej świadomy tego, co może być subtelnym zastraszaniem i niewłaściwym zachowaniem w środowisku pracy.

Każdemu programistowi, który szuka odpowiedzi na taką sytuację, natychmiast wyjdź. Nie możesz pracować zespołowo, aby wyjść ze złej sytuacji w zespole.

Zapytać. To znaczy zapytaj ludzi, z którymi pracujesz. Staraj się trzymać ustalonego stylu istniejącego kodu. Zapytaj zwłaszcza, czy istnieje lista standardów kodowania dokumentów i postępuj zgodnie z nią. Jeśli nie ma, napisz pierwszy szkic na podstawie tego, co zaobserwujesz w kodzie, a następnie poproś pozostałych członków zespołu o jego krytykę. Wykonasz usługę dla firmy (i nowych programistów, którzy przyjdą za tobą), zaczynając dokumentować przyjęte praktyki kodowania. Jedynym ryzykiem jest złapanie się w środek, jeśli okaże się, że dawni strzelcy nie zgadzają się ze sobą co do tego, co jest lub nie jest dopuszczalne.

Nie bój się też być sobą . Możesz być nowym facetem, ale jesteś członkiem zespołu, a twoje opinie są aktualne. Jeśli możesz wymyślić lepszy sposób na zrobienie czegoś, zasugeruj to. Szanuj innych członków zespołu i ustalony sposób robienia rzeczy, ale nie pozwól im się popychać. Firma nie zatrudniłaby cię, gdyby nie doceniała twojego wkładu.

Bardzo pomoże, jeśli znajdziesz w zespole kogoś, kto wydaje się przyjazny i szczególnie chętny do odpowiedzi na pytania. (Jeśli jest to dobry zespół, powinien to być każdy, ale zespoły nie zawsze są takie.) Twój szef mógł wyznaczyć kogoś, kto pomoże Ci zacząć. Użyj tej osoby jako zasobu. Zapisz pytania, jakie ci się przydają, a następnie poproś tę pomocną osobę, aby od czasu do czasu na nie odpowiadała.

Jeśli chodzi o wpisywanie kodu „zbyt często”, dlaczego nie utworzyć własnego oddziału dla okresowych zatwierdzeń, a następnie połączyć się z powrotem do pnia, gdy kod będzie gotowy? Nie robi to nikomu krzywdy, a kiedy twoi współpracownicy zobaczą, że czerpiesz korzyści z SVN, które chcieliby, mogą pójść za tobą.

Odnośnie białych znaków: po prostu zrób to, ale kod już to robi. Idź z prądem.

Odnośnie do odpraw SVN: udokumentuj je bardzo wyraźnie. Pomaga to ludziom zrozumieć, co dzieje się w kodzie. (Kontynuacja: Jakie są ich zastrzeżenia do częstych meldowań?)

Ogólnie: zacznij tworzyć standardowy dokument kodowania. Nie próbuj wypełniać go 100 regułami. Po prostu dodaj reguły, gdy tylko się pojawią.

Ponadto: zadawaj pytania innym programistom. To daje im szansę na zważenie, zanim zrobisz coś, co im się nie spodoba. Ponadto buduje relacje. Ponadto dowiesz się więcej o tym, jak działa sklep.

Jeśli chodzi o styl formatowania kodu (białe znaki, tabulatory, gdzie nawiasy klamrowe itp.), Należy postępować zgodnie z obowiązującym standardem w kodzie. Jeśli nie ma, nie sądzę, żeby mieli na co narzekać. Jeśli chodzi o to, czy wstawiasz nawiasy klamrowe na ich własną linię, czy nie, umieszczasz spacje wokół list parametrów metod itp. Jest osobistą preferencją i powinieneś poddać się panującemu stylowi, ponieważ na dłuższą metę tak naprawdę nie ważne . Liczy się konsekwencja.

Jeśli chodzi o sprawdzanie kodu w SVN, starałbym się ewangelizować to, co uważam za właściwy sposób robienia rzeczy, zamiast pozwolić sobie na parowanie. Nie sprawdzam mojego kodu, chyba że buduje i przechodzi testy, a jeśli wprowadzam kilka niepowiązanych zmian, dzielę swoją pracę na kilka zatwierdzeń. Jeśli coś zostanie na jakiś czas zepsute, tworzę gałąź i tam wykonuję swoją pracę. Zatwierdzenia otrzymują opisowe komentarze. Z mojego doświadczenia wynika, że ​​działa to lepiej niż metoda „sprawdź stos zmian w piątek o 5:00” i wydaje się, że jest to „najlepsza praktyka” zgodnie z większością tego, co przeczytałem tutaj i gdzie indziej.

Najpierw przeczytaj dokument dotyczący konwencji kodowania (jeśli go nie ma, poproś go o napisanie jednego z nich, abyś mógł go przestrzegać)

Następnie zauważ i podejmij świadomy wysiłek, aby postępować zgodnie z tym i tym, co mówią. Może ci się wydawać, że są surowe, ale standardy kodowania są ważne, lepiej jest teraz wskazać, co jest nie tak, niż pozwolić, aby później pojawił się problem, gdy wprowadzasz większe zmiany.

Jestem pewien, że zrobisz to samo za rok lub dwa, gdy jakiś nowicjusz nadepnie Ci na palce :)

Zapytaj o standardy kodu firmy. Zwróć większą uwagę na szczegóły. Jeśli widzisz, że inni podążają za bardzo specyficzną formą białych znaków i wzorów klamrowych, postępuj zgodnie z nimi. Jako starszy możesz argumentować, że jest to wybredna, ale jako Jr. lub nowy facet w projekcie musisz pokazać, że możesz śledzić, zanim będziesz mógł prowadzić.

Zrozum także, że każdy nowy programista w projekcie będzie miał niezbędny czas „przyspieszenia”. Więc nie przejmuj się tym.

Najlepsze, co możesz zrobić, to postępować zgodnie z radami, które ci udzielają. Nie ma sposobu, aby powiedzieć z wyprzedzeniem, czego chcą. Chyba że jesteś medium.

Sugeruję jednak, aby ludzie udzielali ci porad, dokumentuj je. Czy masz wiki? Jeśli tak, użyj go. Jeśli nie, dobrym pomysłem może być plik tekstowy z kodem źródłowym. Zbuduj dobrze zorganizowany przewodnik po programach. Pomoże ci pamiętać, jak to zrobić, a jeśli ktoś zaprzecza wcześniejszej radzie, którą ci udzielono, daje ci punkt odniesienia do omówienia niekonsekwencji. Ponadto, gdy kolejna osoba dołącza do zespołu, nie będzie musiała przechodzić przez to, przez co przechodzisz.

Sugeruję, abyś nie przypisywał rad zawartych w dokumencie osobom (więc „bloki kodu powinny być wcięte trzema spacjami”, a nie „Bill powiedział mi, że bloki kodu powinny być wcięte trzema spacjami”). Jeśli jednak możesz zapisać te informacje w dyskretny sposób (np. W komentarzu do zatwierdzenia, napisz „dodana reguła dotycząca wcięć na podstawie porady Billa”), może to być pomocne w rozwiązywaniu sprzeczności, ponieważ możesz natychmiast uzyskać dwa punkty widzenia na czymś. Myślę tutaj o tym, że jeśli otrzymujesz sprzeczne rady, musisz unikać stania się piłką nożną przez dwóch kolegów, którzy się z czymś nie zgadzają. To trochę zakryte podejście, ale może być ostrożne.

Łatwo jest znaleźć przewodnik po stylu i postępować zgodnie z nim. Większość nie ma w nich nic obraźliwego i nie pozwoli ci obrażać innych.