Ostatnio znalazłem się w trudnym miejscu. Pracuję nad grą z programistą od prawie 8 miesięcy. Oboje zaczęliśmy jako początkujący programista około sierpnia ubiegłego roku, jest studentem CS na drugim roku, jestem z zawodu technikiem wsparcia IT i jestem samoukiem z mnóstwem książek i subskrypcji online.
Problem, który ciągle widzę, polega na tym, że kiedy piszemy fragment kodu, często będzie on trochę zhakowany razem, będzie miał wiele wad, a jeśli jest to zupełnie nowa koncepcja dla jednego z nas, pełna naiwnych rozwiązań. To jest w porządku, uczymy się, spodziewam się, że oba nasze kody zostaną trochę zhakowane podczas pierwszego uruchomienia lub drugiego przejścia. Problem pojawia się, gdy chodzi o faktyczne naprawianie i refaktoryzowanie tych zhakowanych razem zachowań.
Mój partner będzie się trzymał jego świeżo ułożonego zachowania, rażąco odmawiając zauważenia błędu w momencie, gdy zacznie działać. Twierdząc, że jest niemal perfekcyjny, z fragmentu struktury, którego nie mogę nawet użyć, nawet jeśli zawiera on komentarze i odpowiednio nazwane metody i pola. Bez względu na to, jak bardzo się staram, po prostu nie mogę sprawić, by zobaczył rażąco oczywiste wady, które zapobiegną dalszym zmianom lub rozszerzeniu zachowania bez całkowitego ich zerwania, a wszystko, co jest tak ściśle z nimi związane, może równie dobrze należeć do tej samej klasy. Zhakowane rozwiązania są stale zhakowane, źle przemyślane projekty pozostają takie, jakie były, gdy zostały opracowane i przetestowane po raz pierwszy.
Poświęcam tyle samo czasu na opiekę nad nowym kodem, co sam, pisząc go, ale tracę co robić. Mój partner zgubił go dziś wieczorem i wyjaśnił, że bez względu na wszystko, bez względu na test porównawczy, bez względu na powszechną praktykę, bez względu na niepodważalny dowód, jego kod pozostanie taki, jak po raz pierwszy. Nawet jeśli napisano całe książki o tym, dlaczego chcesz uniknąć robienia czegoś, odmówi uznania ich ważności, twierdząc, że to tylko czyjaś opinia.
Jestem bardzo zainteresowany naszym projektem, jednak nie jestem pewien, czy mogę kontynuować współpracę z moim partnerem. Wydaje mi się, że mam trzy opcje do wyboru.
- Przestań dbać o funkcjonowanie bazy kodu po kompilacji i po prostu poradzić sobie z próbą utrzymania i przeanalizowania zachowania, które ledwo utyka. Mając nadzieję, że gdy wszystko zacznie się poważnie psuć, zobaczy to i spróbuje zrobić coś więcej niż tylko położyć bandaż nad zasadniczo wadliwym projektem.
- Kontynuuj niekończące się dyskusje na temat problemów, które zostały odkryte dziesięć lat temu przez inne, znacznie bardziej zdolne osoby.
- Przestań programować w tym projekcie, porzucając prawie 10 000 wierszy mojego kodu i niezliczone godziny pracy nad projektem i sam znajdź nowy projekt.
Jakie podejście mogę podjąć, aby ustalić, czy warto kontynuować ten projekt z tą osobą? Lub jakie czynniki powinny wpłynąć na moją decyzję? Napisaliśmy dużo kodu i nie chcę tego rezygnować, chyba że jest to konieczne.
źródło
Odpowiedzi:
Dostarczony, niedoskonały kod jest lepszy niż idealny kod na tablicy, który nigdy nie jest wysyłany.
Biorąc to pod uwagę ...
Rozważę następujące.
Rozważ powyższe, spróbuj przemyśleć dodatkowe wymagane prace.
Musisz określić swoje priorytety i ustalić, czy warte są problemów związanych z pracą z tą osobą. Nie możemy tego rozwiązać.
Wiesz, że nie chcesz pracować z tego rodzaju osobami.
Wykonujesz podobny projekt, prawdopodobnie dlatego, że chcesz nauczyć się programowania i znaleźć elegancję w samym rzemiośle.
źródło
To może być kwestia kulturowa. W niektórych kulturach przyznanie się do popełnienia błędu jest niespotykane, a proszenie kogoś o przyznanie się do popełnienia błędu jest najgorszą rzeczą, jaką możesz zrobić. Jeśli tak jest, uciekaj.
Z mojego doświadczenia z bardzo mądrymi ludźmi, jeśli powiesz im, że coś, co robią, jest mniej niż doskonałe, to oni (1) podadzą ci prawidłowy i łatwy do zrozumienia powód, dla którego to, co robią, jest słuszne, (2) powiedzą wiesz, że wiedzą, że to źle, ale nie mają czasu, aby to naprawić z powodu priorytetów, lub (3) dziękuję za wskazanie i naprawienie tego.
Odmowa nauki jest najgorszym atrybutem, jaki może mieć programista. Zostaw go temu. Życie jest zbyt krótkie i cenne, aby marnować na niego czas.
źródło
Być może najłatwiejszym sposobem jest zaangażowanie kogoś innego do projektu - albo się mylisz, a jego baza kodów jest po prostu zbyt sprytna dla ciebie, lub masz rację i jest zbyt sprytna dla wszystkich. Wkrótce się dowiesz i otrzymasz kopię zapasową, jeśli okaże się, że jest to bzdurny, skomplikowany kod poziomu programisty.
Z drugiej strony, działający produkt jest wart wiele lat precyzyjnie dostrojonego, eleganckiego, przejrzystego kodu. Stwórz grę, wyślij ją, a następnie odejdź - zostaw go, aby ją utrzymał i nie działa na v2.
źródło
Oto kilka pomysłów, nawet jeśli niektóre wzajemnie się wykluczają.
Oddzielne obowiązki źródłowe. Jeśli pracujesz na module A, a on na module B, możesz konkurować ze swoimi różnymi stylami. Czy często udostępnia funkcje robocze? Czy osiąga punkt, w którym musi przepisać kod od zera? Zmień kod z modułów i nie dotykaj jego,
Pozwól mu zachować swój najgorszy kod. Jeśli to zrobi, unikniesz okropnego zadania. Jeśli nie będzie w stanie, poczuje ból.
Rozważ to z punktu widzenia użytkownika lub firmy. W niektórych przypadkach potrzebujesz tylko realnego produktu, który Google lub Microsoft może kupić. W innych wprowadzasz produkt na rynek, a obsługa tysięcy klientów z błędnym lub zhakowanym kodem będzie piekłem. To nie to samo, jeśli Twój kod kontroluje drony za pomocą pocisków nuklearnych lub tworzy szczęśliwe filmy dla nastolatków.
On robi zajęcia, ty robisz testy. Kod refaktoryzacyjny z testami jest łatwiejszy i bezpieczniejszy. W ten sposób nie musisz zaglądać do kodu, tylko pasek Junit. Zakłada się, że A) programujesz testy, B) kod współpracownika jest testowalny. Jeśli trudno ci zbudować testy podczas fazy kodowania, to będzie gorzej.
Idź razem na szkolenie lub wydarzenia. Jeśli nie wiesz, która droga jest właściwa, skorzystaj z niej w sposób naturalny. Widok kodu innego może nie rozwiązać wszystkiego, ale nie zaszkodzi spróbować.
Znajdź swoje uzupełniające się mocne strony. Refaktoryzacja może czasem być świetną zabawą. Jeśli napisze rzeczy, które przynajmniej działają, możesz przefakturować. Może robić impulsy w celu eksplorowania rozwiązań, które nie kończą się na kodzie produkcyjnym.
Może nie chce przepisać kodu, ale może wyrazić zgodę na lepsze napisanie nowego kodu. Rozumiem, że przepisywanie jest trudne, nudne i może zepsuć wszystko. Wyhoduj wyspy jakości. W ten sposób będzie miał dobre przykłady, jak to robić.
Użyj zasady skaut . Pozostaw rzeczy nietknięte, chyba że musisz nad tym popracować. Jeśli moduł jest źle napisany, ale działa i nie trzeba go zmieniać, zostaw go w ten sposób. Jeśli musisz naprawić błąd lub uzupełnić funkcję, popraw ją trochę. Po pewnym czasie poprawi się 20% zajęć, które zmienisz w 80% przypadków. Więcej wysp jakości.
Nie możemy zaproponować najlepszego rozwiązania bez znajomości was obu. Powodzenia.
źródło
Ok, oto odpowiedź, której prawdopodobnie nie polubisz.
Oto moje rozumowanie. Prawdopodobnie próbujesz zarabiać pieniądze. Aby zarabiać, musisz szybko wysłać ukończone funkcje. Nikt nie zapłaci Ci więcej za „dobrze zakodowaną” grę komputerową.
Większość firm ma ten sam problem. Zmodyfikuj istniejący kod, aby był „lepszy”, a czasem nawet obiektywnie lepszy pod względem szybkości lub niezawodności LUB napisz nowe funkcje.
99% czasu decydują się na pisanie nowych funkcji, ponieważ wynik prostej analizy kosztów i korzyści.
źródło
Podobają mi się wszystkie dotychczasowe odpowiedzi. Biorąc jeden z punktów z odpowiedzi Enderland :
Chciałbym poświęcić ten czas na podłączenie wymiany stosu recenzji kodu . To wspaniałe miejsce, w którym możesz krytykować swój kod przez profesjonalistów. I szczerze mówiąc, wiele recenzji kodu jest niezwykle pomocnych dla osób zaangażowanych - pytających, odpowiadających i tych, którzy się z nimi potykają i czytają. Rzadko dostajesz takie przydatne recenzje w profesjonalnym otoczeniu (co może mieć miejsce w miejscach, w których pracowałem z jakiegokolwiek powodu).
Moja rada to opublikowanie części kodu do przejrzenia. Nie sugerowałbym używania go jako amunicji, aby udowodnić, że ten facet się myli - wątpię, żeby wziął sobie to do serca - ale możesz uzyskać bardzo przydatne informacje zarówno o kodzie, który napisałeś, jak i kodzie, który napisał. Polecam przesłanie fragmentów kodu, o które walczycie najbardziej. Najprawdopodobniej oboje jesteście w pewnym stopniu w błędzie i możecie wykorzystać recenzję jako sposób na uzyskanie obiektywnej strony trzeciej, która mogłaby wkroczyć. Osiągnie to kilka rzeczy:
Możesz odłączyć się od napięcia emocjonalnego sytuacji.
Otrzymasz profesjonalne porady w czasie rzeczywistym. Duży impuls do tego, czego się uczysz.
Ktoś powie ci, że się mylisz. Co jest dobre, ponieważ każdy, kto zajmuje się programowaniem przez dłuższy czas, usłyszy to. Możesz sobie z tym poradzić słabo, jak ten facet, z którym pracujesz, lub możesz nauczyć się sobie z tym radzić.
Myślę, że jeśli odpowiednio wykorzystasz recenzje kodu, możesz wiele zyskać, radząc sobie z tą niezwykle frustrującą osobą. I jest o wiele bardziej interaktywny niż książka lub strona internetowa z napisem „zrób to, ponieważ jest to właściwa droga przez większość czasu”.
Podobnie jest wymiana stosów twórców gier . Nie tyle miejsce na kod pocztowy do recenzji, ile na pytanie o koncepcje / pomysły, z którymi się zmagasz. Znów to miejsce jest niezwykle pomocne dla wszystkich zaangażowanych.
Być może widziałeś już obie te strony; Chciałem tylko upewnić się, że są częścią twojego zestawu narzędzi.
źródło
Brzmi całkiem beznadziejnie. Prawdopodobnie oddałbym się i ruszyłbym dalej, gdybym czuł się tak, jak ty; zdecydowanie nadszedł czas, aby odejść i możesz tam być.
Jeśli nie jesteś jeszcze gotowy do odejścia, musisz znaleźć sposób na lepsze porozumienie w sprawie swojego procesu. Wygląda na to, że masz standardy kodowania, ale nie są to standardy uzgodnione. Następnym razem, gdy dojdziesz do skrzyżowania, następnym razem chcesz małpować z odrobiną kodu, a twój kumpel chce go zostawić w spokoju, strzelaj do rozmowy w następujący sposób:
douglas: Chcę to zmienić, ponieważ X, który jest tutaj w naszych wytycznych.
kolego: W porządku, jak to jest.
douglas: Więc mówisz, że powinniśmy zmienić wytyczne?
kolego: Nie, po prostu myślę, że tak jest dobrze.
douglas: Więc jakie są wytyczne?
kolego: Nie wiem - napisałeś je.
douglas: Jakie wytyczne byś napisał?
kolego: nie pisałbym wytycznych. To strata czasu.
douglas: Czyli powinniśmy po prostu odrzucić wytyczne i napisać, co to za bzdury?
kolego: To nie bzdury.
douglas: Czy to jest idealne? Czy to jest idealne?
kolego: wykonuje pracę; przejdźmy do następnej funkcji.
douglas: Czy jest coś, na co możemy się zgodzić, że X to dobry kod, a Y to zły kod?
kolego: Zostaw mnie w spokoju; Chcę po prostu kodować!
Cóż, to nie poszło dobrze, prawda? Wydaje mi się, że mam wrażenie, że ty i Buddy chcesz różnych rzeczy. Jeśli jest coś, na co możesz się zgodzić, świetnie; zacznij od tego i buduj na nim. Ale nie możesz zmusić go, by zgodził się chcieć tego, czego chcesz - bardziej niż mógłbyś sprawić, że będziesz chciał tego, czego on chce. Jeśli potrafisz znaleźć wspólne pragnienie i stamtąd dojść do porozumienia, być może możesz współpracować.
douglas: Czego chcesz?
kolego: Chcę po prostu kodować.
douglas: Ja też chcę kodować, ale chcę być dumny z mojego kodu.
kolego: Jestem dumny z mojego kodu.
douglas: Oto funkcja, z której jestem dumny - co o tym sądzisz?
kolego: Cóż, jest OK, ale nie powinieneś ponownie obliczać X wewnątrz pętli; to nieefektywne.
douglas: Więc mówisz, że zawsze powinniśmy obliczać stałe wartości poza pętlami?
kolego: Cóż, duh!
douglas: Czy uważasz, że powinno to być w naszych wytycznych?
kolego: Oczywiście.
douglas: OK, dodam go do naszych wytycznych i zaktualizuję mój kod ...
douglas: Jak to teraz?
kolego: Dobrze.
Teraz Buddy przyczynia się do wytycznych (choć pośrednio), więc ma trochę poczucia własności. Może - tylko może - zacznie traktować je poważniej. Myślę, że byłbym skłonny wyczyścić tabliczkę i zacząć od nowa od wskazówek, pozwalając początkowo większości lub wszystkim z nich Buddy. Śmiało, napisz kod gówna, aby poczuł potrzebę dodania do wytycznych; niech z niego pochodzą. Może wtedy zacznie rozumieć ich powód.
Ale jeśli wolisz się poddać i iść dalej - to też nie może być taka zła opcja.
źródło
Zakładając, że zdecydujesz się porzucić projekt:
źródło
tl; dr powinieneś prawdopodobnie porzucić projekt.
Nie wiedząc o tym więcej niż powiedziałeś, spekuluję, że tarcie, którego doświadczasz, jest związane z doświadczeniem.
Nawet jeśli nie jesteś z zawodu programistą jako informatyk, prawdopodobnie nauczyłeś się na własnej skórze dobrego robienia rzeczy za pierwszym razem, ale twoje odniesienie do przyszłego siebie wskazuje, że spieprzyłeś go w przeszłości i nauczyłeś się nie do.
Twój student CS na drugim roku, nawet dość uzdolniony, prawdopodobnie nie ma takiej perspektywy (jeśli jesteś podobny do mnie, wielokrotnie :).
On / ona będzie nigdy naprawdę wierzą w wartości naprawie as you go, dopóki on / ona ma palić blizny z nieprzestrzegania zrobić lub jest prowadzony w kulturze z wyjątkowej dyscypliny inżynierskiej, albo jedno i drugie.
Ta osoba może być twoim programistą, ale nie jest twoim projektantem, więc robienie tej gry jako projektu równorzędnego jest prawdopodobnie straconą przyczyną. Chyba że jesteś przygotowany na po prostu zjedzenie przyszłych kosztów. Może związek jest dla ciebie wystarczająco cenny. W takim przypadku zrób wystarczająco dużo liny, aby się powiesić i wkrocz, by pomóc posprzątać bałagan, gdy ta osoba będzie zmuszona uznać problem.
W przeciwnym razie zwolnij za kaucją i zrób projekt z partnerem lub zrób projekt mentora / podopiecznego, w którym od samego początku jest to dynamika.
źródło
Aby dodać dodatkowe punkty do wszystkich świetnych odpowiedzi:
źródło
Powinieneś po prostu robić swój kod tak, jak uważasz za słuszny, z komentarzami itp. I robić kopię swojej wersji kodu (na wypadek, gdyby zmienił kod).
Nie walcz, nie złość się, tylko uśmiechnij się, gdy zobaczysz jego złe decyzje.
Skarż się tylko jako użytkownik, jeśli działa, nie narzekaj.
Nie poddawaj się, ważne jest, aby przyzwyczaić się do ludzi innych niż ty, co stanie się w prawdziwej pracy.
źródło