Quali fattori dovrebbero influenzare il modo in cui determino quando abbandonare un piccolo progetto con un amico? [chiuso]

Spedito, il codice imperfetto è meglio di un codice perfetto sulla lavagna che non viene mai spedito.

Detto questo ...

Those of you with more experience, or that have been in similar situations. What did you do? What would you recommend I do?

Prenderò in considerazione quanto segue.

• Qual è lo scopo di questo progetto? Divertimento? I soldi? Per imparare?
  • Realizzi effettivamente questo scopo?
• Questa persona ti sta effettivamente consentendo di realizzare meglio i tuoi obiettivi?
• Quanto sei vicino alla spedizione effettiva?
• Questi problemi impediscono al tuo avvio? O sono una questione di orgoglio personale?
• Ci sono vantaggi nel lavorare con qualcuno su base volontaria quando è frustrante?

Stop programming on this project, abandoning nearly 10,000 lines of my code and countless hours slaving over design and try and find a new project on my own

Considera quanto sopra, prova a pensare al lavoro aggiuntivo richiesto.

Devi capire le tue priorità e determinare se valgono la pena affrontare i problemi relativi al lavoro con questa persona. Non possiamo capirlo per te.

My partner lost it tonight, and made it clear that no matter what, no matter the benchmark, no matter the common practice, no matter the irrefutable proof, his code will stay the way he first made it.

Sai che non vuoi lavorare con questo tipo di persona.

Stai facendo un progetto come questo presumibilmente perché vuoi imparare a programmare e trovare l'eleganza nel mestiere stesso.

Questa potrebbe essere una cosa culturale. In alcune culture, ammettere di aver commesso un errore è inaudito e chiedere a qualcuno di ammettere di commettere un errore è la cosa più rude che si possa fare. Se è quella situazione, scappa.

Nella mia esperienza con persone molto intelligenti, se gli dici che qualcosa che stanno facendo è tutt'altro che perfetta, o ti danno (1) un motivo corretto e facile da capire perché quello che stanno facendo è giusto, ( 2) ti dicono che sanno che è sbagliato, ma non hanno il tempo di risolverlo a causa delle priorità, o (3) grazie per averlo indicato e risolto.

Rifiutarsi di apprendere riguarda l'attributo peggiore che uno sviluppatore di software potrebbe avere. Lascialo ad esso. La vita è troppo corta e preziosa per sprecare il tuo tempo con lui.

Forse il modo più semplice è quello di portare qualcun altro nel progetto - o ti sbagli e la sua base di codice è troppo intelligente per te, o hai ragione e è troppo intelligente per tutti. Scoprirai presto e otterrà il backup se si rivelerà un codice di livello scadente, complicato, per programmatori junior.

D'altra parte, un prodotto funzionante vale un certo numero di anni di codice finemente sintonizzato, elegante e chiaro. Prepara il gioco, spediscilo, allontanati, lascia che lo mantenga e non lavori sulla v2.

Ecco alcune idee anche se alcune di esse si escludono a vicenda.

• Separare le responsabilità di origine. Se lavori sul modulo A e sul modulo B puoi competere con i tuoi diversi stili. Sta rilasciando spesso funzioni lavorative? Raggiunge un punto in cui ha bisogno di riscrivere il suo codice da zero? Rifatta il codice dai tuoi moduli e non toccarlo,

• Lascialo fare il mantenimento del suo peggior codice. Se lo fa con successo hai evitato un compito terribile. Se non è in grado, sentirà il dolore.

• Consideralo da un punto di vista dell'utente o del business. In alcuni casi hai solo bisogno di un prodotto valido che Google o Microsoft potrebbero acquistare. In altre parti stai lanciando un prodotto sul mercato e supportando migliaia di clienti con codice bacato o hackerato sarà un inferno. Non è la stessa cosa se il tuo codice controlla i droni con missili nucleari o rende felici i video per adolescenti.

• Lui fa le classi, tu fai i test. Il codice di refactoring con i test è più semplice e sicuro. In questo modo non avrai bisogno di guardare all'interno del codice solo la barra di Junit. Ciò presuppone che A) si stiano programmando i test, B) il codice del collega sia testabile. Se trovi difficile costruire i test durante la fase di codifica, quest'ultimo sarà peggio.

• Vai insieme alla formazione o agli eventi. Quando non conosci la strada giusta, è naturale usare l'unico modo che conosci. Vedere il codice degli altri potrebbe non risolvere tutto ma non ti farà male provare.

• Trova i tuoi punti di forza complementari. Il refactoring a volte può essere divertente. Se scrive cose che almeno potrebbero funzionare, allora potresti fare il refactoring. Può fare picchi per esplorare soluzioni che non finiscono nel codice di produzione.

• Potrebbe non voler riscrivere il codice, ma potrebbe accettare di scrivere meglio il nuovo codice. Capisco che riscrivere è difficile, noioso e può rompere le cose. Fai crescere alcune isole di qualità. In questo modo avrà buoni esempi di come fare le cose.

• Utilizza la regola di boy scout . Lasciate intatte le cose a meno che non vi sia bisogno di lavorarci sopra. Se un modulo è scritto male ma funziona e non ha bisogno di cambiare, lascia in questo modo. Se hai bisogno di correggere un bug o di completare una funzione, migliorala un po '. Dopo un po 'di tempo migliorerà il 20% delle classi che cambierai nell'80% delle volte. Più isole di qualità

Non possiamo suggerire quale sia la soluzione migliore senza conoscere entrambi. In bocca al lupo.

Ok, ecco una risposta che probabilmente non ti piacerà.

Do not 'correct' the code unless it fails to implement the feature.

Ecco il mio ragionamento. Stai presumibilmente cercando di fare soldi. Per fare soldi devi spedire rapidamente le funzionalità completate. Nessuno ti pagherà di più per un gioco per computer "ben codificato".

La maggior parte delle aziende ha lo stesso problema. Rif. Codice esistente per renderlo 'migliore', a volte anche oggettivamente migliore in termini di velocità o affidabilità OPPURE scrivi nuove funzionalità.

Il 99% delle volte sceglie di scrivere le nuove funzionalità perché è il risultato di una semplice analisi costi-benefici.

Mi piacciono tutte le risposte finora. Prendendo uno dei punti dalla risposta di enderland:

Are there benefits to working with someone on a voluntary basis when it's frustrating?

Mi piacerebbe prendere questo tempo per collegare lo scambio dello stack di revisione del codice . È un posto meraviglioso in cui puoi ottenere il codice criticato dai professionisti. E onestamente, molte recensioni sul codice sono estremamente utili per coloro che sono coinvolti: gli utenti, i rispondenti e coloro che inciampano e li leggono. Raramente riesci a ottenere recensioni così utili in un contesto professionale (che potrebbe essere il caso nei luoghi in cui ho lavorato per qualsiasi motivo).

Il mio consiglio è di postare parte del tuo codice per la revisione. Non suggerirei di usarlo come munizione per provare questo torto - dubito che lo prenderà a cuore - ma puoi ottenere informazioni molto utili sia sul codice che hai scritto sia sul codice che ha scritto. Consiglierei di inviare i pezzi di codice che voi due combattete maggiormente. Con ogni probabilità, ti stai sbagliando entrambi in una certa misura e puoi usare la recensione come un modo per far intervenire una terza parte obiettiva. Ciò comporterà alcune cose:

• Puoi disconnetterti dalla tensione emotiva della situazione.

• Ricevi consulenza professionale in tempo reale. Un grande impulso a ciò che stai imparando.

• Qualcuno ti dirà che ti sbagli. Il che è positivo, perché chiunque stia programmando per un certo periodo di tempo lo sentirà. Puoi gestirlo male come questo ragazzo con cui stai lavorando, o puoi imparare ad affrontarlo.

Penso che se usi le recensioni del codice nel modo giusto, hai molto da guadagnare affrontando questa persona estremamente frustrante. Ed è molto più interattivo di un libro o di un sito web che dice "fai questo, perché è il modo giusto il più delle volte".

Allo stesso modo, c'è lo scambio di stack di sviluppatori di giochi . Non tanto un post per postare il codice per la revisione, ma per chiedere dei concetti / idee con cui stai lottando. Ancora una volta, quel posto è estremamente utile per tutti i soggetti coinvolti.

Potresti aver visto entrambi questi siti prima; Volevo solo assicurarmi che facessero parte del tuo set di strumenti.

Sembra abbastanza senza speranza. Probabilmente mi arrenderei e andrei avanti se ne avessi sentito come te; Arriva sicuramente un momento per andartene e potresti essere lì.

Se non sei ancora pronto per andartene, devi trovare un modo per raggiungere un accordo migliore sul tuo processo. Sembra che tu abbia degli standard di codifica, ma non degli standard concordati. La prossima volta che vieni ad un bivio, la prossima volta che vuoi scimmiottare con un po 'di codice e il tuo amico vuole lasciarlo da solo, riprendi una conversazione seguendo le seguenti linee:

douglas: voglio cambiarlo perché X, che è proprio qui nelle nostre linee guida.

amico: Va bene com'è.

douglas: Quindi stai dicendo che dovremmo cambiare le linee guida?

amico: No, penso che sia bello come è.

douglas: Quindi quali sono le linee guida per?

amico: non lo so - li hai scritti.

douglas: quali linee guida scriveresti?

amico: non vorrei scrivere linee guida. È una perdita di tempo.

douglas: Quindi dovremmo buttare via le linee guida e scrivere qualunque schifezza ci stia pensando in quel momento?

amico: non è una schifezza.

douglas: è perfetto? È l'ideale?

amico: ottiene il lavoro; passiamo alla funzione successiva.

douglas: c'è qualcosa su cui possiamo essere d'accordo, che X è un buon codice e Y è un codice cattivo?

amico: lasciami in pace; Voglio solo codice!

Bene, non è andata bene, vero? Credo che la mia sensazione sia che tu e Buddy volete cose diverse. Se c'è qualcosa su cui puoi essere d'accordo, bene; inizia da lì e costruisci su di esso. Ma non puoi farlo accettare di volere ciò che vuoi - non più di quanto potresti farti desiderare ciò che sembra volere. Se riesci a trovare quel desiderio comune e giungere a un accordo comune da lì, forse puoi lavorare insieme.

douglas: cosa vuoi?

amico: voglio solo codice.

douglas: anch'io voglio scrivere il codice, ma voglio sentirmi orgoglioso del mio codice.

amico: sono orgoglioso del mio codice.

douglas: Ecco una funzione di cui sono orgoglioso - cosa ne pensi?

amico: Beh, va bene, ma non dovresti ricalcolare X all'interno del ciclo; è inefficiente.

douglas: Quindi stai dicendo che dovremmo sempre calcolare i valori costanti al di fuori dei loop?

amico: Beh, duh!

douglas: penseresti che dovrebbe essere nelle nostre linee guida?

amico: certo.

douglas: OK, lo aggiungerò alle nostre linee guida e aggiornerò il mio codice ...

douglas: com'è ora?

amico: bene.

Ora Buddy sta contribuendo alle linee guida (anche se indirettamente), e quindi ha un po 'di senso di proprietà. Forse - solo forse - inizierà a prenderli più sul serio. Penso che sarei propenso a cancellare la lavagna e ricominciare da capo con le linee guida, lasciando che la maggior parte o tutte arrivino da Buddy all'inizio. Vai avanti e scrivi il codice merda in modo che senta la necessità di aggiungere alle linee guida; lasciali venire da lui. Forse poi comincerà a capirne il motivo.

Ma se preferisci rinunciare e andare avanti, anche questa potrebbe non essere una cattiva opzione.

Supponendo che tu decida di abbandonare il progetto:

• Inserisci il codice fork e rifattalo, utilizzandolo come un 'portfolio' prima / dopo '
• Dato che l'obiettivo era (principalmente o in parte) di apprendere la programmazione e dal momento che imparare qualcosa richiede 2-4x finché si fa qualcosa che si conosce già, il lavoro non è veramente sprecato.
• 'Affrontare l'attaccamento di costo' (l'investimento che hai già fatto in un'impresa prima di apprenderlo era una cattiva idea) è uno degli errori umani più comuni nel processo decisionale
• Per mantenere l'amicizia, inquadra la tua decisione come priorità dell'amicizia sulla codifica

tl; dr dovresti probabilmente abbandonare il progetto.

Senza sapere altro su ciò che ci hai detto, avrei ipotizzato che l'attrito che stai vivendo sia correlato all'esperienza.

Anche se non sei un programmatore di professione come professionista IT, probabilmente hai imparato a fondo le cose per fare le cose bene la prima volta, il tuo riferimento al tuo sé futuro indica che l'hai fregato nel passato e imparato a non farlo.

Il tuo secondo anno di CS, anche se abbastanza dotato, probabilmente non ha la prospettiva di averlo fatto (se sei come me, più volte:).

Lui / lei mai crederà veramente nel valore di aggiustare le cose man mano che si procede fino a quando non ha bruciato cicatrici dall'incapacità di farlo o è mentore in una cultura con una disciplina ingegneristica eccezionale, o entrambe le cose.

Questa persona potrebbe essere il tuo peer di programmazione, ma è non il tuo peer di progetto, quindi fare questo gioco come un progetto peer è probabilmente una causa persa. A meno che tu non sia disposto a mangiare solo i costi futuri. Forse la relazione è abbastanza preziosa per te. In tal caso, lascia un cordino sufficiente per appendere se stesso e intervenire per aiutare a ripulire il caos quando quella persona è costretta a riconoscere il problema.

In caso contrario, fai un bail e fai un progetto con un peer, oppure fai un progetto mentore / allievo dove questa è la dinamica fin dall'inizio.

Per aggiungere ulteriori punti a tutte le ottime risposte:

• Quanto impegno ci vorrà per completare il progetto? Si noti che terminare "l'ultimo 10%" richiede molto più tempo di quanto ci si aspetti. Ciò include test di gioco / messa a punto, correzione dell'usabilità, gestione di una varietà di piattaforme di destinazione, rilascio, ... Se si tratta di un gioco iOS, c'è la firma del codice e la revisione di Apple. Onestamente, la finitura può durare fino al primo "90%". E sarà più difficile se il codice è così brutto come suggerisci. (Puoi iniziare a provarlo ora?)
• Realisticamente, quanto è probabile che le persone apprezzino il tuo gioco?
• Attenti al " costo euristico ridotto ". Valuta questo investimento di 10.000 righe di codice alla luce del quadro generale, guardando indietro a un prodotto finito e senza eccessivo ottimismo.
• Puoi continuare se ci vogliono altri 3 anni? Voi due avete stili di sviluppo diversi (non una buona partita di squadra). Sembra che tu sia vicino alla fine della tua pazienza e se vai avanti, potrebbe essere difficile rimanere amici.

Dovresti semplicemente continuare a fare il tuo codice nel modo che ritieni giusto, con commenti e simili e fare una copia della tua versione del codice (nel caso in cui cambi il tuo codice).

Non combattere, non arrabbiarti, sorridi quando vedi le sue decisioni sbagliate.

Reclami solo come utente, se funziona non lamentarti.

Non rinunciare a nessuno, è importante abituarsi a persone diverse da te, che avverranno in un vero lavoro.