Jakie czynniki powinny wpłynąć na to, jak określić, kiedy porzucić mały projekt z przyjacielem? [Zamknięte]


30

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.


3
Co powiesz na opracowanie uzgodnionych wytycznych dotyczących stylu kodowania i procesu przeglądu kodu? Unikaj wszelkich kontrowersyjnych kwestii, wystarczy wprowadzić standard, aby oboje mogli się na to zgodzić.
Brandin

25
Czwarta opcja (jeśli licencja jest dozwolona): rozwidlaj kod i kontynuuj pracę na własną rękę.
Robert Harvey

4
Jak licencjonowany jest kod? Czy możesz to rozwidlić i kontynuować z kimś innym?
Jaydee

14
Jak wspomina @enderland w swojej odpowiedzi, w tym, co napisałeś, jest absolutnie masywna czerwona flaga: „Mój partner stracił ją dziś wieczorem i wyjaśnił, że bez względu na wszystko, bez względu na punkt odniesienia, bez względu na powszechną praktykę, bez względu na niezbity dowód, jego kod pozostanie taki, jak go stworzył. ” Jeśli można uciec z tego zrobić. Każdy, z kim naprawdę warto współpracować, będzie miał pokorę, by zaakceptować, że czasami coś źle zrobi.
Richard J Foster

3
Bez względu na to, co zdecydujesz, 10 000 wierszy kodu nie zostanie utraconych: pomyśl o tym, czego nauczyłeś się z ich pisania; pomyśl o przyjemności, jaką miałeś podczas kodowania czasu; a zastosowanie tego, czego nauczyłeś się w (wymuszonej) trzeciej / czwartej / n + 1 iteracji, może nawet uczynić ją lepszą niż obecna wersja. Poza tym, jeśli wiesz, co napisać 10 000 wierszy kodu, możesz napisać 10 000 wierszy w stosunkowo krótkim czasie; często wiedza, co napisać, aby wszystko działało, zajmuje najwięcej czasu.
Kasper van den Berg

Odpowiedzi:


26

Dostarczony, niedoskonały kod jest lepszy niż idealny kod na tablicy, który nigdy nie jest wysyłany.

Biorąc to pod uwagę ...

Ci z was, którzy mają większe doświadczenie lub byli w podobnych sytuacjach. Co zrobiłeś? Co poleciłbym zrobić?

Rozważę następujące.

  • Jaki jest cel tego projektu? Zabawa? Pieniądze? Uczyć się?
    • Czy rzeczywiście osiągasz ten cel?
  • Czy ta osoba rzeczywiście pozwala ci lepiej osiągać swoje cele?
  • Jak blisko jesteś faktycznie wysyłki?
  • Czy te problemy uniemożliwiają uruchomienie? A może chodzi o osobistą dumę?
  • Czy istnieją korzyści z dobrowolnej współpracy z kimś, gdy jest to frustrujące?

Przestań programować w tym projekcie, porzucając prawie 10 000 wierszy mojego kodu i niezliczone godziny pracy nad projektem i sam znajdź nowy projekt

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

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.

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.


1
Dziękuję za odpowiedź. Osiągam cel, jakim jest dobra zabawa (kiedy nie walka) i nauka. Pogoda, na którą trzeba zarabiać, to zupełnie inna historia. Pomaga w osiąganiu moich celów, ale wierzę, że wciąż mógłbym je osiągnąć sam, motywuje. Gra jest doskonałym przykładem pełzania po funkcjach, szczerze mówiąc, nie mam pojęcia, kiedy można ją wysłać. Mój partner od miesięcy próbuje naciskać na zmianę z 2D na 3D, odmawiam, ponieważ już dawno przekroczyliśmy nasz zakres.
Douglas Gaskell

1
Byłbym skłonny porzucić projekt, gdyby był tylko mój, zostałby porzucony kilka miesięcy temu. Moim czynnikiem motywującym do kontynuowania jest kontakt z kimś innym, nawet jeśli konflikt zmusza mnie do zadawania pytań w niektórych dniach. Jedyną rzeczą, która powstrzymuje mnie przed porzuceniem tego, jest przyjaźń taka jak połączenie z nim poza kodowaniem, wolałbym raczej nie podrzucać tego w projekcie. Oczywiście nie jest to wyjaśnienie oparte na logice, ponieważ ich osobiste uczucia wiążą się z tym, że naprawdę zaparowuje moje możliwości decyzyjne.
Douglas Gaskell

1
najszybszym sposobem na utratę przyjaciela jest praca z nim na równi!

58

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.


Dziękuję, Gnasher, co jakiś czas widzę nr 2, chociaż nie mamy faktycznego harmonogramu, więc nie jestem pewien, jak ważna jest ta odpowiedź. Będę się nad tym przespać i zobaczę, co myślę w AM, co wymaga dużo dyskusji przed podjęciem decyzji.
Douglas Gaskell

1
„Jeśli tak jest, uciekaj”. - i ogólnie rzecz biorąc, jeśli nie możesz osiągnąć bliskiego konsensusu co do twoich celów, nie możesz z kimś współpracować. Wygląda na to, że nie wyrazi zgody na zmianę „swojego” kodu, bez względu na przyczynę.
Steve Jessop

Wydaje się, że presja czasu nie jest powodem do odmowy zmian.
gnasher729

1
To świetna odpowiedź. Nie możesz zmusić kogoś do zmiany sposobu! Wygląda jednak na to, że dużo czasu i wysiłku włożono w projekt zarówno po jego stronie, jak i twojej. Moim zdaniem może nie chcieć zmieniać swojego kodu, ponieważ nie rozumie, w jaki sposób uważasz, że należy to zrobić. Albo to, albo oszalał, ale jeśli to JEST, że tego nie rozumie, spróbuj pamiętać, że może być sfrustrowany i myśl, że „do niego mówisz”, nawet jeśli masz na myśli bardzo dobrze. Moja rada to postaraj się z nim przedyskutować, kiedy oboje będziecie gotowi.
zfrisch

^ + Ktoś łatwo się obraża, kiedy zaczynasz na tym samym poziomie, a on przewyższa cię umiejętnościami. Nie twierdzę, że tak jest na pewno, ale z pewnością brzmi to tak, jakby miało to coś wspólnego z tym.
zfrisch

12

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.


2
Dziękuję za odpowiedź. Zabawne, że wspominasz o swoim pierwszym punkcie. Próbuje znaleźć i wprowadzić początkującego programistę, którego może uczyć pomagania w projekcie. Mogłem się spodziewać, że okaże się to okropnie tylko wtedy, gdy dwie osoby będą postępować według tego samego stylu hackowania i zapomnienia. Podoba mi się druga opcja, zrób to, wyślij, a następnie zostaw. Problemem, na który mogę natknąć się, jest to, że jesteśmy częściowo zaangażowani w tworzenie LLC, dzięki czemu mamy nazwę, pod którą możemy wysłać naszą grę. Oba zastosowania będą miały oczywiście 50% udziału. Mogłem jednak go ukończyć, a następnie przejść dalej. Projekt jest duży, może to chwilę potrwać.
Douglas Gaskell

20
Zdajesz nie w żadnych okolicznościach chcą wprowadzić prawnie wiążącej relacji biznesowych z osobą tak.
gnasher729

3
@ douglasg14b sprowadza młodszego do nauczania .. biednego dziecka. Zaproponuj sprowadzenie doświadczonego faceta, „który przyspieszyłby znacznie szybciej i pomógłby ukończyć produkt”. Skoncentruj się na linii mety - czy oboje zamierzacie pracować nad tym hobby na zawsze i zawsze? (widziałem, że tak się dzieje, dopóki nie zostanie anulowane)
gbjbaanb

Zdecydowanie planuję to zakończyć. Chociaż uważam, że był to zbyt duży projekt, aby zająć się nim jako naszym pierwszym. Zaczęło się od prostego projektu, nie miało być tak blisko, jak jest teraz. Granica naszego zakresu jest nieustannie przesuwana z powodu pełzania funkcji przez mojego partnera, jestem częściowo za to winna, ponieważ pozwalam na to, a nawet zgadzam się z niektórymi funkcjami. Zakres polega na tym, że jeśli pozostawimy go w spokoju, prawdopodobnie oczekujemy ukończenia w ciągu roku. Na szczęście dzięki temu, jak go zaprogramowałem, części można łatwo wyjąć i wprowadzić do innych projektów później.
Douglas Gaskell

4
Myśl o kodzie jako o projekcie, a nie o tobie. Jeśli masz współwłasność produktu, możesz ponownie wykorzystać cały kod do następnego projektu. Jeśli nie masz pojęcia, kto jest właścicielem, zrób to teraz. Powodzenia.
gbjbaanb

9

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.


4

Ok, oto odpowiedź, której prawdopodobnie nie polubisz.

Nie „poprawiaj” kodu, chyba że nie zaimplementuje on tej funkcji.

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.


15
Podlega to jednak całemu argumentowi „zadłużenia technicznego”, prawda? Kiedy piszesz tę nową funkcję (lub modyfikujesz istniejącą), czy zajmuje ona trzy razy więcej czasu i produkuje dziesięć razy więcej błędów, niż gdybyś nadążał za refaktoryzacją? Jeśli tak, to może pominięcie refaktoryzacji było fałszywą ekonomią.
Ben Aaronson

1
Można by tak sądzić, ale pracowałem w wielu odnoszących sukcesy firmach i (prawie) nigdy nie widzę refaktoryzacji o wysokim priorytecie. Mój wniosek jest taki, że to po prostu się nie opłaca.
Ewan

To dość uczciwe i jestem pewien, że istnieje szereg opinii na ten temat, po prostu wydaje się, że nie zajęcie się w ten czy inny sposób znaczącym pominięciem odpowiedzi. Mogę się również mylić, ale czytając pomiędzy wierszami w pytaniu, myślę, że zły kod, o który martwi się OP, może być znacznie gorszy niż rodzaj kodu, o którym myślisz.
Ben Aaronson

heh, tak! ale także wydaje się, że koszt wprowadzenia zmian jest bardzo wysoki. W mojej odpowiedzi staram się podać cel „jesteś w tym za pieniądze?” odpowiedź plus mój subiektywny pogląd na to, gdzie leży bilans prawdopodobieństwa
Ewan

1
W niektórych przypadkach jest to uzasadnione, ale jeśli czyjś „działający kod” powoduje, że inna osoba spędza 2x tyle samo czasu na swoim kodzie lub na integracji systemów razem, albo w przyszłości, nie jest to już prosta decyzja typu „statek kontra statek”. Wiele dużych projektów ginie, ponieważ nie podejmują decyzji, aby zrobić to dobrze, a nie szybko.
kraina krańca

3

Podobają mi się wszystkie dotychczasowe odpowiedzi. Biorąc jeden z punktów z odpowiedzi Enderland :

Czy istnieją korzyści z dobrowolnej współpracy z kimś, gdy jest to frustrujące?

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.


2

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.


2

Zakładając, że zdecydujesz się porzucić projekt:

  • Rozwidlaj kod i prześlij go ponownie, używając go jako elementu portfela „przed / po”
  • Ponieważ celem było (głównie lub częściowo) nauczenie się programowania, a ponieważ uczenie się czegoś zajmuje 2-4 razy więcej niż robienie czegoś, co już wiesz, praca ta nie jest marnowana.
  • „Przywiązanie do kosztów utopionych” (inwestycja, którą już poczyniłeś w przedsięwzięcie, zanim dowiedziałeś się, że to zły pomysł) jest jednym z najczęstszych ludzkich błędów w podejmowaniu decyzji
  • Aby zachować przyjaźń, ustaw swoją decyzję jako priorytet nad przyjaźnią zamiast kodowania

1

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.


1

Aby dodać dodatkowe punkty do wszystkich świetnych odpowiedzi:

  • Ile jeszcze wysiłku będzie wymagało ukończenie projektu? Pamiętaj, że ukończenie „ostatnich 10%” zajmuje znacznie więcej czasu, niż ludzie się spodziewają. Obejmuje to testowanie / dostrajanie gier, poprawianie użyteczności, radzenie sobie z różnymi platformami docelowymi, wydawanie ... Jeśli jest to gra na iOS, istnieje podpisywanie kodu i przeprowadzanie recenzji Apple. Szczerze mówiąc, wykończenie może zająć nawet pierwsze „90%”. Będzie to szczególnie trudne, jeśli kod będzie tak zły, jak sugerujesz. (Czy możesz teraz zacząć grać w testowanie?)
  • Realistycznie, na ile prawdopodobne jest, że ludzie polubią twoją grę?
  • Uważaj na „ heurystykę kosztów utopionych ”. Oceń tę inwestycję w 10.000 linii kodu w świetle dużego obrazu, patrząc wstecz na gotowy produkt i bez nadmiernego optymizmu.
  • Czy możesz kontynuować, jeśli zajmie to kolejne 3 lata? Wy dwaj macie różne style rozwoju (niezbyt dobry mecz drużynowy). Wygląda na to, że zbliżasz się do końca cierpliwości, a jeśli będziesz kontynuować, pozostanie przyjaciółmi może być trudne.

3
„Ostatnie 10%” zajmuje dużo dłużej, jeśli 90% kodu to śmieci :-(
gnasher729

0

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.

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.